编码测试淘汰了一些最优秀的候选人

与应用程序开发相关的职业领域，既有美好的一面（也可能是丑陋的一面）。作为该领域的资深人士，我有机会亲眼见证其中的美好与丑陋。这种二分法的核心在于我们所做工作的内在可量化性。

量化之梦

一方面，应用程序开发在众多专业领域中颇为独特，因为它本质上是可量化的。我的意思是，你不必仅仅依靠某人的言辞来评估他们的编程能力。如果方法得当，你就能真正看出候选人是否真正具备他们在简历中（无限可塑性）所宣称的技能。

如果某人（从简历上看）看起来像是一位出色的项目经理，那么要判断他们是否真的具备在你的环境中妥善管理项目的技能，因为他们需要与你的团队互动，将会非常困难。他们的简历无疑充斥着你在优秀项目经理身上通常寻找的所有字母缩写。但任何稍有头脑的人都能轻松地在简历上输入这些缩写。然后，你需要在面试过程中，确定他们是否真的是一位优秀的项目经理，是否具备他们所声称的技能和经验。

但是应用程序开发的感觉……不一样，对吧？我的意思是，如果有人声称自己是某种语言（或多种语言）的顶尖开发人员，并且他们发誓说他们已经在其他环境中为其他雇主编写了你想要的所有代码，那么你应该能够看到他们所能完成的工作，对吧？我的意思是，到最后，你应该能够告诉他们，“好的，那就给我看看……”理论上，我们可以观察某人编写代码——最好是实时观察——来确定他们是否真的是他们自称的程序员。

从理论上讲，这种通过实际行动展现个人编程能力的能力，只有现代工具才能真正发挥作用。我们可以安排由 HackerRank 或 Codility 等第三方网站（或许多其他网站）管理的编程测试。或者，我们可以进行屏幕共享，让他们当场演示编程技巧。或者，用最“老派”的方法，我们可以把他们拉到一个实体办公室，让他们用白板写下解决方案——当然，房间里应该还有其他值得信赖的开发人员在场，评估和点评他们的工作。无论具体采用哪种方法，在考虑是否提供录用通知之前，我们都应该拥有所有必要的工具来量化评估一个人的编程能力……

正确的？？？

嗯...有点。

白板面试的风险

我职业生涯中面试过的很多公司都严重依赖白板面试。他们会把你拉进办公室，让你坐在白板前，然后要求你编写某种名义上的解决方案。与此同时，他们的内部开发人员会观察并评估整个过程/结果。

这种方法并非完全错误或糟糕。事实上，它确实可以带来非常成功的招聘。但如果雇主不够谨慎，这种方法也存在一些潜在的风险。其中一些（但并非全部）风险包括：

• 很多优秀的程序员面试能力很差。
  如果他们真的优秀，可能就不会从事应用程序开发了。他们会去人力资源部门，或者去招聘。但他们既不是人力资源部门，也不是招聘部门——因为他们的主要技能是编程，而不是人才评估。我见过很多被拉去面试的开发者，他们脾气非常暴躁，这可能会让一个很有前途的候选人变得神经紧张。（他们一辈子盯着电脑屏幕，很少与其他人互动，这是有原因的。）我遇到的一些程序员在进行白板面试时，其实会过于宽容。他们会提出一连串荒谬的诱导性问题，而一个精明的候选人即使不了解面试的核心问题，也能成功地“回答”这些问题。我甚至见过面试官走到白板前，为候选人写出解决方案，然后在面试结束后，一本正经地说候选人“通过了”。
  
  

• 白板面试容易滋生迂腐。
  “真正的”程序员往往生活在IDE中。他们已经习惯了IDE内置的快捷键和代码补全功能。所以，当你让他们坐在白板前，让他们随便写点代码时，即使是最优秀的开发者，有时也会写出一些非常……嗯……不完整的代码。这会让他们成为一个糟糕的程序员或一个糟糕的候选人吗？几乎肯定不会。这种类似的限制是可以接受的……只要面试官理解（甚至同情）他们要求候选人做的事情。但我见过太多这样的情况：一个非常优秀的候选人被淘汰，就因为他们在白板上的某些代码如果放到IDE中编译不通过。在大多数情况下，如此严格地遵守完美的语法对候选人来说是完全不公平的。如果提供的解决方案逻辑上合理，但这里或那里缺少几个分号，这不应该成为淘汰候选人的理由。但通常情况下，它确实会成为淘汰的依据。当候选人在白板上写解决方案时，你应该问自己的一个关键问题是：“如果这个人坐在一个功能齐全的开发环境中，是否可以合理地假设其语法中的小错误会被IDE快速突出显示，并由候选人修复？” 如果答案是“是”，那么仅仅因为这个理由就淘汰候选人就是在浪费大家的时间。
  
  

