是时候给糟糕的技术面试来场革命了
英文原文：The Terrible Technical Interview
传统的技术面试对所有人来说都很糟糕，既不利于公司评估应聘者，也不利于应聘者评估公司，不仅浪费时间，还对双方产生了压力。几乎所有面试过的人都同意这些。可他们依旧继续这样面试。
我在此谨建议那些有颇多选择的工程师们干脆地拒绝这些面试。
不要紧张，下面我要介绍更好的面试方法。
上个月，丹尼·克莱顿（Danny Crichton）写了 几篇 关于技术面试的文章。这几篇文章 写得很不错 ，我推荐大家读一读，在这里我只摘取文章中的一些要点：
没有什么行业像软件工程一样如此公开地敌视其从业者……我们让应聘者在压力很大的面试环境下在白板上现场编程，只因为这是我们这行的惯例……我们实在不该在工程师紧缺的时候错失如此多的人才。
他受到了 Thomas Ptacek 的文章的启发：
现在这种软件开发人员的面试行不通。公司不应该再用这种方法招人。聪明的团队将通过设计新的招聘方案战胜竞争对手。
的确如此。而且，在我的印象中，情况终于开始改变了。更多的公司开始让应聘者做测试项目，而不是只做白板面试。其他公司也不那么热衷于在面试阶段剔除那些看起来合适的应聘者（而是在几个月后更加无情地开除他们）。这些改变产生了效果，谷歌的人力资源主管几年前也 承认 ：“脑筋急转弯纯粹是浪费时间”以及“测试分数没有任何价值”。
然而技术面试还没消失。我本可以再早几年写出这篇“ 技术面试已死 ”（这里有 中文版），可我没有。至少技术面试现在还没死。它已垂死，但死得过于缓慢。
我们这些痛恨技术面试的人不得不承认的是，即使公司知道白板型面试远非完善，他们还是坚持使用，这是有原因的，其中一些算得上有部分正当性。这些原因包括：
- 面试从公司的角度讲是一个相对可测量、可重复的过程。人人都知道面试的流程是怎样的。不过是出几个题目，设定一些考量答案的标准。甚至在必要的时候，（绝大多数）技术员工都能当面试官。
- 公司想尽早剔除明显不合适的应聘者，因此很难不在面试中多问技术问题，就算我们这些人做面试官时也会如此……在特别传统的面试中尤其如此。
- 你当然想选出有才能的人，剔除那些没什么才能的人。传统技术面试被认为更喜欢在面试中看起来没什么才能的人，而不是看起来有才能其实没有的人。看 起来有才能过去被视作灾难性的状况；雇用一个差工程师被视作比没雇到两个好工程师更糟。可在好工程师如此稀缺的今天，这样的观点已经过时了。
- 目前代替技术面试的方法是布置一个测试项目给应聘者，可这种方法充其量也仍旧不完美。事实上很难找到既有意义又不会占用应聘者太多时间的小项目。 同时，应聘者希望这个项目是有偿的，他们也可能会说他们还没辞职，不能花这么多功夫在一个考察性的项目上，而公司也会担心项目会抄袭，甚至外包出去。
- 这就是为什么个人推荐依然是所有人最喜欢的招聘方法……
- ……反过来说明了为什么技术行业的如此缺乏多样性。
因此，我们想找到一种代替传统技术面试的可靠方法，这种方法既对公司有利，又对应聘者有利，还能帮助那些被现在这种推荐过程默默忽略掉的人。这个三赢的任务实在太艰巨了。
我当然不会忘记有很多致力于解决所有问题的创业公司。但我有个不一样的想法。这种方法可以说是给应聘者增加了一项义务，不过我认为对应聘者还是有好处的。我的提议是：
- 工程师，尤其是那些炙手可热的优秀工程师，应该开始干脆地拒绝参加白板型面试。
- 的确，只有在面试前就失去优秀的应聘者，才能更快迫使公司寻找更好的面试方法。
- 但是，拒绝的同时必须提出条件：用讨论或演示应聘者自己在业余时间开发的一个小项目来代替面试。
这是我设想的应聘流程：
- 面试官用 30 到 60 分钟熟悉应聘者开发的项目。
- 然后双方花一到两小时讨论这一项目，包括应聘者做出的架构和实现决策、本可选择的其他方案、他们希望添加的功能、代码结构和每一行代码的质量、环境和配置问题等等。
- 讨论中经常涉及的主题应固定下来，这样这些主题就能在其他面试中重复出现，应聘者和面试官可被互相比较，结果也能够被测量。这些主题可以是：它们使用全局变量吗？代码遵循的是 MVC 框架还是别的架构模式？方法是合理结构化的还是封装的？用户界面能显示出对可用性问题的了解吗？有测试代码吗？等等。这些主题一半是为了综合考察代码，一半是为了考察应聘者“对他们（声称）自己写的代码理解了多少”。
- 接下来面试官让应聘者现场给他们的项目添加一个小功能。
- 此时面试官应该很确定这个项目做得好不好，应聘者是不是真的肚子完成了这个项目。
- 如果答案是肯定的，那么双方可以继续约定一个时间，让应聘者参与开发公司事先定好的测试项目。测试项目可以是一个长期项目，也可以是每几个月做一 个新项目。（开发新项目很适合新雇员。）之后让应聘者为新功能提交拉拽请求，这应该需要工作 4 到 8 小时。测试项目可以是任何类型的，但必须要小，足够检验应聘者能正常工作且能保持合理的进度即可。
- 让另一名面试官评估拉拽请求，看其他人对应聘者的看法如何。
- 或者也可以让应聘者用一到两小时给另一名面试官开发一个更小的功能，这样更有说服力，也更高效。
- 最后决定是否雇用。
看，这不是有了代替技术面试的方法吗？这个方法里不需要在白板上写代码，不需要回答脑筋急转弯，也不需要应聘者写出以后再也不用写一遍的详细算 法实现细节。我不会把这个方法吹嘘成对所有问题的最终完美解决方案，但我相信对大多数还在固守白板面试的公司来说，这个方法或类似的方法是可行的，而且比 现状好得多。
不过，这样就需要一个比原来复杂得多的前提条件：每个应聘者都要有一个独立完成的小项目作他们的名片。
我不觉得这是不合理的。事实上，我认为你可以开心地剔除所有没有这张名片的人。（为了避免有人说我夸夸其谈：我 自己就是一名 全职软件工程师，我经常旅行， 写过书 ，每周还给 TechCrunch 撰写这个专栏，可我依然有空开发我自己的小软件项目。 这是我最近开发的项目，是 开源 的。）
四年前，当我第一次在这里批评传统技术面试无效的逆生产性时，我 写到 ：” 不要面试任何毫无建树的人。绝对不要。证书和学位不是成绩，有真正用户的真正项目才是。在一个 Google App Engine 和 Amazon Web Services 都有免费服务层、注册为安卓开发者并在安卓市场中发布应用只需 25 美元的世界里，软件开发者没有理由没做过一个他能自豪地拿给别人看的网站、应用或服务。”
我想，这些话放在今天更是如此。而另一方面，如果你真有成绩，有一个值得夸耀的个人项目，那你不该再跳进白板编程面试这种毫无意义的怪圈中。你可以做得更好。我们都可以做得更好。