如何招聘程序员

我的两位老读者都知道，招聘和开发者评估是我最热衷的话题之一。或者更准确地说，它们是我最讨厌的两个话题。在我看来（愤怒、恼火、焦躁），我们评估人才的方式在根本上和关键层面上都存在严重缺陷。

由于这种骚动，我已经在这个网站上写了好多篇幅的文章，谈论我认为所有错误的观点。但一些深思熟虑的评论者，在之前的文章中，又把这个等式反过来推到我身上：

如果您觉得这些都是“有问题”的事情，那么您认为评估潜在雇员的“正确”方法究竟是什么？

这是一个公平的挑战。毕竟，坐在场边抱怨所有你不喜欢的事情很容易。而提出一个有意义、可行的改进计划则完全是另一回事。所以，这就是：获得专利的 Adam Nathaniel Davis 程序员招聘计划™。

[提示：这并不像许多公司和招聘经理想象的那么困难或复杂。]

我不想深入探讨如何找到编程候选人。我不是招聘人员。在我看来，优秀的候选人几乎随处可见。但话说回来，我从职业领域内部的角度出发，无疑有点……偏见。我假设你能找到一堆候选人。但你怎么知道哪一个值得录用呢？

非技术性电话/视频面试

我觉得这已经成为大多数招聘流程中相当标准的第一步。坦白说，我对此并没有什么异议。所以，如果你的组织想效仿这种模式，我完全理解。一些非技术人员会打电话给候选人，让他们做一些非常基础或非常高水平的考察。这应该是轻松、简单、简短的——最多30分钟。

在我看来，这类电话的主要目的通常是了解候选人的薪资期望。很多候选人愚蠢到第一次通话就把这个说出来。（注：这绝对是以后文章的主题。）

我对初次面试电话唯一的不满是，除了想知道薪资预期之外，我真的不知道候选人在这种电话面试中还能做什么才能被淘汰。我自己也接过这类电话，经常会被转到第二轮面试，即使我告诉面试官我必须缩短面试时间，因为我正在地下室里活剥某人的皮，他们的尖叫声让我听不清问题。

我确实认为，如果职位本身有任何独特或非标准的方面，这些电话面试对双方来说都是有价值的。例如，如果你打电话给波兰的某个人，但工作地点需要调到玻利维亚，那么从非技术性筛选开始是合理的。如果这个“机会”对候选人来说完全没有吸引力，就没必要浪费大家的时间。

这也是一个很好的地方，可以用来解决职位机会与候选人简历之间任何明显的高层不匹配的情况。例如，他的简历上可能同时包含 BA 职位和编程职位，但你招聘的是一个纯编程职位。候选人是否愿意接受这种情况？

虽然这种筛查通常很简单，并且很难“搞砸”（对于任何一方而言），但我从非技术筛查人员身上发现的一些习惯让我感到很烦。

比如，我都不知道有多少次遇到过这样的场景：一位招聘人员联系我，说：“这是 XYZ 公司一个职位的详细信息。我可以提交你的简历吗？”我同意了，很快安排了一次技术筛选，但首轮面试的剩余对话大致如下：

筛选员：那么你是怎么知道 XYZ 公司的？
我：一位招聘人员在 LinkedIn 上联系了我。[光是说出这种话就让我感觉自己有点傻。我的意思是，几乎每个我想争取的机会都是从……一位招聘人员在 LinkedIn 上联系我开始的。 ]

筛选员：我明白了。那么，你对 XYZ 公司了解多少呢？
我：我知道你们的招聘人员在 LinkedIn 上联系了我，所以才打了这通电话。

筛选员： [滑稽笑声] 哦，当然。好的。但是……你为什么想为 XYZ 公司工作？
我：我不知道自己是否想为 XYZ 公司工作。你打电话给我了……

筛选员： [更多调侃的笑声]
我：听着，我得走了。我正在地下室活剥人皮，尖叫声让我很难听清你的问题。

技术电话/视频屏幕

这也是许多公司招聘流程中相当标准的一个环节。我对此并没有什么异议。事实上，在某些情况下，它确实能带来价值。但这里有一些重要的“陷阱”，我真的需要你理解：

1. 这绝对不应该当面进行。即使你招聘的是严格意义上的现场职位，我也不在乎。技术面试中的一切问题都可以通过电话/视频高效地处理。将面试环节设置为纯粹的远程环节，既能节省你自己的时间，又能尊重候选人的时间。

2. 与非技术面试一样，这次面试不应超过30分钟。面试的目的不应该是让候选人用30分钟的时间滔滔不绝地讲述他的整个简历，也不应该深入探究他的技术知识。面试的目的应该只是确保候选人能够熟练地使用“程序员术语”。如果你不能在半小时内完成这次面试，那你就错了。

