通才和专家：如何选择

原文：Generalists and specialists: thoughts on hiring
作者：Nicholas C. Zakas

我的职业生涯经历过各种规模的公司，从非常小的五人创业团队到 13000 人的大公司雅虎，再到约 1000 人规模的 Box（我目前所在），这些公司有着迥异的组织文化和招聘哲学，我也面试和聘请过众多的应聘者，在挑选优秀同事方面有着出色的成绩。

在这些经历里，我发现招聘策略的最大差异最终归结为一点：公司更青睐专家还是通才。我并不认为搭建工程师团队有唯一正确的方法，但我相信公司的规模和和它所处的阶段是招聘策略中重要的影响因素。

通才和年轻公司

通才是这样的人，从定义上来说，是指没有特定专长的人。他们大多毕业于计算机专业，擅长各种服务器端的工作，如数据库、基础设施、构建、部署、数据操作和处理等等。通才的人员在工作中并不介意从 C++ 转向 Python 再到 Java，众多编程语言对他们而言差别不大，转换起来也没有什么负担。他们是真正的战马，能够承担交给他们的任何任务。

对大多数任务来说，通才倾向于完成到良好，但可能不会到优秀的水平，而且在需要完全不同思维模式的事情上不会太顺利。比如大多数通才都会在前端或移动端的任务上比较纠结，这两个领域的模式和后端的开发哲学有着很大差异，这部分产品在通才的手上也时不时会碰到点小问题。

一家公司的早期阶段总是起步于异常紧张的资源，即便你成功融资，也很难迅速招募到满足需求的全部人力资源。因此这个阶段任何加入公司的人都应该尽可能戴更多头衔，完成各种事情。我以前端的身份加入 WellFurnished 而最终搭建起了整个基础架构、源码控制、构建和部署系统，当碰到问题我通常会向公司里的通才寻求帮助，只要他们能抽出时间在任何地方给到一点帮助。

年轻公司没有奢侈的资金可以雇人来只做一件事情或者一小部分事情，事情太多而人员太少。通才能够让业务起步运转起来，所有人的所有时间都要投入在推进计划上，否则你就是在浪费你非常有限的资源：钱。

在这个阶段，还有个相当实用的技术策略。因为整个系统规模很小，每个工程师都可以（也应该）理解系统的每个部分。脑中有整个系统的图景很重要，因为每个人都可能需要做任何事情。

引入专家

相对而言，专家是那些在部分领域有突出专长的人。他们对这些领域有深入的理解，为此，有必要忘记（有意或者无意）一些通才会格外注意的东西。专家提供的是在特定领域里的高级能力，他们把职业生涯聚焦在有限的领域里，以此达到通才所不能达到的高度。

在公司的早期阶段，通才创造了大量“足够好”的方案。这不是什么坏事，只是公司成长的正常步调。“足够好”的方案正如它的名字所示，足够支持公司发展到它的下一阶段，有时候甚至好到能支撑公司接下来两三个阶段的成长。但最终，“足够好”的方案终会变得不再够好，这就是你需要聘请专家的时候了。

不再够好会有多种表现，最显著的就是前端部分：我工作过的每家专注于聘请通才的公司都有一段时间受困于糟糕的前端质量。设计师很苦恼，因为工程师无法实现他们的设计方案，产品经理也很不满因为前端是面向最终用户的关键环节。这个时候，终于有人开始考虑是不是该招个“真正懂这坨东西”的人。

在小公司成长为大公司的过程中，总会碰到这个富有争议的问题。对于聘请专家的主要争论会是：

• 我们不知道如何招聘这样的人。

面试流程是为招聘通才而设计的，所以面试问题大部分都围绕通用的计算机科学知识，以便考察候选人是否足够“聪明”。面试会有很多算法问题、数据结构问题以及关于复杂度的讨论——所有这些都不是为了考察特定领域的能力，而是为了考察那些适用于任何编程语言的通用概念。这些对于通才是应该的，毕竟他们要熟练操作任何工具面对各种问题。一旦公司适应了以此来衡量候选人是否足够“聪明”，就很难做出改变。事实上，“聪明”是个非常灵活的词，并不能拿来整齐划一地衡量每个人。然而如果公司里没有专家的话，又该如何评估专家的能力水平？

