【导读】：咦，怎么是招不到程序员？标题没写错么？嗯，没写错，国外程序员 Nikita 最近写了一篇文章《How NOT to hire a software engineer》，吐槽大公司在招程序员的一些不合理的做法。

一起来看看他是从哪些方面吐槽的？吐槽的是否有道理？

我不是大公司的招聘专家，但我是一个有 14 年工作经验的程序员，对小公司招聘还是有较多经验和一点常识。

早在 2013 年，我为 AboutEcho 组织了一次非常成功的招聘活动，最终招聘了 9 名高级工程师。

这让我有信心来聊聊如今互联网巨头招程序员的做法。

（插图来自 Yulia Prokopova）

1、不要面试时追求最佳解决方案

当求职者到达面试现场时，面试官给出一个问题，并希望在 2 分钟内得到解决。如果花的时间更长，他们就会开始担心，至少会要求你做点什么。

我能理解，毕竟他们只有 45 分钟，他们有很多事情想和求职者一起经历。

我不能理解的是，面试官是根据求职者在 2 分钟内想出的解决方案的质量来评判。因为那不是人类创造力的工作方式。想出很多点子很容易，但期望最佳点子总是第一个出来就很奇怪了。即使是天才，也无法在几分钟给出世界上的最佳解决答案。

创造力是评估和过滤你所想到的想法的能力。如果你们真的对此感兴趣，为什么不让求职者来比较和评估多种解决方案呢？然后判断求职者是否能够评估解决方案的性能？求职者是否能清楚看到所有的优点和缺点？

如果要求在几分钟内想出最好的解决方案，你们测试的是运气，仅此而已。你们是在雇佣幸运的员工吗？还是招能力的员工？

2、不要在面试中问谜题

如何检查链表是否有循环？一个 N 维的盒子能装进另一个 N 维的盒子里吗？你能在没有第三个变量的情况下交换两个变量吗？如何找到两艘行进中的船之间最短的距离？

别误会我的意思，这些谜题很有趣，讨论起来很有趣，解决方法也很有见地。我以前还是个孩子的时候，我就喜欢看《Mathematical Recreations and Essays》。

然而，不管谜题有多有趣，它们只是一些轶事。谜题的性质是，你要么知道答案，要么不知道。它没有告诉你其他任何事情。它与未来的表现无关，与聪明、能力或其他任何事情无关。知道一个特定的答案，并不意味着你可以采取通用和可预测的方式去解决实际问题。它告诉你的唯一一件事是，当某人与他人分享一个解决方案时，那这个人已经有了一种解决方案。不多也不少。就够了。

（蜡烛烧断绳子之前，你会如何自救？）

3、接受其他选择/解决方案

这在某种程度上是意料之中的，但大公司似乎仍然在这方面失败了。如果求职者提出了另一种解决方案，这是面试官学到一些东西的机会。如果提出的解决方案不可能实现，或者不太好，这也是一个深入讨论的好机会。

尽管如此，我还是因为曾经提出过一个同样复杂的替代解决方案而被 pass 了（而且我背负着一场关于“解决问题的真正方法”的讲座）。另一次面试时我引入了一个特定的解决方案，面试官急迫地忽视我所有考虑到的，只想讨论他认定的解决方案，后来面试官对我的反馈是“没啥印象”。

没有人知道所有的事情。放开心态，倾听他人，多思考。是的，即使你在面试他人。

4、容忍瑕疵

由于某种原因，单字节溢出（Off-By-One）错误被广泛认为是 CS 中最难的问题之一，几乎每个人都会犯此类错误。错误是程序员生活的一部分，并不是你可以摆脱掉的。优秀的程序员知道该怎么做。程序员的素质，并不取决于他/ TA 犯的错误有多少。

现在，如果你只选择那些在面试中没有出错的人，你就能得到一群总是能写出完美代码的程序员。你只是不知道当他们不可避免地犯错误时，他们会怎么做。