• 白板面试往往是为了测试候选人是否了解/偏好公司指定的代码风格。
  白板面试官（通常是已经在公司工作的开发人员）往往会关注他们已经为公司选择的特定代码编写方式。他们通常会对任何尚未选择该特定代码风格的候选人持怀疑态度。例如，一个 JavaScript 团队可能会要求候选人编写一个解决方案，而当候选人开始在白板上书写答案时，可能会发现候选人选择使用“老式”JavaScript 格式编写函数，而不是使用箭头函数。在许多前端开发人员的白板面试中，这对候选人来说可能是致命的。现有的开发人员已经习惯了只看到箭头函数，开始低声抱怨这个候选人很差劲。从那一刻起，面试中的一切都变得几乎毫无意义。因为公司原有的开发人员已经认定这位候选人无法胜任。需要明确的是，如果候选人开始只写“老派”的函数声明，那么问他们以下问题完全没问题：他们以前用过箭头函数吗？他们理解这些函数吗？如果被要求使用，他们能用吗？在这个特定的解决方案中，他们选择使用“老派”函数声明有什么特别的原因吗？但很多时候，这些问题从未被问过。现有的开发团队只是看着这些“丑陋”的函数声明，窃笑着告诉招聘经理，这个候选人应该被淘汰。
  
  

• 白板任务通常会附带一些令人困惑/模棱两可的口头指示。
  据我所知，没有哪个现代开发团队希望他们的规范仅仅是一套口头指示。但他们却很乐意把这样的口头指示强加给在白板上坐立不安的应聘者。他们可能会问这样的问题：“编写一个不可变函数，接受一个由整数 X...n 组成的数组 A，返回一个由 X...n 组成的数组，其中所有整数出现的次数都等于或小于 Y（假设为 1）。”当然，更简单的说法是：“编写一个对整数数组进行去重的函数。” 但很多时候，那些爱挖苦的内部开发人员更喜欢使用第一种描述。然后，他们坐下来，看着紧张的应聘者努力理解他们刚才被问到的问题，哈哈大笑。
  
  

有效的白板面试

这是否意味着白板面试应该被摒弃？当然不是。它确实是一个强大的工具。但以下是一些建议，可以确保你不会淘汰其他有价值的候选人：

1. 至少花一点时间培训你现有的开发人员如何提出有效的面试问题。
   他们可能不喜欢这样做。但未经培训的面试官往往是一个负担。教他们避免诱导性问题。培训他们如何评估候选人的心理过程，而不是关注语义细节。教他们如何让候选人（合理地）感到舒适——因为紧张很少是淘汰候选人的正当理由。

2. 在候选人到达之前，把编程练习写下来。
   你可能不太接受纯口头指令。所以，不要指望候选人在纯口头指令下就能完美地完成任务。

3. 尽量提供一台预装IDE的工作站，供候选人演示他们的解决方案。
   现在没有人用记事本写代码了，他们也不在白板上写代码了。所以，不要以此为借口淘汰优秀的候选人。

4. 鼓励候选人讲解他们的解决方案。
   你是否执着于他们能在白板上写出完美可编译的代码，并在人为限定的时间内完美实现目标？还是你更看重候选人拥有扎实（且可重复）的思维过程，能够用来编写任何潜在的解决方案？

