技术面试流程出了什么问题？

人们似乎越来越一致地认为，科技公司招聘技术人员（尤其是开发人员）时常用的面试流程存在缺陷。大约一年前，我在一篇讨论当今科技行业面临的问题的文章中，就曾指出这是一个重大问题。可以肯定地说，自那以后，这个问题一直没有得到解决。

不费吹灰之力，Twitter、Hacker News 以及各种博客上都在讨论这个问题。这些问题似乎可以归结为三点：

1. 编码测试是任意的、不必要的困难并且与工作实际所需的技能脱节。
2. 面试轮次和时间要求很难管理。
3. 招聘决定往往显得武断，而且关于某人未能通过某个阶段的原因的沟通往往很不畅通，甚至根本无法沟通。

让我们仔细看看每一个。

编码测试和白板

让我们从编码测试和白板开始，因为这可能是开发人员提到的最常见的挫折。

开发人员对编码测试的主要不满在于，测试难度过高，而且经常随意性很大。许多人都表示，他们被问到一些复杂的计算机科学概念和算法，这些概念和算法他们可能在大学里学过（假设他们是计算机科学专业的），但之后就没必要参考了（即使需要，他们也只是查一下）。

我不应该在面试中依赖算法题抽签来证明自己的技能和能力。运气和偶然性不应该成为技术面试的一部分……这就像测试你的牙医技能，看他们本科化学课上用氧化数法配平氧化还原方程的能力一样。

• Sahat Yalkabov，操你，我辞职了——招聘制度崩了

代码测试或白板测试的问题之一是，它似乎与它所要筛选的工作无关，而且常常被视为一种把关方式。

这些人究竟是怎么断定我技术不够强的呢？猜猜看？如果你说“一个现场编程测试，里面有一道你在codewars.com上能找到的随机脑筋急转弯题”，那你猜对了。别误会，我也通过过这类测试的面试。嗯……这难道不奇怪吗？

• Ambrose Little技术面试存在缺陷，但我们可以修复

在我看来，编码测试主要存在两个问题。首先，这些编码测试与其设计初衷——即考察面试者的技能和知识——之间存在脱节。在我看来，无论是学历、在公司的工作经历、对开源项目的贡献还是业余项目——都比完全脱离实际的随机代码挑战更能体现一个人的技术能力。作为一名开发人员，回答随机的技术问题本身并没有什么特别之处，但这似乎是这个职位独有的实践。

更重要的是，第二个问题是，这种做法优先考虑随机的技术知识（这些知识相对容易学到），而忽略了性格契合度、与人合作的能力、职业道德、学习热情（这些知识并非易事）。你可能是一个优秀的程序员，也可能是一个糟糕的人，但我可以告诉你，这等式中的哪一部分会对你在开发者工作中的成功产生更大的影响。

大量的时间需求

技术面试通常就像一场马拉松。许多职位除了需要耗费大量时间的“家庭作业”之外，还需要进行多轮面试。

这种现象似乎并非家喻户晓的大型科技公司独有。你到处都能听到这样的故事：科技公司把招聘流程当作一个专门用来淘汰那些根本无法在这场残酷的竞争中坚持到最后的候选人的程序。

越来越多的雇主采用毫无意义、昂贵且耗时的额外流程，使他们的招聘流程变得更加缓慢，让求职者更加望而却步。

• 莉兹·瑞安（Liz Ryan），不，你没疯——招聘流程有问题

缓慢或完全中断的沟通过程使问题变得更加严重。

我经历过半天到全天的面试，也就是所谓的“穿越重重障碍”，结果等了一个月才收到拒绝或根本不予回复。这是面试过程的一部分，我们都能克服。（耸耸肩）不过，当你不得不用宝贵的假期去参加毫无进展的面试时，还是很令人沮丧的。

• Milecia McG，《疯狂的求职过程》

沟通障碍通常发生在候选人没有继续参与流程时，这对被搁置的候选人来说无疑是不公平的。然而，即使候选人即将进入下一阶段，沟通也很不畅，甚至完全没有沟通的情况也屡见不鲜，因为他们往往要等上数周才能得到通知。

对于至少在两个方面进行招聘的公司来说，这似乎完全是自取灭亡。首先，它毫无意义地将潜在候选人限制在那些经济状况和/或工作允许他们忍受无数缺勤时间和时间的人身上。其次，它错过了一些中途退出的候选人，他们要么对缺乏沟通和流程冗长感到沮丧，要么当然是那些在本来不必如此冗长的招聘过程中找到了其他工作的人。