所以犯错其实是件好事，因为你会了解到求职者是如何消除错误的。不要只看到错误，而是要看求职者是如何处理错误的:

• 简单的代码

• 分治

• 自检

• 不变量

• 断言

• 编译和运行

• 测试

噢，不好意思，最后两项。我都忘了你们在面试时不会让求职者运行程序的。那你们还指望什么呢？

5、让我测试！

说真的，在白板上写程序有什么用？

我的意思是，我宁愿在面试时讨论算法，讨论抽象的东西更有效率。

但是在白板上写程序，真正的程序？甚至不用运行？这样有什么意义？

获得代码初稿，仅仅是编程整个过程的十分之一，接下来是编译、检查、调优、测试、评审等等。我们在开玩笑吧？这些是任何程序员工作流程的基本部分。代码只有在经过所有流程之后才适合查看，而不是在此之前。

这就好比你让一个画家画马，然后在第一次画的时候，当你看到四条线代表腿的时候，让 TA 停下来，然后判断。你会对 TA 有多少了解呢？

6、深入点吧

整 5 个简短的面试题呢？还是搞 2 个长点的面试题？

有了 5 个题，你就有了 5 个独立的意见，这比 2 个好。但 45 分钟能挖多深呢？实践表明，45 分钟仅仅编写 20~30 行代码并问几个非常简单的问题（复杂度是多少？如何测试它？）

下一个面试官只是简单地重复同样的过程，和前一个面试官一样。这并不够，一点也不够。

为什么不写 2 个呢，但要写得很全面？午饭前 1 个，午饭后 1 个？3 个小时也不算多，但至少你有机会了解求职者如何测试代码、如何更改代码、如何处理需求——所有这些都是前后相关中进行的，而不是每 45 分钟就重新开始。

有了这么多时间，你甚至可以让 TA 把代码编写成一个系统的一部分，而不仅仅是一个抽象的算法任务，并了解 TA 在现实世界中的表现。

如果你想要更多的意见呢？让多名面试官在一个房间里，然后让他们辩论。

7、多了解求职者的背景

我的意思是，我有 14 年的工作经验。我很乐意谈谈函数式编程、分布式系统、一致性、复用（replication）、协作文本编辑、CRDTs、并行架构、UI框架、团队流程、产品设计和用户体验。我在这些领域都有实践和研究经验。它们都或多或少与我面试过的互联网巨头有直接的利益关系。

有人问过我这些问题吗？没有。

我得到的面试题是“假如你有一个函数，要用一个列表……”，连续 5 次。5 个学校级水平的面试题，能给你们一个足够深刻的印象么？我读科曼等人的文章有多透彻？公平地说，你也很少被问到这些问题。

相反，要根据求职者的经历来调整面试。谈谈 TA 擅长什么。那你们将有机会提出更深入的问题，了解更多关于 TA 的经验水平和 TA 能为公司带来的好处。

8、无缝流程

方向错了？推迟票？需要特别安装 Adober 阅读器才能打开的调查问卷？廉价的超极本配着不熟悉的键盘布局，基于 Web 的糟糕编辑器，没有任何快捷方式。打扰一下，我这还是在全球知名 IT 公司的办公室面试吗？

在我遇到的中，一个面试官每天要安排 5 次面试。每天 5 个人，乘以公司面试官的数量。想象一下，所有求职者都对这个过程感到有点沮丧。日复一日，年复一年。

你可能认为这无关紧要，还得视情况而定。电视剧《Louie | 路易不容易》中有一集，一个喜剧演员发现房门上自己名字被拼错了。所以他争辩道：是的，这是一个容易犯的错误，但也是一个容易纠正的错误。

是的，我相信任何人都能做得更好。

结语

如果你所在公司在招软件工程师，大公司的那套常规做法不是你的「朋友」。常识、公平、宽容、真正的兴趣和开放的心态，这些才是你的「朋友」。

好好招聘咯!