5. 鼓励候选人编写与语言无关的解决方案。
   换句话说，通常这样说很有效：“用你熟悉的任何语言编写这个函数 X…… ”有些人对这种自由感到犹豫。有些人坚持认为：“我们招聘的是能用汇编语言编写、能连接到 React 前端、能通过 GraphQL 与 MongoDB 通信的人——所以我们需要看到用这些工具编写的解决方案。” 但这种限制是傲慢的愚蠢之举。你不应该寻找恰好掌握了你完全相同技术栈的开发人员。你应该寻找顶尖的开发人员。就是这样。如果一个开发人员花了 20 年时间精通 C#、C++、Python 和 Oracle 的方方面面，你真的认为他无法（快速）掌握你当前环境中使用的 TypeScript 吗？
   
   

编码测试的风险

过去十年左右，各种在线工具层出不穷，据说可以用来评估候选人的开发技能。在某些情况下，这些工具甚至非常有用。但我注意到，很多在线编程测试都彻头彻尾地垃圾。

这些在线工具的第一个缺点是，它们通常依赖某种人工计时器来限制每个问题的完成时间。从某种程度上来说，这可以理解，因为如果我要求你对数组进行重复数据删除，你的解决方案（在很多不同的语言中都有很多不同的方法可以实现这个目标）不应该花费你几天的时间。但我见过很多网站，这类问题的计时器时间都被限制在几分钟之内。

也许你在想，

“好吧，如果你不能在几分钟内对阵列进行重复数据删除，那么你就不是我们团队的最佳人选。”

好吧，你可以这么想。但请考虑一下：很多复杂且相当深奥的函数，我几分钟就能帮你写出来。我能这么快写完这些函数，是因为我是编程高手吗？很难说。我能这么快写完，是因为我以前接触过它们。这些脑力劳动已经完成并存储在我的脑子里了。所以，当你让我写这个函数时，在不知情的旁观者看来，我的努力会相当令人印象深刻。但这并非因为我高超的编程能力而“令人印象深刻”。这仅仅是因为我能复述过去某个时刻已经解决过的问题，才显得令人印象深刻。

相反，我有时会花一个小时左右的时间来解决一些在别人看来相当“简单”的问题。我之所以花了更多时间，仅仅是因为我之前从未接触过类似的解决方案。而且我知道，我并不是唯一一个遇到这种情况的人。

换句话说，很多这类限时编程测试并非衡量你内在的智力。它们只是“衡量”你是否已经熟悉这个问题。而这通常不是一个合格的晋级/淘汰候选人的依据。此外，对很多人来说，看着（人为限制的）计时器倒计时，会严重削弱他们提供可靠解决方案的能力。

瞧……我们工作中都要面对截止日期。我理解，在极少数情况下（比如生产环境中出现bug），有时我们可能非常需要知道某个人能快速完成代码。但更多时候，我们更注重质量而非速度。如果开发人员A在15分钟内就写出了一个“勉强”的解决方案，而开发人员B却花了几个小时才打造出一个健壮的解决方案——包含单元测试，涵盖了多种极端情况，并且特意以其他开发人员更容易阅读和理解的方式编写——你真的想淘汰开发人员B，让开发人员A进入面试的下一阶段吗？

好像这还不够糟糕，我还遇到过好几次编码测试完全出错的情况。这种情况并不常见，但确实会发生。

几年前，我去一家号称只招聘“顶尖人才”的公司面试远程合同工。通过初步筛选后，他们安排我和一位资深员工进行屏幕共享，并给了我两个任务，每个任务限时15分钟。第一个任务我顺利通过。第二个任务，我提交了我的解决方案，他却告诉我错了。说实话，我当时有点不知所措，不知道该说什么，因为我相当确定我的解决方案没错。但那时已经太晚了。他们已经认定我的解决方案“错误”，面试结束了。

但这真的让我很烦，我竟然记得当时给我布置的具体任务，之后特意去谷歌搜索了一下。我并非无法接受我的解决方案“错误”——但如果是错的，我想知道它错在哪里。换句话说，我想从中吸取教训。所以……在从大约10个不同的角度搜索之后，我终于意识到我其实是对的。当然，这与我的面试无关。我已经被彻底淘汰了。但你可以想象，这段经历对我来说有多么令人沮丧。

如今，大多数自动化编程测试甚至都不会被面试官实时查看。但我发现，在其他一些情况下，自动化系统标记为“错误”的任务实际上是正确的！

当然，自动化测试并不一定局限于实时编码示例。它们还可以包含多项选择题。而且……哦天哪。让我告诉你，很多人不知道如何设计一道有效的多项选择题。