3. 这次面试应该考察应聘者对一般概念的掌握程度。没错，这些概念可能比较“技术性”，但仍然应该比较高深。更多地关注编程语言（例如 JavaScript），而不是框架（例如 React）。最好关注更广泛的概念（例如 Web 开发原理）。不要耍小聪明，比如问应聘者某些语言​​内置函数的默认参数。不要问一些“陷阱”问题（例如，“JavaScript 中 A 的null计算结果是什么类型？”）。面试的目的不应该是让应聘者被一些深奥的概念难倒。真正的目的应该是验证应聘者是否真的是一位至少对关键概念有基本了解的程序员Function。如果你问应聘者构造函数和函数声明的区别，那你就错了。

4. 就本次筛选中要使用的问题达成一致，并向每位候选人提出相同的问题。这是我最讨厌的事情之一。乔负责你的一些技术筛选，他会问一些简单的问题。玛丽负责你的其他一些筛选，她会问一些尖锐的“陷阱”问题。这种做法很不礼貌，会影响你的评估。

5. 认真考虑一下，把这种筛选条件设定成基于应聘者经验的筛选。换句话说，如果你在和一个有30年经验的程序员交谈，让他们接受这种筛选就太荒谬了。是啊……我已经听到你们有些人在尖叫，说你们根本不知道应聘者的经验/简历是否真实，所以才要对每个人都进行同样的筛选。对此，我的回答是：别自以为是了。如果有人真的伪造了简历，仍然有很多机会揭露他们。（而且，快讯：这种明目张胆的伪造行为非常罕见。）当我接受这些筛选时，我一点也不介意。但这真的很浪费时间——对我和雇主来说都是如此。我知道这听起来很自大，但我不在乎。无论如何，我还是要说：如果我申请一个 JavaScript 职位，并且在 30 分钟的电话技术筛选中“失败”，那么这更多地说明你的技术筛选有问题，而不是我的技能有问题。
   
   
   

编码评估

好的……现在我们来谈谈招聘流程的真正“核心”部分：令人畏惧、经常出错、甚至被人诟病的编程“评估”。有人已经通过了你最初的非技术筛选和技术筛选，但现在你想知道他们是否真的会编程。所以你应该这样做：

[注：借助现代工具，远程员工/面试应该与面对面会议一样易于管理。
屏幕共享和协作代码工具（例如 StackBlitz）现在让在现场环境中观看某人编写代码变得非常简单。]

1. 让候选人坐在真实的、实时的编程环境中。如果是面对面面试，请准备好工作站。如果是远程面试，只需让他们边工作边与您共享屏幕即可。如果有多名评估员，请确保他们全都在场并能够观看整个过程。

2. 要求候选人开始编写一个基本的应用程序。它几乎可以是任何东西。它可以是一个待办事项应用程序，一个井字游戏应用程序，一个战舰应用程序，或者……任何东西。如果你需要看到候选人创建一个极其复杂、深奥的功能，为你的认证用户群体实现实时视频流，并进行内容控制和广告投放的动态跟踪，那么你的做法就错了。

3. 告诉应聘者，他们只需要写一个小时的代码。没错，就一个小时。不能再长了。

4. 还要告诉他们，他们预计无法在这段时间内完成应用程序。如果你认为编程评估就是给候选人一项需要几个小时才能完成的任务，那你就太混蛋了，而且你还会让公司失去考虑许多高技能、经验丰富的候选人的资格，因为他们根本懒得花一下午的时间来开发你的演示应用程序。

5. 告诉候选人，他们不必专注于用户体验的细节。除非这个职位几乎完全专注于用户体验，否则你不应该纠结于候选人是否部署了简洁、美观、响应迅速且直观的<Grid>控件。你应该寻找程序员。

6. 鼓励他们在写解决方案时进行讨论。他们提出的任何澄清都是有用的，能让接下来的问答环节更加顺利。

7. 告诉他们，虽然他们不需要完成整个应用，但如果他们想“去掉”通常会实现的基本功能/组件/特性，那也没问题。比如，如果他们通常会实现一个异步调用的包装器，那么他们完全可以“去掉”该功能，而不必从头开始构建。

8. 让候选人用他们喜欢的任何语言/框架来编写应用程序。没错，任何语言/框架都可以。如果你觉得这听起来很荒谬，那么你绝对不是在筛选合适的“技能”。你在寻找的是那些恰好掌握了你所选技术栈的人。你不是在寻找硬核程序员。你绝对应该寻找的是硬代码程序员。

9. 一小时结束后，让候选人停止编码。他们可以继续在屏幕上展示解决方案。但你绝对应该尊重他们的时间，不应该指望他们为了把所有细节都做到位而延长时间。

10. 编码环节结束后，应该与评估人员进行问答环节。该环节也应该严格控制时间。通常三十分钟就足够了，但一个小时也不算太长。如果你真的需要与他们交谈超过一个小时，那么你可能本来就不喜欢他们的解决方案，而且你也不太可能考虑给他们发 offer。

