如何进行技术招聘？

团队

技术招聘的重要性远超你的想象，一个公司的招聘流程恰恰可以反映其工程团队的水平。Jan Jorgensen在博客上分享了他经验之谈，好的招聘流程可以促成好的工程团队文化，而且必须做到快速回应、测试驱动和积极沟通。以下内容翻译自Jan的博客，已获得作者翻译授权，查看英文原文 Bad News, Y'all: Your Hiring Process is Also Your Engineering Process。

虽然我不知道你是谁，但我敢说，你在招聘这件事情上一定搞砸过。不管你是工程师也好，负责技术招聘的专员也好，还是初创公司，你一定搞砸过招聘。

或许你总能招到好的人才，不过你也一定经历过艰难的日子。你阅读过一些资料，进行过一些招聘，但都太过依赖你的直觉，而好的直觉靠的是运气。

我要说的是，不管你接不接受，你的招聘流程正好反映了你的工程团队水平，反之亦然。即使你不在招聘团队里，也应该注意到这一点。回顾一下过去的面试：如果高管主导了大部分的面试，那么这些人可能正在管理着你的团队；如果你的公司把招聘外包给HR，那么流程问题和管理问题也一并外包给了他们；如果你是同事面试进来的，那说明你的团队拥有一定程度的自主权。不管是有意的还是无意的，你的招聘流程正影响着你的团队流程和文化。有时候，不做选择也是一种选择。

招聘流程与团队文化无法撇清关系主要有两个方面的原因。首先是权力和习惯。小公司的领导要尽早地巩固自己的班底，在公司发展壮大之后，他们就不会被轻易调配，也不需要改变多年养成的坏习惯。我的中学音乐老师曾经说过：“习惯不会造就完美，但完美的习惯会”。

其次，好的候选人在招聘过程中会高度专注，哪怕在管理上表现出一点点对他们的不信任都会把他们吓跑。

如果招聘流程可以影响到团队的价值观和优先级，那么好的招聘流程也能促成好的工程团队文化。好的招聘流程包括三个要素：快速回应、测试驱动、沟通。

快速回应

如果在面试中碰到好的候选人，在面试结束时我总会对他们说：“你最迟在两天内可以收到我们的通知，如果没有，请直接给我发邮件”。如果候选人在某个领域有很大的影响力，那么就没必要花两个礼拜的时间才把他们招进来。如果动作慢了，你就会错过优秀的候选人，从而浪费了时间，还会养成错失良机的习惯。

其实，你没必要非得招到什么样的人，你应该接受那些不完美的人。错失好的候选人是不可避免的，你要为此做好心理准备。有“完美”代码强迫症的团队不是一个高效的团队，因为没有人知道该如何做出合理的权衡。追求“完美”代码是一个很糟糕的目标，招聘“最好的人选”也一样。

不做选择也是一种选择

我总是告诉人们：“如果你不积极主动地安排好你的生活，或许是因为你想把事情留到以后再做。你忽略了当前的选择，但实际上已经做出了选择。你只有在知道为时已晚的时候才会意识到这一点”。

如果你的客服回应时间比招聘回应时间还要快，那说明你们的招聘流程是很糟糕的。如果你想招到优秀的开发人员，在面试后的两天内就要做出回应。没错，就是两天。一个小公司可以在48小时远程招聘一个员工，从筛选简历到发出录用通知书。好的开发者在找工作时总是对具有挑战性的工作虎视眈眈。除非你是Google，或者你只想招聘没有实际经验的毕业生，否则你就要仔细考虑清楚。不要指望好的候选人会等你的电话，你要与他们保持联系，而且要马上联系他们！

有时候，你可能因为要发布项目，抽不出时间参加面试。这个没有问题，因为偶尔错失好的候选人并不是世界末日。不过，如果你认为面试是有时间才会去做的事情，那么就不要指望能够招到好的人才。更糟糕的是，在你看来，代码比人重要。

如果你把代码看得比人重要，那么你就无法真正建立起一家公司，即使候选人接受了录取通知书也无法改变这个事实。

尽早失败（Fail Early）