有时，题目已经过时了。有时，它们的措辞含糊不清，以至于根据上下文，多个答案可能都是“正确的”。但我最讨厌的，是那些被当作技能测试/问题来炫耀的智商测试/问题。考虑一下下面这个与编程无关的假定问题：

As a lawyer, someone walks into your office and demands to know the 
contents of the conversation that you just had in the previous hour 
with another client.  
You should:

A) Call 9-1-1
B) Threaten to kill the client
C) Politely inform him that conversations with other clients are
legally-protected and encourage him to either change the subject or 
find another laywer
D) Tell him that such inquiries can only be handled via "street 
justice"
E) Inform him that you can only divulge the conversation "for the 
right price"

我假设，如果你正在读这篇文章，你肯定不是律师。我还假设，即使你没有接受过任何法律培训，你也能看出正确答案是C。

换句话说，这道题根本就没考你的法律知识。它设计得（很差劲），只考你有没有点儿常识。

这听起来可能有点奇怪，但我见过太多选择题（无论是科技类还是其他类），它们的措辞方式根本不考察考生的实际知识水平，而只是考察考生的基本智商。

作为一个更好的例子，考虑以下问题：

By default, HTTPS requests, encrypted with SSL, are transmitted 
on which port?

A) 22
B) 80
C) 82
D) 443
E) 448

如果有人对 HTTP 请求和默认端口一无所知，那么他们很难通过简单的猜测得出正确答案。对于不了解相关主题的人来说，问题（或答案）中确实没有任何数据能够让他们轻易推测出正确的答案。当然……他们仍然有五分之一的机会能够简单地猜对，但问题（以及提供的答案）并不能帮助“门外汉”找到正确答案。

有效的代码测试

那么，我们应该抛弃所有自动化代码测试吗？答案是否定的。它们可能非常有用。但如果你觉得必须使用这些自动化测试工具，以下是一些需要考虑的关键点：

1. 除非您可以手动指定每个问题的时间限制，否则不要选择代码测试工具。
   并且要灵活处理。不要一概而论地认为“每个人”都应该能够在X分钟内解答这个问题。优秀的程序员有时会投入额外的时间来确保解决方案的稳健性和高质量——他们不应该因此受到惩罚。并且，不要低估候选人看着冰冷无情的计时器倒计时可能带来的不安感。

2. 除非您可以手动选择向候选人呈现的确切问题，否则不要选择代码测试工具
   。 让随机算法将问题 A、B 和 C 分配给我，而将问题 X、Y 和 Z 分配给另一位候选人，这显然是不公平的。问题的潜在随机性会破坏您在候选人之间进行同类比较的能力。此外，这些代码测试工具提供的一些“常用”问题的措辞令人困惑且难以理解。您的“测试”不应该是候选人能否理解问题中晦涩难懂的语言。问题应该是测试一个人对编码技术的基本掌握程度。

3. 做选择题时要非常小心。
   如果一个完全的新手能轻易排除任何可能的答案，那么这道选择题就很差劲。

4. 不要盲目地对所有候选人进行编码测试。
   坦白说，这对高级开发人员来说可能有点侮辱。我理解，这可能是你对通过你的网站或招聘网站筛选的匿名申请人使用的“盲目”工具。但是，如果你的一位现有开发人员强烈推荐了一位知识渊博、经验丰富的朋友，你可以通过向他们发送基本技能测试来彻底打消这个候选人的念头。如果你愿意，你可以“坚持己见”，你可以要求每位候选人——即使是那些由你信任的员工亲自推荐的候选人——首先完成编码测试。但你也会发现，一些资深的、炙手可热的开发人员根本懒得去做。他们已经有一份好工作了。他们正在进行一些副业。他们有……选择。他们不需要为了获得一份最终可能根本不想要的工作而费尽心思。

5. 尊重候选人的时间。
   如果你认为每个编程任务应该花30分钟，而实际要完成10个任务，那么你就是期待着大量你不认识的人无偿劳动。在这种情况下，谁有能力完成整个测试？初级开发人员。那些没有……选择的人。那些即使想通过面试也需要大量指导的人。他们没有一份好工作。他们会做你要求的任何事。但那些顶尖的程序员呢？他们会认为你的编程测试很浪费时间——然后干脆就通过了。

