在Reddit的编程分类中，尽管大部分帖子只有寥寥数语，但关于面试的话题总能吸引众多开发者的目光。他们纷纷感叹：现场编程测试已成为获得软件工作的必备环节。尽管这种测试备受关注，却鲜有人为其辩护。为此，我想在此提出自己的观点：

面试过程中的编程测试一直备受争议。尽管被视为评估候选人编程能力的一种手段，但它却并不被所有候选人所喜爱。一些人觉得这种测试流程设计不佳，容易导致愤怒和怨气，因为不合理的面试流程可能会阻碍他们展现真正的实力。对于那些自信能够胜任工作的人却被拒之门外，这无疑是一种糟糕的体验。尤其是当这种招聘流程看似科学、准确时，更会让人心生不满。

许多实习生在走出编程面试后，脸上都会带着一种特殊的表情——震惊与迷茫的混合。他们咆哮着走出面试室，心中不解为何要在短时间内尝试使用一种编程语言，然后又发现自己并不熟悉这种语言，需要从头开始使用另一种。对于那些拥有多年工作经验的候选人来说，为何他们无法轻松地在编辑器中启动一个新项目呢？面对这样的问题，不禁让人感叹面试的疯狂程度。

一些古老的入会仪式让人看着都觉得有趣。老辈的程序员们喜欢看着实习生们面对编程挑战时的困惑表情，然后窃笑。他们觉得这是一种必要的筛选过程，可以帮助识别那些真正具备编程能力的候选人。这种面试形式源于微软等科技巨头推广的结构化面试，其中包括一些刁钻的智力题和编程难题。这种趋势得到了Joel Spolsky的《游击队面试指南》一书的支持，并被初创公司广泛采纳。谷歌就是其中的一个例子。

随着时间的推移，人们对这种面试方式产生了质疑。一些人认为它已经过时，不再适应现代招聘需求。Imran Gohry的FizzBuzz问题引发了公众的关注。Jeff Atwood在他的博客中写道，他对那些不能编写最基本程序的程序员感到震惊。同样，Dan Kegel在面试中也发现很多求职者无法完成基本的编程任务，即使他们拥有高学历背景。这些例子都表明，编程测试并不总是准确地反映出候选人的真实能力。

企业进行编程测试的真正原因并不是因为他们充斥着痴迷于算法的书呆子，而是因为他们遇到了很多简历光鲜亮丽、但实际操作能力欠缺的候选人。这种测试是为了识别那些夸大其词或虚张声势的候选人，戳穿他们的伪装。这种做法是否真的有效呢？每个组建开发团队的人都会遇到这样的问题——面试官总是在面试中遇到没有实际编程能力的人。企业需要更加科学和有效的招聘方式来确保找到真正具备实力的候选人。作为一名求职者，如果你想在面试中脱颖而出，达到以下标准将让你在竞争中占据优势：

（1）声称精通某种编程语言，那就要在面试中实际运用它。对于列出C++技能的求职者，拒绝在实际面试中使用C++编程将失去一个展示实力的机会。

（2）熟悉你的开发工具。如果你是Java开发人员，意味着你要熟练掌握在你所选IDE中创建项目、编写代码、运行程序及解析输出的流程。你应该熟悉编写和运行测试、使用调试器的技能。

（3）如果面试要求自带工具，那就带上你平时使用的工具去面试。不要尝试在面试过程中现场安装工具，这样会影响你的表现。

（4）掌握一些基本的编程要素，如集合、IO、字符串操作、循环、数据类型等。如果你是函数式程序员，你应该了解如何在适当的位置对列表进行实际操作。

（5）对你将要使用的编程语言有深入的了解，避免被语法或类型安全方面的常见错误所困扰。

对于那些具备以上能力的求职者，编程测试的重要性在于，经验丰富的工程师会明白这个门槛的价值，他们渴望加入一个技术精湛的团队。一个有效的招聘流程不仅是给面试官留下深刻印象的机会，也是给求职者留下深刻印象的机会。最好的同事往往会被那些具有挑战性的面试所吸引。在效率和误判之间取得平衡是构建软件公司的艺术之一。