如果要让我来培训面试官，而且只能教他们一件事情，那么我会告诉他们：如果你对这个人不是很感兴趣，那么就可以拒绝他，不要犹豫。头脑风暴是一个很有用的工具，因为它可以“随意丢弃（free disposal）”想法。并不是说头脑风暴当中就不存在糟糕的想法，只是这些想法可以很快地被丢弃掉，所以你要尽早说出你的想法。不过，在招聘过程中做出快速回应并不像丢弃想法那样简单。要快速做出回应，你需要合理地利用时间。

简历筛选可以在5分钟之内完成，而且几乎谁都可以做到。大部分电话面试可以在30分钟之内完成，除非遇到非常感兴趣的或者喜欢社交的候选人。技术筛选需要一个小时的时间。以上的这些工作都可以由普通员工来完成。最后的面试可能需要几个小时甚至一整天，取决于公司的具体情况。

让我们来看一下这种保守的4步技术招聘流程：

1. 简历筛选（最多5分钟）
2. 电话初试（30分钟）
3. 远程技术面试（1个小时）
4. 现场面试（4个人时）

如果候选人能够参加完所有的面试，总共需要差不多5个半小时的时间。但是很显然，并不是每个候选人都会走完整个流程。我们假设有100份简历，并且你会拒绝掉一些候选人，那么让我们来看看每个候选人平均需要花多少时间。

蓝线表示我们按照一定的速度在面试过程中拒绝候选人。从六个候选人中拒绝掉一个之后，每个候选人平均需要3个小时的时间（节省了200多个小时）。红线表示我们按照一定速度拒绝简历并让通过简历筛选的候选人参加所有的面试。虽然这只是虚拟的场景，但它告诉我们，尽早拒绝不合适的候选人会为我们节省很多时间。

黄线最接近真实情况：只在第一轮拒绝候选人。或许你会想：拒绝一份糟糕的简历只需要很短的时间，这个真的是微不足道。花在筛选简历上的时间最多只有5分钟，所以我们要着重考虑在后续的面试中花费的时间。我们已经忽略掉了现场面试所需要的差旅成本，如果需要高层参与到面试当中，成本则会更高。

从我的经验来看，大部分招聘团队都要求候选人具备很强的技术能力和软技能。有时候，有些候选人在头几轮面试当中没有表现出出色的软技能，不过他们有可能在后面的技术面试中通过技术能力来弥补。

如果你让候选人进入下一轮，那么就要相信他们会在后续的面试中有良好的表现，甚至相信他们能胜任这份工作。

不要抱着“试一试”的想法让候选人进入下一轮，或者认为他们在实际工作当中可能会表现得更好。问问你自己，仅靠你对他们有限的了解，你愿意与他们一起工作吗？

让对的人参与进来

好的敏捷实践总是能够让正确的人参与到讨论当中，你的招聘流程也应该这样。如果你的团队不需要向高层汇报日常工作，那么高层就不需要过度地参与到招聘流程中。C级别的高管（Chief开头的高管）当然需要过问招聘的事情，但他们的主要工作还是把握公司的发展方向，不需要在招聘这件事上事必躬亲。如果高层花很多时间在招聘上，那么你的工程团队里也存在同样的模式。

招聘专员不能完全取代团队的招聘工作，不过他们可以为工程团队节省时间。他们可以在网站上发布招聘信息，筛选简历，然后安排面试，但他们不能单独定义招聘策略或流程。这个原则同样适用于“人事”部门。

我想再强调一次：不应该由技术招聘专员定义招聘策略或流程。他们的职责在于降低招聘的成本。如果你依赖他们来给你的团队招人，那么无异于让他们来定义你的团队。

测试驱动式的招聘

测试驱动开发不管是在理论上还是在实际当中都是一个很好的实践。一个好的TDD流程包括：

• 在开始编码之前定义好验收标准。
• 为测试做好准备。
• 找出边界情况。

如果我只是为了吸引眼球，完全可以写一篇类似“每个技术招聘者需要知道有关TDD的10件事”这样的文章（或者“你的招聘流程与React和Angular一样愚蠢”）。我认为你应该在你的招聘流程中应用TDD，因为它真的是一种很好的流程模型。除此之外，还因为你的招聘流程将会影响到你的团队。候选人也因此可以了解到你的团队文化以及你对他们的期望，同时为每一个参与招聘的人提供了实现想法的机会。

定义验收标准

