领英上有不少公司CEO，声称可以在五分钟内通过简单的对话甄别出合适的候选人，实际是违科学。本文将揭示面试开发者的科学之道。

我对领英上那些大言不惭的帖子快要失去耐心了，帖子里一位刚出道的科技公司CEO这样说道："我不需要对候选人进行为期一周的面试和多次的评估，只需要与候选人进行对话，就可以在大约五分钟内判断他们是否可以胜任这份工作"。

事实果真如此吗？非也。尽管较短的面试是个不错的选择（过长的面试可能会吓跑最抢手的候选人），但事实证明，"边喝咖啡边谈话"式的面试很糟糕，它的结果并不比随机选择来得更好。

我们从那些CEO身上看到的并不是非凡的直觉或者社交技能，其实只是邓宁-克鲁格效应（Dunning-Kruger effect），是一种认知偏差，能力欠缺的人有一种虚幻的自我优越感，会错误地高估自己的真实能力，而且他们越差，高估的程度就越高。面试就是被研究得最充分的例子之一。不经过提前准备，世界上没有一个人可以在五分钟左右的对话中评估出某人的工作技能，即兴对话并不是面试，仅能达到见面聊天的效果。然而，有些雇主仍坚持认为，这是挑选出优秀候选人的最高效的方式。

一次又一次的研究表明，这样的做法是错误的。天马行空，没有体系的面试会大大增加各种偏见，给面试官的个性发挥敞开大门，并最终大幅降低招聘的准确性，结果可能比跳过面试随机挑选还更糟糕。更严重的是，错误的候选人可能会造成公司上百万美元的经济损失，并导致项目的大幅延期。

编程考察和能力证明

对于程序员来说，糟糕的面试尤其让人沮丧。而编程则是一项特别纯粹，能证明自己能力的考察项。你仅仅通过肉眼，无法评估一座桥的质量或者一顿饭的准备工作量，但是代码就不一样，他特别纯粹，所见即所得，好或者坏一目了然。不需要过多复杂的设置，候选人就可以展示自己实时编写优雅代码的能力。然而，许多公司却反其道而行之，经常提出一些与他们正在招聘的工作完全无关的奇葩题目。

我们大多数人都有过切身的体会。你正在面试你的第一份程序员工作，而面试官却想知道元素周期表上的哪个元素最能体现你的个性；你是一位资深的前端开发，但是在长达一小时的面试时间里，却都是一些"坑爹"测试题，比如closures(闭包)和hoisting(变量声明提升)的用法；你从零开始搭建过多个.Net应用，但面试官却希望你反转二叉树；你已经为Linux内核代码做出贡献，但现在你必须猜测出面试室内可以容纳多少个乒乓球。这一切都让你觉得崩溃。

在当前程序员炙手可热，工资飞涨的市场环境下，这样的现象令人不解。越来越多的公司为了提升吸引力，允许远程办工，部分初创的科技公司还提出一周只工作四天的优厚待遇，猎头更像诈骗犯一样疯狂地想联系到我们。但是如果被录用的候选人不能胜任这份工作，这一切不都白费了，那为什么公司不愿在招聘阶段花费更多的投入呢？

优化后的面试流程

下面让我们来谈谈理想的编程面试应该是什么样子，如果你的工作是写Java代码，那么流程可能是这样的：

1. 在第一次接触候选人时，披露薪资范围和福利情况

2. 提前查阅候选人的简历，了解他们的Java专业度或者开源经验(任何其他的编程语言也类似；Groovy和Kotlin可以类比)

3. 在现实环境中观察候选人近一小时的Java编码情况，并根据预先制订的、与工作相关的维度对他们进行评分，如问题解决、空值安全、错误处理、可读性、命名规范、封装度等

4. 进行规范化、标准化的评估，考察候选人对JVM和基本命令行工具的熟练情况

5. 让候选人知道什么时候可以接到后续通知

就是这样，拒绝天马行空的"文化面试"，拒绝"小组测验"，拒绝"编译器优化测验"，拒绝让候选人在业余时间从头开始搭建一个15小时的项目。你只要正常评估他们的某项工作技能就可以了。

当然，这并不是说我认为编码能力(或者其他一项技能)是候选人唯一重要的事。诚然，你想雇佣到可靠、聪明、诚实和善良的人，但你必须将自己的要求限制在可知的范围内，就工作面试而言，选择没有很多。大多数应聘者在求职面试中表现得很虚伪，其中绝大部分的人会撒谎。即使假定应聘者很诚实，十有八九的人还会有面试焦虑。如果你想真正了解某人在工作中的表现，你根本不能依赖面试，那些都不是他们真正的样子。当然了，如果你看到任何不良的信号，比如对待接待人员十分无礼，你大可以直接扔掉他们的简历，不过这也通常很少见。

这也是招聘的固有弊病：面试并没有我们想像中那么强大。许多雇主尝试使用软技能和人格测验的面试方法。但是，任何超出实际、不可衡量的指标通常都是一种错觉，尽管看上去令人信服。2013年的一项研究表明，即使候选人的回答是随机挑选的，面试官也会对候选人产生高度自信的印象！人们倾向于相信第一印象，无论他们是否准确，这都会造成招聘过程中的失误。任何仅通过直觉了解其他人的测试方法，都会降低结果的准确性，唯一可以准确衡量的只有任务能力。