• 这会导致资源分配问题。

通才招聘策略背后的的一个理论是，你会有一个小而全能的资源可以随时酌情分配到任何项目中。如果所有人都能做所有事情，你就有了无限灵活分配的项目资源。不需要等 Jim 空下来或者 Mary 完成她的项目，只要有工程师空下来你就能安排他开展下一步骤。而专家，照称谓来说，你应该安排给他们特定领域的事情。这从根本上改变了工程师团队分配资源的方式：突然有一个人只能做一些特定的任务，因为这个差异，整个组织都会因此被推到一个不稳定的状态。

如果正在看此文的你是一位专家，你肯定会想：“这些理由都是狗屁”；如果你是一位通才，你肯定会想，“对啊，显然的”。接下来我会分别解释，这些想法都是真实并且合理的，不过绝不是无法解决的。许多公司都踩过这个坑并成功地跳出来，解决问题的关键总是招进来第一个专家，并且证明团队依然可以顺畅工作。

我们真的需要专家么？

是否真的需要一个专家加入的问题总是归结于公司的状况有多紧迫，通常会使这两种情况：

• 有东西真的坏了。

不幸的是，这种情况最为常见。经过数月数年的修改和补丁，曾经是“足够好”的东西现在变成了“一团糟”，你需要真正懂这块的人来解决问题。

• 进入新的领域。

很多公司在进入新的业务领域又想快速推进的时候，就会想要招聘专家。例如推出一个 Web Application 的移动版，或者反之，这是专家加入的好机会，因为有机会从零开始充分展示他们所能。可惜的是，这种机会并不常见。

第一种情况，事情已经相当糟糕，在我的职业生涯里不论是作为员工还是作为顾问，都见过无数。第二种情况则主要是移动开发者们会碰到的，近年来所有公司都迫不及待地推出移动应用。

是否真的需要专家的问题，也可以根据当前的资源分配状况来判断。如果你发现系统的某一部分总是需要投入大量关注，很可能就是通才已经快要搞不定了。

聘请专家

最终，每个成功的公司都会开始聘请它们的第一个专家——这是必然的。第一步自然是搞清楚如何聘请专家。你需要认识到现行的面试流程很可能并不适用；此外，专家对于跟他擅长的领域毫无关联的问题也没有好感。那么，当你的公司没有此领域专家的时候如何面试这位专家呢？

当你的公司没有这类专家的时候，你们总有人是在做这个领域里的工作内容的，这些人就是你应该安排面试评估的人。最简单的方法就是直接讨论当前碰到的问题，询问候选人会如何解决。这并非随便拉个人来做免费工作，短暂的面试过程也不大会真正解决问题，询问的要义在于向候选人请教问题的状况以及理解他们的思路。好的专家能够和你厘清问题的范畴，阐述他们会审查哪些细节以及可能的解决方案。

和非专业人士能够明白流畅地沟通，对他们来说是非常重要的技能，他们会需要做大量这类的工作，因为没有其他人能完全了解他在做的事情，你需要确保这个专家能以大家都听得懂的方式和大家沟通。最后，理解候选人如何定位问题以及认可他的解决方式，是做出聘请决定的最佳途径。

问题的第二部分是资源分配，这个问题通常也会自愈。很多有通才意识的工程副总裁会担心没有足够多的工作安排给专家，导致资源浪费。实际上，在初期阶段总是会有足够多的事情需要处理所以不是什么问题，无论解决问题还是创造全新产品都够专家忙一阵子的。在这之后，通常是工程师团队已经开发完成了一个阶段性产品，总会有更多特性需求接踵而来。通常在一到两年之内，你就会发现一个专家已经不够用了。

专家拐点

公司发展到一定阶段，没有专家是很难继续下去的，甚至你的通才都要开始专注于产品的部分领域中。产品和基础架构都变得更大，产生了一个有趣的问题。

你最初一直是聘请能做任何事情的通才的，得益于基础架构很小，把整个系统都捻熟于心并不困难，所以这是行得通的。到了某个时刻，基础架构必然会成长到足够大，大到不可能要求每个人都熟悉整个产品架构，人们将会不可避免地开始专业化。

在这个阶段的专业化意味着对系统关注的更少，释放精力会提高工程师的效率，而最终他们将只需要掌握系统的特定部分及其边界。如果他们需要知道其他部分的内容，就去找负责那个方向的工程师即可。

