在过去的岁月中，我不但参加过很多场程序员面试，也亲手举办了许多。我清楚的知道搞砸面试的众多因素。最糟糕的情况就是，面试官通过一些晦涩难懂的技术知识以显摆自己的聪明睿智。
“错了！原因是将它类型强制转化为十六进制！“[“呵呵”，笑着用手指了指]
这件事曾真实地发生在我身上。至今让我记忆犹新。虽然最后他们还是愿意雇佣我，但我婉言拒绝了。这样的互动对双方都是一种折磨：不但封闭了应聘人员的技术思维，也让面试官获取不了他们真正需要的信息。
最好的编码测试可以让应聘人员和面试官一下子就明白将来共事的感觉和情境。所以，专业的编码面试应该具备以下三个特点：
1.开放式对话
良好的编码面试所提出的问题应该是开放式的，不受限制的。为什么呢？我们需要从对话中了解开发人员的喜好、风格和知识。我们的目标不是为了了解琐碎
小事，而是要对该应聘人员如何解决问题有一个整体的把握。具体的技术问题不应该放到编码面试中来，它们应该属于之后的技术面试。
编码测试的真正价值所在，是寻找一个真正的爱好者。
但也不必矫枉过正。
比如说，我对职业棒球大联盟一无所知。然而，关于犯规、投球以及罚球线我也能讲得头头是道。如果不进行开放式对话的话，你或许就会给我打上“对棒球
了解甚深”的标签了。但是，一旦你像一个真正的球迷一样跟我讨论棒球，或者找一个内行人来，那用不了20秒，我大概就会露马脚了：你会发现，我知道的只是
一些规则，一些皮毛。
编码面试也应当如此。你的知识是不是只停留在表面，要像照妖镜一样立马现出原形：不是因为我问的是棘手的问题，而是因为一旦我们讨论起创造性的解决
方案，是金子的才会发光。当然应聘人员偶尔说一句——“我不知道”也是完全可以接受的（总比信誓旦旦地给出错误答案要好！）。但是，如果应聘人员不能对他
们的解决方案说出个子丑寅卯来，那就必然不是一个真正的爱好者。这也是为什么对话的目的并不局限于单纯的测量知识层面上。
2.模拟现实
允许应聘人员选择技术和方法。他们的选择能说明很多问题。如果你正在寻找JavaScript开发人员，而对方恰巧通过创建服务器来呈现解决方案，
那就值得好好地谈一谈。允许应聘人员选择自己惯用的IDE。允许他们谷歌不知道的东西，就像他们在现实生活中那样。尽量模拟现实情境。在白板上用铅笔写代
码是不现实的。它会导致优秀人才的压力从而增加遗漏人才的风险。
接下来就让我在我的IDE上搞一个小时？呵呵，这也不现实。
相反，考虑到结对编程对实际问题的重要性，你也不必特意难为应聘人员。不妨将对方当成是帮你解决问题的同事。在此过程中，你还可以看到他如何使用IDE，搜索了哪些内容，以及攻克的重点是什么。
如果你正在创建一个标准化的测试，那么请确保它与岗位是相关的。例如，如果你正在为医疗行业构建Web应用，那么编码测试就应该是使用Web应用程
序来解决医疗相关的问题。一个好的编码测试能够让人预览今后的日常工作。无论是应聘人员还是面试官都应该对彼此成为同事有着美好的期许。
3.不要设定正确答案
创建一个简单的编码测试是很容易的，比如说， 反向字符串，计算斐波纳契数，或者打印fizzbuzz。但从这些链接上面我们可以发现，这些问题都是没有价值的。因为它们不鼓励对话，也不能代表我们在工作中需要解决的实际问题，而且谷歌或百度一下，答案就有了。
当然，你也可以在测试时禁止网上搜索，但是，请记住，一个良好的编码测试应该力求模拟真实的工作场景。在编码时禁止访问谷歌就像不允许厨师翻阅食谱
一样，都是很逗比的行径。事实上，良好的编码面试应该是开放式的，没有局限的，同样也没有所谓的“正确答案”。这样一来，不但解决方案不容易在网上找到，
还可以讨论应聘人员所选方法的优缺点。
就是这样。也不是那么难，对吧？
来源：51CTO
