1.开放式对话

良好的编码面试所提出的问题应该是开放式的，不受限制的。为什么呢？我们需要从对话中了解开发人员的喜好、风格和知识。我们的目标不是为了了解琐碎小 事，而是要对该应聘人员如何解决问题有一个整体的把握。具体的技术问题不应该放到编码面试中来，它们应该属于之后的技术面试。

编码测试的真正价值所在，是寻找一个真正的爱好者。

但也不必矫枉过正。

比 如说，我对职业棒球大联盟一无所知。然而，关于犯规、投球以及罚球线我也能讲得头头是道。如果不进行开放式对话的话，你或许就会给我打上“对棒球了 解甚深”的标签了。但是，一旦你像一个真正的球迷一样跟我讨论棒球，或者找一个内行人来，那用不了20秒，我大概就会露马脚了：你会发现，我知道的只是一 些规则，一些皮毛。

编 码面试也应当如此。你的知识是不是只停留在表面，要像照妖镜一样立马现出原形：不是因为我问的是棘手的问题，而是因为一旦我们讨论起创造性的解决方 案，是金子的才会发光。当然应聘人员偶尔说一句——“我不知道”也是完全可以接受的（总比信誓旦旦地给出错误答案要好！）。但是，如果应聘人员不能对他们 的解决方案说出个子丑寅卯来，那就必然不是一个真正的爱好者。这也是为什么对话的目的并不局限于单纯的测量知识层面上。

2.模拟现实

允 许应聘人员选择技术和方法。他们的选择能说明很多问题。如果你正在寻找JavaScript开发人员，而对方恰巧通过创建服务器来呈现解决方案，那就值 得好好地谈一谈。允许应聘人员选择自己惯用的IDE。允许他们谷歌不知道的东西，就像他们在现实生活中那样。尽量模拟现实情境。在白板上用铅笔写代码是不 现实的。它会导致优秀人才的压力从而增加遗漏人才的风险。

接下来就让我在我的IDE上搞一个小时？呵呵，这也不现实。

相反，考虑到结对编程对实际问题的重要性，你也不必特意难为应聘人员。不妨将对方当成是帮你解决问题的同事。在此过程中，你还可以看到他如何使用IDE，搜索了哪些内容，以及攻克的重点是什么。

如 果你正在创建一个标准化的测试，那么请确保它与岗位是相关的。例如，如果你正在为医疗行业构建Web应用，那么编码测试就应该是使用Web应用程序 来解决医疗相关的问题。一个好的编码测试能够让人预览今后的日常工作。无论是应聘人员还是面试官都应该对彼此成为同事有着美好的期许。

3.不要设定正确答案

创建一个简单的编码测试是很容易的，比如说， 反向字符串，计算斐波纳契数，或者打印fizzbuzz。但从这些链接上面我们可以发现，这些问题都是没有价值的。因为它们不鼓励对话，也不能代表我们在工作中需要解决的实际问题，而且谷歌或百度一下，答案就有了。

当 然，你也可以在测试时禁止网上搜索，但是，请记住，一个良好的编码测试应该力求模拟真实的工作场景。在编码时禁止访问谷歌就像不允许厨师翻阅食谱一样， 都是很逗比的行径。事实上，良好的编码面试应该是开放式的，没有局限的，同样也没有所谓的“正确答案”。这样一来，不但解决方案不容易在网上找到，还可以 讨论应聘人员所选方法的优缺点。

就是这样。也不是那么难，对吧？