TDD、BDD或敏捷的起点都是一样的：在动手实现之前先把事情想清楚。借鉴他人的经验来改进你的招聘流程自然是一件很容易的事情，不过不要只是简单地模仿。我不会告诉你们我最喜欢的招聘方式，因为我不希望你们太过依赖于博客上的内容。

在一个好的软件工程团队里，你会在编码之前先想好代码需要完成哪些功能。如果你是一个前端开发人员，你会与利益相关者沟通，这样就会明白他们的期望是什么。如果你在开发一套API，你会与API的重度使用者沟通。如果你在做性能优化，你会先搞清楚你的目标是什么，以及如何验证是否已经达成目标。

类似的，在面试之前，先想清楚你想要招什么样的人。与用人的团队沟通，问问他们的需求是什么。想想你最喜欢和最不喜欢的同事。不要忽略了哪些你不喜欢但是对团队很重要的同事。能为团队带来作用的人都有哪些特点？他们身上有哪些不足？在想清楚这些问题之后，开始进行你的面试，就像运行测试用例那样。先进行冒烟测试，然后是更复杂的验收测试。

如果你希望候选人能够马上上手工作，那么就看看他们会不会使用真实的开发工具。如果你想要学习能力强的候选人，那么就面试他们学习新技术的能力。

记住，好的测试并不是要最大化测试的通过率，而是要测出代码的行为是否符合预期。在测试按下按钮是否能触发指定的事件时，并不需要显式地测试按钮是否存在（假设如果按钮不存在就不能点击）。类似的，你的招聘流程不应该总是验证与候选人不是很相关的事情。除非你真的需要候选人能够背出很复杂的算法或者能够用马克笔手写代码，否则不要试图去验证他们是否真的能做到这些。

最糟糕的情况是，如果你没有定义好清晰的验收标准，你有可能招到错误的人。那么最好的情况呢？最好情况是，你招聘流程的大部分仍然带有不确定性。

找到你的期望，并验证它的可行性

在定义好期望输出（合格候选人应该要具备的特征）后，需要验证它的可行性。不要在虚拟的环境里进行验证，如果一定要这样，起码要在相对准确的虚拟环境里进行。例如，在Angular里，一个糟糕的单元测试会要求模拟一个毫无用处的服务，而一个好的单元测试会比较函数的实际输出是否与预期一样。

如果你在招聘信息中列出了你们的期望，那么可行性验证在筛选简历的时候就开始生效了。如果候选人只是单纯地在简历上列出一堆技能和工具，那么你可以直接忽略他们。好的简历需要有候选人过去的工作经历，你可以检查他们过去的经历是否符合你的期望。

其次，使用正确的方式面试候选人，确保可以测出他们真实的水平。对于不涉及写代码的电话筛选和技术初试，可以使用一般性的问答。比如，可以问他们“告诉我当……”，然后深入探讨某些特定的话题。如果他们的回答模棱两可，要想办法让他们给出一个准确的答案。比如，如果一个函数返回3，那么就不应该只是测试它是否可以返回一个整数。如果他们拿不定主意，一定要让他们给出准确的答案，而不只是泛泛而谈。

在现场技术面试时，让他们写代码。不要丢给他们在实际工作中不会碰到的算法题，不过可以给他们你的同事最近解决过的问题，或者把你的团队还解决不了的问题抛给他们。总之要用真实的问题来测试他们。

不要忘了边界情况

除了一般性的问题，还需要测试你的团队或公司所独有的问题。如果你是一个咨询公司，那么在面试过程中要给候选人施加压力，看看他们如何处理情绪问题。我不是在开玩笑：如果工作岗位要求候选人具备良好的心理素质，那么在面试中就要测试他们的心理承受能力。如果工作岗位要求候选人在入职后前几周就要写出具有可读性的代码，或者要求候选人绝对遵从每一条指示，那么就要求候选人在简历上附上代码，并拒绝不遵从指示的人。

这还包括一些“额外”的标准。你的团队除了对候选人有基本的要求，还希望候选人能够具备一些特长。这个可以在简历筛选、文化契合或代码测试中发现。如果你正在开发一款与真实设备交互的应用，那么你要确保候选人具备处理异步事件的技能，虽然这些技能可能只是偶尔会用到。即使候选人可能不知道如何完美地解决问题，你还是能看出他在工作是如何面对挑战的。

