对于程序员来说，现场编程测试可能是考核编程能力的最好方法，但是如果用人单位没有考虑清楚考核题目和考核标准，可能彼此都会浪费时间。今天这篇文章，是一位有着丰富招聘经验的作者，给出的他在现场编程面试程序员时候的一些经验，当然他也澄清了几个被求职者吐槽的问题。
Reddit上的编程分类内容有大约 200 万用户，其中大多数帖子只有很少的评论，热门一点儿的话题一般也就 100 到 200 条评论。但是如果你在上边搜索“面试”这样的关键词，你看到的热门帖子数可是超越想象。
许多开发人员对编程面试都感触颇深。上面所有的帖子都在哀叹：如今的趋势是将现场编程测试当成获得软件工作的必要条件了。但却从来没有一个人为这种编程面试做出一番辩护。
在今天的文章中，我想做的是：
为编程测试提出充分理由。列举一些最好避免的常见做法。解释为什么面试总是涉及毫无意义的算法谜题，而不是“真正的”编程。我写这篇文章的原因，是因为在我的职业生涯中，我有过 300 多次面试别人的经历，并且设计了我当前雇主所使用的面试流程。我所雇佣的团队每天都要进行开发人员面试。一个好的招聘流程是有价值的，本文不是关于如何设计一个完整成熟流程的教程，只是提到了一些求职者在合理情况下非常讨厌的事情，对于聪明的雇主来说，会尽量去避免做这些事情。
首先说说我们如何在 R3 招聘。R3 为了建造一个受比特币启发的分布式开源数据库，我们正在世界各地招募技术人员。开发人员的面试过程一般包括以下内容：首先，阅读一段代码，要求面试者在大约 5 分钟的时间内，快速地发回对代码的评审意见；其次，是一个 30 - 60 分钟时长的视频聊天 + 共享屏幕面试，面试者可以从家中接入，在编辑器中进行编程，可以自选熟悉的编程语言，只要编程语言足够主流，面试官就能读懂；最后，邀请面试者到办公室与团队和高管进行面谈。
根据候选人的个人特质和具体的工作角色，编程测试有时还包括设计部分和“谈话”式问题，因为面试者的工作不仅仅只是编程。我们发现，这样的一个面试流程其实还是很科学的；而且，至少与其他一些招聘流程相比，这个流程还是相当轻量化的。
面试官应该避免什么既然这样，让我们从尽量避免的面试风格开始谈起。
我不推荐某些公司采取以下做法：
“机器人面试”与自动化评估。没有人喜欢做面试官，所以你的团队经常会要你看是否能把面试工作外包出去。我们曾经对这种机器面试有一段非常短暂的体验，却发现其结果与人为主导的评估结果并不相符。更重要的是，邀请应聘者参加面试是对占用他们宝贵时间提出的礼貌要求，如果我们要求某人免费为公司奉献时间，而公司不做出对等的奉献，这是很不礼貌的。面试官花一个小时和你通电话，表明他们和重视自己的时间一样重视你的时间。用一个冷冰冰的 web APP 来实现自动化的“作业”会带来截然不同的结果。尤其是高级工程师，他们一定会拒绝接受这种面试。白板面试。虽然很多年前这种做法是可以理解的，但现在笔记本电脑和屏幕共享无处不在，编写程序最自然的方法当然是使用编辑器、键盘、搜索引擎和编译器这些工具来辅助面试者。另外，视频电话面试允许应聘者在家里用自己熟悉的电脑和工具编程，这比让一个人站在一个小会议室里，用一支粗胖的马克笔在白板上写代码要好得多。面试一整天。许多公司都希望对开发人员进行一整天的面试，这通常需要 5 到 8 次的单独面试。这使得那些已经有工作的开发人员很难参加一整套面试，而这些人可能正是你最想雇佣的。如果先进行远程面试，然后利用午休时间进行一些回访，可以让求职者避免请假，这意味着他们更有可能完成整个面试过程。我个人发现：8 次较之 2 次面试反馈而言，并不能显著提高团队的招聘质量。大规模的“作业”。虽然我们最近开始要求应聘者面试前做一个简单的的任务，但这个任务不需要编写任何代码，而且可以在几分钟内就完成。我听说有些公司要求应聘者在面试时间之外编写完整的、真实的程序。同样，这也是对面试者时间的不尊重，许多人会明确地提出拒绝。慌忙中随意编造问题。问题设计并不容易，你希望候选人事先做好准备对吧？所以作为面试官，你也应该提前做好充分的准备。修复一个真正的 bug 或实现一个真正的功能。这样做除了会带来明显的版权问题之外，这也并不是一个保证面试过程可重复执行的好办法，也并没有办法确保你在这个过程中观察到各种优秀的编程技巧，比如，特性的实现可能仅仅涉及复制 / 粘贴，对现有的代码做出一些细微的调整。这样的面试过程还假设，你在为 Java 代码库雇用 Java 开发人员，或者为 Ruby 代码库雇用 Ruby 开发人员，如果你只是想雇用熟练的开发人员，并让他们在工作中学习你的本地工具，那么这种类型的面试并不奏效。这里我已经讨论了一些需要避免的事情，但是我们应该要求程序员在面试中进行现场编程的基本前提仍然是成立的。现在让我们来思考一下，尽管它并不受面试者欢迎，为什么仍然是一个如此普遍的需求？
许多候选人不喜欢接受编程测试。面试者常常觉得招聘流程设计得不好，这些带来了大量的错误否定，导致人们充满愤怒和怨气。愚蠢的面试流程阻碍了他们自我能力的展现，因为这样的原因错过了一份工作，没人会为之高兴。
你自己觉得能胜任一份工作，却被面试拒之门外，这是一种糟糕的经历，尤其是当这个招聘流程貌似含蓄地宣称其科学、准确时。
因此，雇主们似乎可以不这样做，而是依靠更传统的面试形式，比如在面试中谈谈过去的从业经历。然而，多年来，编程测试这样的形式已经从微软等公司流传开来，几乎成了所有地方的行业标准。现在，很少有软件公司愿意只是进行一次友好的电话交谈就敲定录取。这是为什么呢?
编程测试是必要的看着实习生带着心理阴影走出他们人生第一次编程面试，总令人感到那么”享受“。他们走出来时，先是带着一种呆滞的眼神，略带震惊的表情。然后，开始咆哮。
这些应聘者是如何开始先用一种编程语言编写代码，然后又觉得实际上他们并不熟悉这种语言，应该从头开始用另一种编程语言呢？一个简历上有 10 年工作经验的人，怎么就做不到在自己的编辑器中开始一个新项目呢？面试者怎么可能花 30 分钟试图生成一个随机数却仍然以失败告终呢？这真是太疯狂了！
老人们咯咯窃笑着，十分享受这个古老的入会仪式。“啊，这并不疯狂。让我告诉你大约要花多少时间……”
20 世纪 90 年代，微软在科技行业推广了结构化面试，这一面试过程以刁钻的脑筋急转弯式智力题而闻名，比如著名的“为什么井盖是圆的？” 还有一些编程难题，比如“在白板上用 C 语言对一个链表进行反转”。支持这种面试形式的文章是 Joel Spolsky 的经典著作《游击队面试指南》（Guerilla Guide to interview）。当这本书在 2000 年出版时，很快就被创业公司大量采用，比如一家刚成立两年的小公司，谷歌。
在一次采访中，Joel Spolsky 回顾了他向世界输出的源自微软的面试趋势。从当时的非结构化的面试出发，这是一个很大的进步，但如今他已不再满意于此。遗憾的是，他提出的替代方案是让公司只从实习生中雇佣正式员工。
但是我认为这项面试技术最著名的例子是Imran Gohry 的 FizzBuzz 问题，2007 年 Jeff Atwood 的一篇博文“为什么程序员不能编程？” 引起了公众的注意。Jeff 在他的博客中写道：
每个人都是从头学起的。但令我感到不安和震惊的是，任何所谓的”程序员“都要找一份工作，但其中有些人却不能编写最简单的程序。这对任何以编写软件为生的人来说，都是一记响亮的耳光。
Dan Kegel 是我在谷歌和 Wine 项目中，一位受人尊敬的前同事。2006 年，他在谈到招聘开发人员时，曾这样说：
令人惊讶的是，在要求执行基本编程任务的面试中，有很大一部分求职者都失败了，即使是那些拥有计算机科学硕士和博士学位的求职者也是如此。例如，我曾经亲自面试过一些应届毕业生，他们无法答出“如何写出一个从 1 到 10 的循环”或“十六进制中 F 后面的数是多少”？
在面试中识别那些急于证明自己优势的伪程序员，戳穿他们夸大其词或虚张声势的故事，似乎听起来是件美好的事情。但我告诉你，事实并非如此。每个组建开发团队的人，真的是每个人，都会开始习以为常，面试官总是在面试中遇到没有实际编程能力的人，即使“编程”已经很宽容。
人们普遍认为，企业进行编程测试，是因为这些公司里充斥着痴迷于算法的书呆子，他们都试图挑出知识尽可能渊博的候选人，希望公司成为下一个谷歌，事实并非如此。公司会进行编程测试，是因为他们遇到了很多候选人，他们的简历看起来都很不错，甚至能对计算机行业侃侃而谈，但在被要求编程时，实际上却无法写出程序。真的不夸张，一点程序都写不出来。
如果你是一名求职者，能够达到下列条件，已足够让你脱颖而出：
查看全文，可点击了解更多