6. 让你现有的开发人员参加测试（如果他们在面试过程中还没有参加的话）。
   没错。他们可能已经被录用了——但让你自己的开发团队“吃自己的狗粮”可能是一个很棒的基准。我这么说，并不是因为你应该考虑淘汰那些（大概）已经在你的环境中蓬勃发展的团队成员。我这么说是因为它能让你更现实地了解你的“标准”编码测试对潜在开发人员来说到底有多难——或者说有多容易。当你一直在淘汰那些在你的编码测试中“只”得了50%分数的候选人时，这可能会让你大开眼界——而你现有的开发人员（那些大概已经为你做得很好的开发人员）在同一测试中却经常“只”得了50%的分数。
   
   

“演示”应用程序和编码练习的风险

如果你不擅长应对白板面试的陷阱（对于远程/分布式团队来说尤其如此），并且对现有的自动化代码测试解决方案心存疑虑，那你还能做什么呢？嗯……对许多公司来说，编码练习就是了。

该公司表示，在这一框架下，

好的，我们认为你是个不错的人选。所以为了确保你能做到你说的，我们想让你写一下这个小小的应用程序。

表面上看，这很有道理，对吧？我的意思是，这通常意味着更宽松的完成时间。这样可以减少那些被迫参加白板面试的开发人员的偏见，而他们可能对此没什么兴趣。这是对候选人技能更“真实”的测试。所以这肯定是最终的解决方案……

正确的？？？

嗯...不完全是。

需要明确的是，家庭编程练习有很多值得称道的地方。它赋予了应聘者更大的控制权——因此他们不太可能在实时练习的密切关注下感受到不必要的压力。它可以被设计得更适合雇主的环境。它更“真实”地展现了程序员的实际能力（不会对诸如谷歌搜索答案之类的行为进行惩罚）。所以，还有什么理由不爱呢？

不幸的是，带回家的编程练习似乎是未来雇主最常滥用的手段之一。它们几乎把所有负担都转嫁给了求职者，同时也助长了招聘决策的武断性。我为什么这么说呢？不妨考虑以下几点：

编码“练习”几乎总是比承诺的时间要长得多

这是一个非常直观的编码练习示例，我最近被要求完成它，以便我可以申请一份特定的工作：

You can choose any programming language and web development framework, 
database, and web server you like. The web application you need 
to build is a basic todo list application with the following 
requirements:

-   Users can view their todo lists.
-   Users can add, remove, modify and delete todo entries.
-   Each todo entry includes a single line of text, due date and 
    priority.
-   Users can assign priorities and due dates to the entries.
-   Users can sort todo lists using due date and 
    priority.
-   Users can mark an entry as completed.
-   Users can reorder todo entries via drag-n-drop.
-   You don't need to spend time on UI/UX design, if you do, it will 
    be a bonus.
-   Provide a GraphQL API which will allow a third-party application 
    to trigger actions on your app (same actions available in the app).
-   Provide authentication and authorization service for both the app 
    and the API.
-   As a complementary item to the last requirement, you should be 
    able to create users in the system via an interface, e.g. a 
    signup/register screen.
-   If users have not registered, they must be able to use the app as 
    a "guest".

现在你可能会想，

“嗯...我可以很快地建立一个基本的 CRUD 应用程序 - 我们希望我们的开发人员也拥有同样的能力。”

但是让我们分解一下这个编码练习中的各个层：

1. 至少有两个CRUD 层，
   一个层用于 CRUD 列表，另一个层用于 CRUD 每个列表中的各个待办事项。

2. 每个待办事项都需要优先级和截止日期
   。如果你使用现代日期选择器以外的其他工具来设置日期，你的应用看起来会很不顺畅。而且，一旦你开始在应用中添加日期，排序机制至少会稍微复杂一些。

3. 你必须能够通过拖放功能重新排序项目。
   嗯……什么鬼？？说清楚一点，通过 React 实现拖放功能并非难事。但为什么这是演示应用程序的要求呢？我的意思是，如果某个潜在的开发人员还不熟悉 React 拖放库，而且他必须花费大量时间去熟悉它们，那么这真的是你想要用作选择标准吗？