我的建议是测试候选人能够表现得“超出预期”。对于一个毕业生来说，我会看他的实习经历和参与过的编外项目。对于一个工作过一段时间的候选人，我会看他对开源社区的贡献情况，或者在他的本职工作之外还做过些什么。如果你希望候选人能够超出职位的预期，并且能够快速地自我成长，那么就可以找那些在过去就曾表现得超出预期的候选人。

沟通好过文档

在一个沟通积极的小团队里，几乎可以不需要任何文档。而在一个缺少沟通的团队里，再多的文档也无济于事。用于招聘的工具林林总总，不过简短快速的交流胜过最好的打分系统，比如“我对这个人很感兴趣”或“他们虽然与我们的文化不契合，不过我认为他们在技术面试中会有出色的发挥”。文档无法替代培训和人与人之间的信任，也无法替代尽早的沟通和开放性的谈话。

可以先结对，但也要信任他们

我个人很讨厌结对，我觉得这样很无聊。我讨厌它的高效，因为这意味着我找不到好的理由来拒绝它。尽管我们不喜欢结对，但要让新的团队成员尽快融入项目，结对是最好的方式。不过，在一段时间之后，必须淡化这种联系，让他们独立写代码。

类似的，培训招聘团队最好的方式是让他们与有招聘经验的老手结成对，然后再让他们独自主导面试。如果你希望你的团队能够独立地做出好的解决方案，你必须信任他们。

记住，这不仅仅是关于用“正确的方式”做事，这种习惯也会影响到团队的运作。新人会从中了解团队的文化和团队对他们的期望。让新人参与到面试流程中会把那些倍感被信任的候选人吸引到你的团队中来。

先与你的团队沟通

有时候，我们会被一个问题困上几个小时，而有人只要30秒就能把问题解释清楚，为你省下大量的时间。

年底的时候，我会看到很多候选人进入终面，但他们本来是走不到这么远的。电话面试“没问题”，技术面试也“没问题”，但这两轮的面试官都觉得候选人并没有给他们留下深刻的印象，或许让他们通过是一个例外。但其实只需要几分钟的谈话就可以省下很多招聘成本——飞机、酒店和参与终面的每一个面试官的时间。

在进行技术面试时，我会先了解候选人在电话面试中是否表现突出，如果有必要，我可以尽早地结束面试。只要少许的交谈就可以决定要不要结束面试。

超越服从、检查清单和形式

Kouzes和Posner在《Credibility》这本书里写道，“威胁、权力、职位和金钱无法换来允诺，它们只能换来服从。服从是妥协，并非卓越”。如果你必须问候选人一些问题，可以准备一个问题清单，但清单无法替代交谈。面试越是形式化，候选人愿意花在交谈真正重要的事情上的时间就越少。

在面试过程的每一个阶段，每个面试官都应该与还没有被拒绝的候选人交谈——不只是通过Slack或电子邮件，还有电话或其他即使通信工具。如果在第一次打分时用掉了10分钟，导致没有时间交谈，那么就放弃第二次打分，然后把这10分钟用在交谈上。你对候选人的打分有可能派不上什么用场（你从那些数据里获得的信息几乎都可以通过候选人的特质反映出来）。

为你的团队招聘，而不是我

如果你想在这里找到一些算法和面试题，我肯定你会失望而归。你可能会觉得我做了很多有关如何促成优秀工程团队的假设。没错，如果你认为一个优秀的团队需要做到快速回应、测试驱动和积极沟通，那么你的直觉是对的。但是你要知道，你的公司文化和流程并不会在雇佣了候选人之后就能立即发生改变。

没有人认为招聘是无足轻重的。管理和组织流程的最大问题来自于价值的不对称，也就是说一套做一套。重点不在于招到“最聪明最好的人才”，你必须意识到，你在招聘过程中的表现在一定程度上体现了你的团队价值观。

如果你是小公司的一个C级别高管，那么你要信任你的团队，在招聘过程中授予他们一定的自主权，相信他们能够承担起自己的职责。如果你是一个团队负责人，并希望你的团队能够成为公司里成长最快的团队，那么就绕过技术招聘专员，自己去招聘人才。记住，真正重要的不是你口中所说的招聘目标，而是你实际做了什么。