“谷歌式”面试真心是让人又爱又恨，它糟糕透了：好的应聘者落选，坏的应聘者背背答案就能通过，呵呵。
这是真的。
但是，这也是真的：所有的面试过程都很糟糕。
以往的经验
论点：“我们应该根据他们以往的经验来决定要不要聘用他们。他们以往的成就？他们给曾经就职的公司带去了哪些价值？这才是肯定他们是否优秀的最好的办法。”
问题：
-
你不是在根据他们曾经的行为做判定，而是在根据他们如何描述自己的行为做判定。（这类问题的回答是可以通过培训的。相信我，我已经教过很多人，让这些原本很有可能会以失败告终的应聘者成功上任。）
-
应聘人员可能会夸大他们做的事情，使其听起来更令人印象深刻。
-
应聘人员可能不会将他们的所做的成绩归功到自己身上（将功劳推给团队，或者没有很好地说明项目为什么很难）。特别是女性和负责人更趋向于将他们的个人成就归因于团队，虽然原因各不相同。
最佳做法：
-
谈得更深。不接受表面化的答案。
-
关于开发中的个人贡献，要重点关注技术挑战，而不是关于领导力，冲突等方面的问题。要注意回答者说话的艺术，因为哪怕其实个人贡献并不大，也可以把话说得很漂亮。
引荐
论点：“你应该聘请被引荐的人，聘请那些同事推荐的人。但是请确保一定要彻底检查这些引荐。”
问题：
-
只雇用你曾经共事过的人无法很好地规模化。
-
一个平庸的应聘人员也可以让其他人帮他讲好话。这就会导致我们无法去伪存真，所以你不能冒险使用这样的招聘策略。
-
如果应聘人员还在职，你也不能和他们目前的雇主对质。
最佳做法：
-
审核推荐信。要保持怀疑的态度。可能这个应聘人员很棒，但他的推荐信上面啥也没说。也有可能一个平庸的应聘者却有着好话连篇的推荐信。
-
如果是现任员工的推荐，也不要冒险启用。还是先验证了他与大家之间能否密切合作再说。
Github&作品样本
争论：“查阅应聘人员的Github或作品样本。这种方式可以让你知道他们真正能做什么，以及他们在现实世界中是如何工作的。”
问题：
-
不能扩展。很多人不愿意投入工作以外的编程工作，或做了，但并不想公之于众。
-
容易排除和忽略女性开发人员。她们肩负着更多的家庭责任，因此往往没有更多的时间投入到工作以外的编码项目。
-
作品样本展示的是当前的代码质量，看不出他们受到的培训。许多人（尤其是那些经验较少或从来没有工作于一家拥有严格的编码指导原则的公司的开发人员）可能写出来的代码很马虎。但这并不意味着他们就一定是糟糕的编码人员。稍微培训一下就可以改善他们的编码风格。
-
这种方法很难识别智力/解决问题能力。
最佳做法：
-
可以看看他们的代码，但是要有保留地接受对代码风格的解释。将根本性的问题从可修复的问题中划分出来。
-
如果你有大量的招聘需求，那么就不要仅依赖这个条件。你会排除很多求职者。
-
要注意这种方法的局限，比如说看不到智力/解决问题的能力。
家庭作业
争论：“要想评估他们的真正能力，可以给他们一个家庭作业或项目。这不但可扩展，而且模拟了真实情况。”
问题：
-
很多应聘人员不会去做长时间的家庭作业，特别是那些有着其他责任或其他工作选择的开发人员。
-
求职者可以从朋友那儿获取帮助，特别是如果碰到棘手的算法部分。所以不要指望他给你的成果可以真正代表他的能力。（这并不意味着你就不能使用这种方法，你只是不能完全依赖这种方式而已。）
-
和上面碰到的问题一样，你无法知道应聘人员真实的代码风格。
最佳做法：
-
公平对待应聘人员。平衡实用和时间的要求。如果你给的是一个时间较长的项目，它就应该在很大程度上可替代面试。请注意，这也意味着你会失去那些有着其他责任的应聘人员。
-
1-2小时这样简短的测试就非常好，就能够用来剔除掉那些问题解决能力和编码能力弱的开发人员。不过这可以作弊，所以在实际的面试中你也需要自我评估。
-
通过培训和指导将编码的根本问题从可修复的问题中区分出来。
知识
争论：“开发人员需要具备一定的学识。如果不了解自己的领域，那就可能会导致出现大量的bug和其他有害之处。显然的，知识和经验是有价值的！”
问题：
-
好的开发人员通常会在工作中去学习新的编程语言。如果你有轻松学习新知识的技能，那么你就能在众多候选人中脱颖而出。
-
如果一个程序员标 榜自己是特定的编程语言使用者，那么他解决问题的能力通常更弱。所以这是一个糟糕的属性。优秀的开发人员不太愿意将自己定性为“Java开发者”或 “PHP开发人员”，更愿意自称是开发人员。可能他们现在使用的是某种特定的语言，但是他们知道他们还会去学习下一种语言。（不过，他们可能会说自己是一 个前端开发人员或后端开发人员。）
最佳做法：
-
掌握知识是一个艰难的过程。如果你打算学习某种特定的语言或技术知识，那就应该去学习真正的专业知识。可以轻松掌握的知识通常是没有用的知识，因为不但是你，其他人在工作中也可以学会。有一个例外是，缺乏基本知识会让你的工作亮起红牌。
-
评估一下你是否真的需要特定语言的专业人才。大多数中大型企业都是不需要的。因为开发人员会在工作中学习编程语言。所以其实你有足够多的人才来满足你的需要。
解决问题/算法+白板编码
争论：“想找聪明的开发人员。聪明的人才能做好开发工作。”
问题：
-
你希望应聘人员能够具备某些关于数据结构和算法的知识，虽然这些知识在实际工作中并不常用到。
-
很多应聘人员会提前学习很多内容，因为他们知道面试要问的问题逃不出这些。在这种情况下，你其实评估不了解决问题的能力，因为你考察的只是重复回放算法的能力。
-
很多开发人员在面试时会很紧张。所以他们可能会面试失败，即使他们或许真的可以依靠自己来解决这些问题。
-
白板编码是不现实的。没人会在白板上写代码，这种方式导致代码人员犯一些在工作中不一定会发生的错误。此外，白板编码又慢又让人痛苦。
最佳做法：
-
你问的问题应该是具有挑战性和不寻常的。不要问一些常见的问题。
-
面试官提出的算法问题不应该仅仅是正确性的问题。提出问题的目的是评估应聘人员解决问题的能力，所以如果你想真正见识他们的实力，应该看他们是如何解决难题的。不要提一些显而易见的问题。
-
白板编码非常慢，又会导致很多错误。不要让应聘人员在代码中写一些对评估没有用的细节内容。你也可以提供笔记本电脑，如果应聘者觉得更舒适的话，当然这也有其不足之处。
-
不使用只有单一难点或障碍的问题。这样才能多方位地考察应聘人员的实力。
-
想一些你希望应聘人员知道的数据结构、算法和概念问题，并尽可能公平。二叉搜索树和广度优先搜索就相对公平；实现红黑树则不是。此外，面试官提出的问题不应该超越大范围知识。尽可能地让那些不具备计算机科学知识（或已经毕业很长一段时间）的应聘人员都有一个公平的机会。
-
知道什么时候你确实需要专业知识。有些技能是很难掌握的，即使那人真的很聪明。
都是糟糕的面试，那有没有不糟糕的？
上面讲述的所有的面试方法都有问题。是的，没错，都有问题。
很多顶级企业还大量采用算法式面试，当然许多其他公司也采用了别的过程方法。
但是，都很糟糕，都有问题。
那么……你能做什么？
接受一点：任何面试方法都是有缺陷的，都是糟糕的。
所以，我们需要找出最不那么糟糕的一种。然后好好实现。
这意味着：
-
确定你需要哪些技能（掌握起来是否现实）。各个技能的权重？真正的问题？你能给予什么帮助？
-
确定你如何（或者是否要）评估每种技能。什么样的问题或方法会有效？（你也可以选择多种方法。）
-
这种方法有什么问题？如何减轻这些问题，至少部分问题？
-
创建一个与这种方法保持一致的面试培训计划。
-
通知应聘人员你的期望。他们需要知道自己将要面对什么。
这么做，虽然你的过程还是不够完美——也永远达不到完美——但绝对会比以前更好。
译文链接：http://www.codeceo.com/article/programmer-broken-interview.html
英文原文：Developer Interviews are Broken, and You Can't Fix It