当工程师开始主动要求在某个方向投入更多精力的时候，你就知道公司到了这个阶段了。这时候聘请专家会更加容易，因为你已经拥有专家了；而继续聘请通才则不再合时宜。在公司高速成长的时候去培训每个工程师或者希望他们自学一个新领域的技能，就是拖慢公司的脚步。在我曾经待过的一个公司，工程师平均要入职六个月之后才达到正常的生产力水平，原因就是坚持聘请通才，并且招聘评估也主要着眼于潜力而非现有能力。这意味着我们无法聘请成熟专家，而总是寄希望于培养候选人。这样造成拖延完全没有必要。

当然也偶尔会有工程师对自己的领域感到乏味，想要跳到另一个全新领域。这种事情是难免的，但是应该不会太多。在这个阶段公司可以支持少数人转换领域，但不能是所有人都不停地切换到新领域，然后从零开始学习如何高效地产出。

只聘请最强员工如何？

另一个反对聘请专家的观点是公司只想要雇用最聪明最强大的员工。我称之为“Google 理念”，因为 Google 曾经就是这么做的。大约是 2006 年，我曾经前往 Google 做过一次面试，当时它是最火热的公司，所有人都渴望加入，只是一次面试机会也足够令人激动。有趣的是，他们似乎并不特别在意你的专长有多突出，你也不能申请特定的职位。所有人得到聘请之后会进入一个资源池，你第一天的任务就是找到想要参与的项目。Google 的整个思路就是聘请最优秀的人，然后找事情给他们做，简单来说，这就是终极的通才招聘策略。

不知道 Google 现在是否仍采用这种招聘策略，不过我认为这有点像是职业体育运动中专注于招募最顶级运动员。如果你不是个体育爱好者的话我简单介绍一下，美国的职业运动队每年度都会例行选拔业余或者职业运动员加入。拿篮球运动来举例，在一场比赛中场上总是有五名运动员，两个后卫，两个前锋，一个中锋，他们有不同的职责和战术。在选拔的时候，很多球队会寻找填补他们短板的专长球员（也就是专家），然而也有少数球队倾向于寻找“天才球员”，也就是说他们并不是为特定角色寻找队员，或者他们也不确定招募的球员将来会打什么位置，总的来说他们希望是一个最天才的球员（也就是通才）。

无论球队选了谁，他们在场上只能摆五个人，因此要想胜利就要派出最好的中锋，加两个最好的前锋，还有两个最好的后卫，无视各个职责之间的能力需求差异会让整个球队都吃苦头。大多数篮球队都懂这个道理，所以他们有时甚至会放弃不错的球员，如果球队在这个角色上已经有了出色球员的话。

以个人看法，我坚信在公司规模允许的情况下应该尽量招聘专家。坚持聘请通才再按业务需求来培养，会显著拖累公司的发展，而你的团队最终将会失衡，无法承担涌现的各种新工作内容。

总结

我相信这本质上是人类的专业化趋势。我们整个人生的教育流程就是这样安排的，一开始都是通用知识（数学、语文、科学、历史），逐步到了大学就需要选择方向和专注的领域。自然而然的你会在这个过程中发现你有兴趣做的事情，你想在这方面做的更多，而其他事情则不那么有趣和享受。

早期的公司毫无疑问需要通才，而且很可能会持续相当一段时间，直到它有能力聘请更多员工。通才非常适合这种情景，或者任何需要随时切换任务的场景。代价是你能够得到大量“足够好”的解决方案，而非少量最好的方案。

当“足够好”的方案不再够好的时候，你会引入专家。有时候是因为遇到了无法解决的困难，有时候是因为产品线的自然扩张。在这些情况下，你需要有对相关领域有成熟经验的人加入，聘请专家不是为了他们有潜力应付各种问题，而是为了他们解决当前的需求，马上交付产品。

随着公司和员工的发展，通才逐步转变为专家也很常见，系统和架构规模的增长自然会导致这一现象。支持员工专业化能提高所有人的效率，每个人都能释放一部分精力而更加专注自己负责的问题。

知晓在何时以及如何从通才团队转向专家团队更多是一门艺术，而非科学。我希望本文能对此有所帮助。