4. 你必须使用 GraphQL。
   我其实对 GraphQL 没有任何意见，它的确是个好工具。但你是说，如果我已经开发了一个“只”用 REST 实现的精彩演示应用，你就会把我排除在竞争之外？换个说法吧。如果你有一个候选人，他基本上是编程大神，但……无论出于什么原因，他还没有使用过 GraphQL，你难道不想至少和他多聊聊，看看他是否适合你的公司/环境/团队吗？拜托，哥们……

5. 你必须为应用和 API 提供身份验证服务。
   你能感觉到我翻白眼了吗？因为它们现在真的翻白眼了。你想让我构建这个演示应用，包含一个隐含的数据层、GraphQL（不是REST！）和一个身份验证层吗？嗯……好吧。

6. 作为“补充项”，您应该能够创建/注册用户，或者让他们以“访客”身份维护状态。
   现在……请阅读本规范的其余部分。您觉得这个“附加”建议真的像是补充吗？我的意思是，当然，您可以忽略它。毕竟，它是“补充”的，对吧？但是，如果他们如此执着于您使用的特定 API 格式，如果他们如此执着于拖放功能，您真的相信他们会对任何不包含“补充”方面的提交感到满意吗？

但这个不体贴的请求中我最喜欢的部分是：

“你不需要花时间在 UI/UX 设计上，如果你这样做了，那将是一个额外的收获。”

所以让我先说清楚：他们完全专注于所使用的特定 API 语言（GraphQL），并且他们认为必须实现拖放功能，但是……我不需要花时间在 UI/UX 设计上？嗯，是的……对。

能在短短几个小时内搞出这样的东西吗？当然可以。我想是的。如果……你已经熟悉 GraphQL。并且，如果……你已经非常熟悉各种可用的拖放库。并且，如果……你几乎不用花时间担心这个应用看起来是不是像个热乎乎、抹了黄油的牛粪。

但是，如果您真的对自己所做的事情感到自豪，并且希望这个“简单”的演示应用程序能够合理地代表您对自己的工艺的关注，那么您根本无法在任何合理的时间内启动这样的应用程序。

你看……这样的“要求”完全是对候选人时间的不尊重。当然，他们或许能在相当短的时间内开发出一个功能简陋的应用程序来满足这些要求。但如果候选人“随便拼凑”了点什么，那么这些要求的性质就意味着雇主会拒绝。所以，候选人面临着一个令人望而生畏的境地：要么屈服，做一大堆完全免费的“演示”工作（这些工作永远不会真正用于任何功能），要么就被淘汰出局。

最好的程序员不会费心去完成你的任务

我知道有些过度劳累的招聘经理会想，

“我们必须筛选大量的候选人。因此，我们必须进行这样的编码练习，以便在我们浪费所有时间进行评估之前，淘汰不合格的候选人。”

好的，没问题。你很忙。我明白。 你很忙，我也很忙。每个人都很忙。你不是唯一一个在美国企业界日程满满的会议和截止日期的人。也许你认为这是一个清理日程表、把一些无休止的招聘负担转嫁给候选人的绝妙方法？但我还是想恭敬地问一下，

“你有没有考虑过这会对你的潜在候选人造成什么影响？”

我想你肯定不想随便招个小伙子吧？你通常都想招“精英中的精英”，对吧？所以，请你从那些“顶级”候选人的角度想一想……他们是不是迫不及待地想完成你的编程练习？

我记得，美国的程序员市场一直很紧张。找到那些渴望第一份“真正”工作的脚本小子或许并不难。但如何找到真正的“高手”程序员呢？他们会仔细翻阅（数字）招聘广告吗？他们会主动上门找工作吗？

我见过的大多数“热门”程序员（我很荣幸能与其中很多人共事）很少找工作。他们总是被招聘。他们被从一个工作（他们大概已经厌倦了）拉到另一个工作。这些“超级明星”对在一个一次性的演示应用程序上花费大量时间不感兴趣。他们已经有一份不错的高薪工作了。即使他们可能想找另一个雇主，他们也不必再找了。他们有……选择。