测试编程能力的方法

这样说来，如果现场编程是我们能做的最好选择，那么衡量编程技能的理想方法是什么？不少商业产品如LeetCode，提供了一套编码平台，并配有许多预先设计好、可以自动评分的任务用来测试候选人。尽管他们比常规的方法要好得多，但我们并不打算推广。你想一下，你的团队整天都在做针对性的、有现实意义的面试评测，你为什么要采用另一家公司的通用评测方法，并且还是付费的？最近一次我在设计编程测试题时，就从我的日常工作中选择了一段比较优秀(不是"胶水代码")但不涉及任何公司业务的代码，对其进行调整以便能自己独立运行，并将函数签名复制到LINQPad(一个.net的代码运行平台)平台上，而候选人的任务与我的工作需求很相似，要求实现这个函数。当他们完成时，我就知道他们是否可以胜任这份工作，基本上没有比这更具实际意义的评测方法了。

此外，到目前为止，我经历过体验最好的面试流程，是与一家初创公司签订了一份为期一周的合同(一些公司称之为"试镜")，在这一周里我与他们的团队合作，他们给我分配任务，我克隆了他们的仓库代码，用了几个晚上的时间编写并提交了PR(Pull Request)，团队的其他成员给出了反馈意见，我根据反馈修改代码以达到他们的标准，最后他们将代码合并，并按我的时薪标准支付了薪水。尽管我最终没有接受他们的offer，但大家实现了双赢——他们完成了一些额外的工作，而我得到了薪水。如果我接受了，通过一周的工作，证明了我的技能和团队合作能力不会有任何问题。多年后，如果我仍要找工作，这家公司仍在我的候选名单上，因为这种面试方式相当靠谱。

也许这种方式不是你认为的面试，但我要说这比面试好得多。你能想象花费5分钟与CEO们闲聊然后决定面试结果有多可笑吗，这些CEO甚至都不会编码。

出于安全或者公司规定等原因，一些团队可能无法采用上述这种面试方法，在这种情况下，你应该尽量保证面试流程的统一。如果你不能让面试看起来像是工作，至少让每次面试都遵循相同的流程体系，并且在相同的指标上比较候选人。

帮助候选人达到最佳状态

一套标准统一，方法科学的面试流程也可以进行灵活的调整。每个候选人都有不同的要求，不必为了标准化，被一些与面试指标无关的事项损害到个人或者团队。例如，免疫力较低的候选人要求选择远程面试以保证他们的健康；有身体或者神经疾病的候选人期望分段面试以便休息，而不是一场三小时的面试马拉松，这样他们可能会表现得更好；一些有面试焦虑的候选人可能需要在面试前一两分钟与面试官建立友方关系，而对于其他人来说，他们宁愿跳过这部分闲聊环节。你应该始终根据候选人的需要来调整面试的环境或者节奏，像这样的调整是双赢的，因为这样让每个候选人都有机会展示出他们最佳的状态。如果你想找到最好的候选人，你就需要根据他们的最佳状态来判断。

此外，面试也是一个双向选择的过程，你在评估候选人，候选人也在评估你的公司和团队。如果因为候选人提出一些要求，而这些要求不在标准流程之内就拒绝他们，那是得不偿失的。

你希望获取到客观的、可比较的面试指标，候选人则希望获到合理的便利和帮助，那么如何调解这对矛盾呢？可以采用软件设计上的一条著名规律，即稳健性原则："对自己的工作要保守一些，对别人接受的事情要开放一些"。在面试中应用这一原则，那么你应该在标准化和相关技能的考察方面表现得保守，而在候选人需要帮助的方面表现得自由开放一些。这样，两全齐美，你既能获取到想要的指标数据，候选人的表现也不会被不必要的条条框框限制住。

总结

经过数十年的研究表明，结构化的、真实的、聚焦工作内容的面试才是黄金法则。所以，当你决定使用计划外的面试流程，或者某些无法量化的评估指标时，你应该问自己，我是不是想选出一位不合适的候选人。

当然，有时候仍然会看走眼，让不合适的候选人混水摸鱼，但这是无法避免的事。最好的面试机制也只能保证结果大部分是准确的。所以不要害怕偶然的失误，而再依靠直觉去评估候选人，计算机还偶尔会死机呢，但人们能回到手写笔算的时代吗？

科学的招聘机制也许是公司相对于竞争对手而言最大的优势，而要做到这一点，最佳的途径就是专注于你能考核能量化的指标。

译者介绍

李腾辉，51CTO社区编辑，目前在一家东南亚互联网金融独角兽担任资深Java工程师，负责金融借贷平台架构设计及核心建设工作，对互联网金融架构、微服务体系有较深入的研究，期望在互金领域持续深耕。

原文标题：The science of interviewing developers，作者：Isaac Lyman

链接：

https://stackoverflow.blog/2022/05/23/the-science-of-interviewing-developers/