而且……就是这样。不，真的。就是这样。现在你肯定快要中风了，对吧？？？

反对意见

如果你现在感觉有点激动，没关系。真的。我理解。这跟你们的招聘流程不符，你们那道貌岸然的招聘流程里的每一步都神圣不可侵犯，对吧？所以，请允许我谈谈我在提出这种流程时遇到的一些最常见的抱怨。

我们没法花那么多时间看所有候选人写代码一个小时！之后还要花时间跟他们交流！

让我先把事情说清楚。你打算给这个人开一份薪水，在很多地区，这个薪水可能远超10万美元。你会投入无数的时间让他适应你的环境。但你不能提前花几个小时和你的团队一起，真正地观察他写代码吗？好好想想……

我最近为一位潜在雇主做了一个“编程挑战”。我独自一人花了几个小时编写了解决方案后，他们让我和他们三位最资深的员工见面，花了超过一个小时详细讨论这个解决方案。之后，他们安排了第二次电话会议，还是和同一批人，详细讨论我编写的代码的一些细节！（顺便说一句，我收到了这份工作——但我没有接受。）

但这比你想象的要长得多！我们有很多候选人需要评估！

那么你的预筛选流程就有问题了。如果你想看十几位（甚至更多）候选人的编码评估，那么要么是你的候选人素质高得离谱，要么是你的预筛选流程需要再“精简”一点。

假设你确实有十几位（甚至更多）看起来都非常优秀的候选人。我仍然很难相信其中一些候选人竟然没有排在你的层级结构顶端？如果有些候选人看起来比其他候选人更有资格，答案很简单：先面试最优秀的候选人。然后，如果出于某种原因，这些“顶尖”候选人没有被录用，就把他们从名单上往下移一点。

这段时间不足以让一个人展示出我们需要在潜在程序员身上看到的所有技能！

那么你需要认真质疑你的评估员的资质。说真的。每次我第一次和别人一起编程（或者只是看他们编程），我都能相当准确地评估他们的技能水平。而且我通常在几分钟内就能“读懂” 。如果你看了我整整一个小时的代码，仍然不确定我的知识水平是否足以胜任这项工作，那么我保证我不够。

但是通过强制候选人自己进行编码评估，我们节省了大量时间，因为我们可以在需要费心将任何人拉入现场面试/评估之前淘汰许多候选人！

啊，是的。所以你承认自己就是那种觉得让一大群资质存疑的候选人做“带回家的评估”（也就是让他们做免费工作）很酷的混蛋。而且，如果提交的材料没通过你的“嗅探测试”，你就直接终止他们的候选资格？甚至都不提供任何反馈，说明他们的材料到底是怎么“不合格”的？

是的，明白了。我完全了解你是哪种类型的雇主。我一点也不想为你工作。你猜怎么着？越来越多的优秀求职者已经得出了同样的结论。

我们不能让人们使用“他们想要的任何语言/框架”进行编码，因为我们需要真正的同类比较！

所以你的意思是，如果你的环境完全依赖于 Angular 和 Node，你认为我用 React（哦不！）和 C#（我的天！）编写的那个牛逼的解决方案根本无法移植到你的技术栈上吗？如果我真的用 React/C# 写了一个可靠的解决方案，你真的认为我需要花费大量时间才能把这些技能“转化”到 Angular/Node 上吗？拜托，哥们……

破坏评估？？

如果我之前的建议让你撕扯衣服并咬牙切齿，那么你一定会喜欢这个建议：有时，你绝对应该考虑完全绕过编码评估！

不，我通常不会建议彻底放弃你的编码评估。但你真的应该好好想想，你给哪些候选人安排了哪些任务。

我现在有一个相当完善的 GitHub 个人资料。它包含已上线且可公开访问的应用程序的代码。它包含我所有 NPM 模块的代码。它包含许多其他编码评估的代码。如果您对我所写的内容（或者我是否编写过）有任何严重疑问，这完全合理。我们可以对我已经编写的大量代码进行实时审查。我可以向您讲解我所做的任何设计选择。我甚至可以实时为您进行小幅修改，以证明我拥有这些代码，我彻底理解它，并且我知道如何安全地更新它。

这听起来可能有点傲慢。（我一点也不在乎。）但简单的事实是，如果你让我写一个新的小型演示应用程序，而我已经有大量的实时、高质量代码，甚至可以直接应用于你的环境，那么你的“测试”通常会相当……烦人。

我已经听到招聘经理的辩护词了，他们会说：“好吧，如果你懒得做我们的编码评估（这其实就是你之前公开发布过很多次的东西的另一种变体），那我们不想录用你。” 这……太棒了。真的。确实如此。但请记住，你的招聘流程几乎肯定会导致很多其他经验丰富的候选人（那些已经有工作、并不一定需要你提供的绝佳机会的候选人）干脆完全“退出”整个流程。