这些顶尖程序员已经拥有一份高薪工作。即使他们想找一份新工作，也并不急于找到下一份工作。事实上，他们中的许多人已经身兼数职。一份“日常工作”。几份持续进行的合同工作，让他们的银行账户鼓起来。他们有家庭。有爱好。他们……有自己的生活。对于这类人，他们只需看一眼你的演示应用中长长的需求清单——就会毫不犹豫地拒绝。

所以，你或许会觉得自己通过布置繁重的“家庭作业”，出色地区分了“真正的”程序员和那些装模作样的程序员。但实际上，你只是在从候选人库中剔除掉一大批——最优秀、最有资格的人才。

编码作业通常“测试”语义因素

即使我们假设你的下一个热门编程职位真的想完成你的编程任务，也要仔细想想这个任务究竟在考验什么。在上面的例子中，雇主测试的并非你是否具备全面的编程技能。他们测试的是你是否具备 GraphQL、拖放操作以及其他与他们的工作环境相关的细微细节的具体经验。这种方法的问题在于它目光短浅，而且很懒惰。

这种做法很短视，因为你下一位优秀的程序员可能拥有解决你大多数编程问题的丰富专业知识。但他可能没有专门使用过 GraphQL 或拖放功能。但你会因为他简历上的技能组合与你特定技术栈的技能组合不匹配而淘汰他吗？

说它懒惰，是因为编码作业中的细节很容易导致候选人（其他方面都合格）被盲目淘汰。很容易想象有人在审阅提交的作业后会说/想：“哎呀，这是我见过的最好的编码解决方案之一……但他们没有使用 GraphQL。所以……他们被淘汰了！” 如果你的开发文化如此狭隘，以至于你只能考虑雇佣一个和你技术栈完全相同的人，那么你的开发文化就是垃圾。

编码任务的异步性可能会引发怨恨

许多开发人员招聘经理喜欢代码作业，因为它本质上把程序员评估的重担从雇主身上转移到了候选人身上。其中的逻辑其实很简单：

我们不可能筛选所有这些不知名的候选人，所以我们会要求他们全部提交一项繁重的“作业”。很多人根本就完成不了作业——这样就有效地帮我们淘汰了候选人。即使完成了作业的人，我们也可以安心地挑选出最佳答案。

对于工作过度的招聘经理来说，这听起来很完美，对吧？但是，除了（之前提到过的）他们会默默地淘汰许多高素质的候选人之外，另一个问题是，这种态度会在市场上引发日益增长的不满情绪。为了说明这一点，我们再次参考上面的例子。

和许多经验丰富的求职者一样，我很少费心去完成（甚至尝试）这类任务。和许多同事一样，我很幸运，几乎不需要工作——我的空闲时间太宝贵了，不值得为了某个所谓的工作而去匿名编程，毕竟，说到底，我可能根本不想做这份工作。

但尽管有这样的特权，我还是完成了这项编程任务。出于各种原因，我就不在这里烦你们了，我其实很想做这件事。所以，尽管我一如既往地有所保留，我还是把整个代码都写好了。把它放到了 GitHub 上。提交给了雇主。然后……等待。不幸的是，回复和我担心的一样，令人心力交瘁。

有一段时间，我什么也没听到。事实上，我认为在“正常”情况下，我根本不会从潜在雇主那里听到任何消息。（坦白说，这简直太粗鲁了。）但巧合的是，我最终和一个认识申请编程任务的公司的CEO的人聊了起来。他们告诉我的是：

“他们不太喜欢你的提交，因为你用 PHP 编写了后端代码。”

现在，我恳请您向上滚动并再次查看这些需求。并且请指出——在需求中——哪里提到了后端应该/必须使用哪种语言？为了绝对清楚，我的解决方案有一个 React 前端，它使用 GraphQL 向 API 提交查询。该 API（是的……用 PHP 编写）也设计用于接受和处理专门以 GraphQL 格式提交的查询。持久层通过 MySQL 处理。（同样，规范中没有具体说明应该使用哪种数据引擎。）前端使用拖放功能来实现待办事项的可视化排序。

事实上，我的解决方案满足了作业里的每一项要求。但雇主还有进一步的“要求”。不言而喻的要求，没有记录在案的要求。由于我不符合这些不言而喻且没有记录在案的要求，他们选择完全不回复我的申请。