任意的招聘决定

最大的问题似乎源于前两个问题，即拒绝似乎是完全任意的——以至于有一个网站专门用于分享拒绝故事，其中充满了开发者社区中知名的名字。

甚至许多参与招聘过程的人似乎也认识到它存在缺陷。

部分问题源于筛选过程（rejected.us上的故事经常证实这一点），根据下文引用的有关 Y Combinator 招聘的研究，该过程占了申请人被拒绝的近一半。

大多数公司在招聘人员电话面试（或简历筛选）时都会拒绝很大一部分申请人。我们采访的25家公司平均有47%的申请人以这种方式被拒（个别公司的比例最高可达80%，最低则为0%）。负责这种拒绝的招聘人员并非专业人士。他们所能做的就是拒绝那些不符合他们所学的求职者条件的候选人。

• Ammon Bartram，Y Combinator 公司想要的人

正如研究指出的，很多情况下，这是因为筛选人员通常不懂技术，因此必须依赖他们提供的个人资料信息。这并不是说筛选人员应该懂技术。我相信，聘请受过培训并专注于招聘的人员有很多好处，但这意味着我们需要更好地确保他们理解个人资料，并获得正确评估候选人所需的信息。

另一个问题又回到了编码测试。它们看似琐碎的性质似乎会导致难以预测的结果。基本上，优秀的候选人失败率相当高，正如以下研究指出的那样。

大约 25% 的受访者表现比较稳定，其余的则表现参差不齐……

对我来说，看着这些数据，然后假装要根据一次面试结果做出招聘决定，感觉就像透过钥匙孔窥视一间漂亮奢华的客厅。有时你会看到墙上的艺术品，有时会看到酒水选择，有时你只能看到沙发的背面。

• Aline Lerner，技术面试表现的评判标准有点随意。以下是相关数据。

筛选、测试和时间的结合可能意味着公司的招聘流程不一定针对寻找最佳候选人进行优化。

这不是一个容易解决的问题

听着，我明白了。面试一个人需要时间和精力，而且你们大多数人只想回去继续工作。想出一个标准问题可以让你事半功倍，还能让你在一定程度上比较不同的候选人。

但确实需要仔细考虑一下这是否选出了合适的候选人。

• Zach Holman：初创企业面试太糟糕了

正如扎克所说，这是一个难以解决的问题，这或许可以解释为什么该系统目前似乎得到了“我们一直都是这么做的”和“其他人也都这么做”的双重支持。这种推理为公司提供了必要的借口，使其能够避免认真审视自己的流程，看看是否真正实现了其设计初衷。大多数公司似乎认为，在最坏的情况下，该系统只会产生大量的误报，而不会产生误报。

看来，企业可以通过问自己以下问题获益：

• 我们的代码测试或白板练习真的能提高我们甄别优秀候选人的能力吗？或者，是否有更相关的练习（例如与日常工作要求相关的合理家庭作业）或标准（例如，可以代替测验或家庭作业来评判的项目经验或开源工作）可能更有用？
• 我们真的需要一整天的马拉松式面试，或者五个以上的面试环节吗？有哪些环节可以省略，但仍然同样有效？我们会因为候选人负担不起我们安排的面试流程而失去他们吗？
• 我们的筛选人员是否获得了正确筛选人员所需的信息？还是我们可能会失去高素质的候选人？我们的标准是否过于具体（例如，JavaScript 或 JavaScript 框架经验就足够了，但我们却专门寻找 Angular）？我们的流程是否似乎导致了大量误判？

这些问题确实很难回答，而且显然很多优秀的候选人仍然设法通过了。但我是这样想的：作为开发人员，我们开发了一套单元测试系统，以帮助防止我们部署有缺陷的代码。这些测试并不总是能检查出会导致整个应用程序崩溃的问题。有些问题可能会导致软件在相当长的一段时间内或相当一部分用户（取决于特定条件）无法正常工作。但是，我们不会允许开发人员仅仅因为应用程序在某些时间段内对某些用户可能有效就部署未通过这些测试的代码。我们的面试和招聘系统目前有大量单元测试未通过。让我们来解决这个问题。