从求职者的角度看，很多关于面试的恐怖故事并非来自那些初筛就被淘汰的人。那些对编程测试感到沮丧的人往往是因为觉得被要求解决复杂而不具有代表性的问题。

在面试中，最常见的问题包括自行实现排序函数、反转二叉树或进行图表搜索等。这种面试体验有时会让人回到大学学习的感觉，让实际编程经验被搁置，转而要求证明对理论课题的精通。这种情况下的求职者往往会觉得困扰和郁闷。不过对于那些热衷于啃《计算机程序艺术》这类书籍的程序员来说，他们往往能轻松应对这些问题。面对这种情况的讨论和质疑时，最普遍的解释是雇主可能并不专业或是过于模仿谷歌的招聘流程而忽视自身实际需求的考量。然而真正的原因相当平淡乏味：设计一个好的面试问题必须满足许多限制条件以满足面试的目的——快速提取求职者的技能信息。这类问题往往看起来像是典型的“算法类”问题但其实恰到好处，旨在确保面试的有效性和快速性。因此这些问题并非随意设置而是经过深思熟虑的结果。理想情况下一个面试问题应该能在短时间内解释清楚以便面试官能更专注于观察候选人的技能展示而非花费时间在解释问题上。对于那些愿意雇佣具有特定技能并在特定框架下工作的人的公司来说用这样的问题来面试是合理的选择因为这些问题的设计旨在快速筛选出符合他们需求的候选人。在R3公司，我们欢迎来自不同背景和专业的开发人员加入我们的团队。为此，我们坚持使用那些无需特定框架或技术，就能得出可靠答案的问题进行面试。

这些问题应该反映出我们对候选人编程能力的重视。编写返回虚假HTML的函数并不能真正检验候选人的编程实力。我们期望候选人能够熟练掌握循环、集合、类、IO等基础知识，并对标准库有大致的了解，而非对每一个API都了如指掌。

优秀的面试问题应该给优秀的候选人一个脱颖而出的机会。虽然我所提到的技能似乎非常基本，但这并不意味着我们的招聘标准低。一个好的编程测试应当在问题深度上足够，让优秀的候选人可以迅速且令人印象深刻地创建出比初学者更好的解决方案。通过足够的实践，面试官能够区分有经验的开发人员和初学者，即使他们提出的是相同的面试问题。

我们需要证据来证明候选人能够独立思考，接受并解决一个不会马上得出明显解决方案的问题，而非停滞不前或盲目套用以往的经验。这样的问题不需要特别精确，重要的是它不能通过简单地匹配候选人的以往经验来解决。这也是过程中最模糊的部分——测试应聘者的思维能力究竟意味着什么？它排除了大多数仅仅“套用别人编的代码来做这件事”的解决方案，尽管在实际工作中，这通常是有效的方法。

面试问题应当简短、易于解释，并且只使用基本的语言特性。它们可能有糟糕的或优秀的解决方案，但不会流于套用样板。这些问题旨在检验候选人是否真正掌握了大部分基础知识，而不是考察他们是否记得晦涩难懂的算法。不要过分强调你的答案是否具有理想的计算复杂度，至少不要在第一次尝试时这样做。面试官可能更关心代码是否干净、无bug，并且以快速有效的方式编写。如果有剩余时间，再回去优化也不迟。

由于缺少全球认可的认证机构和对特定技术技能的需求，招聘开发人员的流程比某些行业更加严格。从雇主的角度来看，这个流程在过去几年里已经有了显著的改进。对于乐于接受这类面试的求职者来说，他们有机会进入一个能力更均衡的团队，这样的团队中不会有无用的伪程序员。尽管存在对流程的抱怨，尤其是在没有采用这种面试流程的组织中，但我们必须认识到招聘在很大程度上仍有随机性。精心设计的面试流程总是比随机面试更好，但也会存在误判的可能。正如Spolsky提出的用实习代替面试的建议所显示的那样，尽管存在缺陷，但这种制度仍然难以克服。我们需要不断地努力改进招聘流程以确保尽可能准确地评估每个候选人的能力。