想一想。一位非常资深的开发人员决定完成你庞大的编码任务。但是，就因为他们没有以完美匹配你内部技术栈（需求中从未明确说明的技术栈）的方式完成，你就要把他们的申请扔到一边？？？

坦白说，我认为这是可耻的。

有效的编码任务

所以……我个人很讨厌编程作业，而且我觉得它们总是很邪恶，对吧？嗯……不完全是。就像这篇（长文）中讨论的其他技巧一样，编程作业可能非常有用。但双方必须互相尊重。因此，以下是一些需要考虑的关键事项：

1. 编程作业几乎永远不应该成为你初步筛选流程的一部分。除了上面提到的（一个）例外，如果我看到一个我可能感兴趣的
   职位，但我必须完成编程作业才能提交申请……我就会继续申请。你的时间很宝贵。我的时间也很宝贵。而且我不会花费大量时间（或几天）去编写一些超级具体的解决方案，仅仅希望你能跟我谈谈。有很多简历平平的脚本小子，他们很乐意为你费尽心思，希望你能在面试过程中让他们有所进步。我不是那种人。而且我认识的大多数经验丰富、才华横溢的同事也不会接受这些考验。

2. 别自以为是了。
   显然，有些公司会设置很高的门槛，比如给你布置非常具体的编程任务，然后才会考虑你。这些公司包括亚马逊、谷歌和微软。他们支付丰厚的薪水，在开发者社区拥有巨大的影响力，每年都会收到成千上万的申请。他们完全有理由如此挑剔。如果你正在读这篇文章，那么你很可能不在这些公司工作。你可能认为你所在的早期风险投资初创公司就是下一个独角兽。但最有才华的开发者都经历过很多次。他们知道不应该浪费自己的夜晚和周末来满足你演示应用程序的所有挑剔要求。

3. 将您的编码任务转换为实时会话。
   与已经确定的合格申请人进行屏幕共享，给他们一个开放式的编码任务，并要求他们在您面前编写代码。是的……这将需要您花费更多时间。这些时间将培养出更优秀的开发人员。您可以要求的范围几乎没有限制。您可以要求他们从头开始重新创建 Facebook。他们会在屏幕共享期间完成吗？当然不会。重要的是，您将实时看到他们如何进行应用程序的构建和架构过程。如果他们不选择使用您所选技术栈中现有的确切工具怎么办？谁会在乎呢？不要陷入特定技术/字母汤的细节中。

4. 对实时屏幕共享的编程任务设定一个硬性限制。
   我个人建议两个小时。提前告知候选人，他们不一定需要完成任务，并且不会要求他们编写代码的时间超过之前告知的时间限制。如果你在观看某人实时编写一个潜在应用程序两个小时后，仍然无法判断你是否想聘用他们，那么强迫他们再花费10个小时的个人时间并不能解决问题。当你以这种方式处理编程任务时，它会向你的下一位潜在的“编码摇滚明星”传达出你确实尊重他们的时间和才能——并且，如果他们接受了你的工作邀请，那么在正式入职后，他们也会得到同样的尊重。

5. 切勿抛弃任何提交过作业的人。
   这一点至关重要。如果有人同意做所有这些免费工作只是为了（希望）证明自己的价值，那么你能做的最不尊重的事情就是干脆无视他们。你提交的每一个练习都应该得到至少一定程度的认真反馈。如果你认为自己无法满足这样的要求，那就停止征集代码作业吧。真的。停止吧。马上。这样想：想象一下，你同意为某人免费工作一整天，希望他们能给你一份正式的工作邀请。然后，到了一天结束的时候，你不仅没有收到任何邀请，公司里甚至没有人会理你。他们消失了。如果你做错了什么，甚至只是“不太理想”，你都无法知道，因为那些同意让你免费工作一整天的混蛋根本懒得给你任何有意义的反馈。他们直接开车回家，让你自己想办法解决。这就是你把所有带回家的编程作业都发上去，却懒得对提交的作业做出任何认真的回应。这简直是荒谬的打脸。

6. 抛弃你的技术栈。
   如果你有 React 团队，但有人能用 Angular 写出令人惊叹的应用程序，这真的算对他们不利吗？你真的想淘汰一个编程高手，却又恰好没有你那套狭隘技术栈经验的人吗？好好想想……