快一年才发现新来的程序员全靠谷歌搜索混过面试和解决问题，这是哪里出了纰漏？

作者 | 赵钰莹

最近，一篇题为《”Google” programmers. How one idiot hired a couple more idiots》的文章在 Reddit 上引发了网友的激烈讨论，这是一位招聘者的自述，他在文章中介绍了自己如何精心设置面试流程，可过了八个多月才发现新招来的程序员大部分都是靠谷歌找代码和解决用户问题，这是哪个环节出了问题呢？

八个多月才发现，

招来的程序员全靠“谷歌搜索”

博客的作者 @nmivan 曾经在聘用新程序员方面有着不错的经验，因为他之前招聘进来的一些程序员在后来成为了当地 IT 领域的重要专家，这些人的面试流程是先口头回答一些问题，然后在纸上手写代码完成给定的编程任务。

鉴于现在的程序员都是直接在电脑上编程，所以 @nmivan 改变了面试流程，在提问环节结束后，给候选人一台电脑让其独自解决编码问题，在这半小时到一小时之内，候选者独处一室，无人打扰，当 @nmivan 再次返回，候选人就会给出一个现成的解决方案，这些方案不仅代码漂亮且优化得很好，通过这样的面试流程，@nmivan 招聘到了一些新的程序员进入公司。

在最初几个月，这些程序员确实表现得很好，甚至不需要任何帮助就可以解决问题，等到了第 3 到 6 个月，@nmivan 发现这些程序员集体进入了瓶颈期，生产力很难有所突破，但这些问题被归咎于是疫情之下的远程工作造成的，等到第 8 个月重回办公室工作，生产力依旧没有任何提升，@nmivan 只好亲自解决问题，尝试对这些程序员提供帮助，但发现效率低下，所以决定还是要从“根”上想办法——技术面试。

依旧是机考，但这次 @nmivan 在场全程盯着求职者，并计划从基础开始逐步提高难度。

离谱的是，这个计划在基础阶段就结束了，只有十分之一的求职者了解如何使用基本实体、类型；更糟糕的是，只有 2-3 人在使用内置帮助和上下文代码补全的情况下才勉强完成得不错。

@nmivan 对这个结果十分震惊：这些人根本就找不到属性和方法，更别说使用了，他们甚至连最基本的任务都做不了，可之前的优异表现是怎么回事？

直到一个人在测试期间问了一句：“我能谷歌一下吗？”@nmivan 恍然大悟，意识到了问题所在。

对这个结果，@nmivan 越想越生气，他可以理解大家通过网络搜索了解一些原理性的内容，也可以理解通过这种方法快速查找一些针对性资料，但不能接受这些人从网站上直接复制一些对程序员而言最基本的东西。

面对质问，这些程序员表示：“这有什么大不了的？”这种态度让 @nmivan 更加无力，他认为问题出在了自己身上，当然是面试过程出了问题。

这也很好地解释了为什么这些程序员在 3 到 6 个月就开始进入瓶颈期，因为并非所有代码都在网络上找得到。

到底是哪个环节出现了问题？

在博客的评论区，很多人对这篇文章提到的“技术面试流程”给出了自己的想法，当然大部分人认为这个面试流程确实有问题，但作者后期的处理方式也不够完善。

很多网友都提到如果希望衡量求职者才采用新技术或者使用工具解决方案的熟练度，可以在机考之前花一点时间解释代码库，再给求职者一些时间在实际代码中调试问题，这可可能是一个与架构相关的问题，比如创建一个脚本 / 应用程序（以任何具有完全互联网访问权限的语言），可以授权端点并使用获得的信息从另一个服务获取和列出一些信息等，而不是仅仅告诉求职者解决他们可能已经在 LeetCode 上见过很多次的算法问题，在一些告高阶程序员的面试中，对算法逻辑的理解深度可能更胜于一个漂亮的解决方案。

也有网友提到 VS 上有实时共享编码的功能，如果看到求职者的屏幕上突然出现大块的代码，很明显这是在通过复制粘贴解决问题。

至于“谷歌搜索”，大部分网友认为如果是通过搜索就可以解决的问题，没必要非得通过其他方式获取认知，比如口口相传，显然搜索的方式更加高效。而且，如果有合适的代码库或者依赖可用，也没必要重复造轮子。当然，也有网友提到自己工作了 20 多年，很难想象有什么问题是通过搜索就可以得到答案的，因为大部分问题都是与业务逻辑相关的，很难找到答案。

对于事情发生后的处理方式，很多网友也提出尝试通过沟通引导这些程序员知道自己的任务范围，隐藏的问题，训练这些人逐渐掌握主动权，克服可能的障碍并鼓励在遇到问题时主动寻求沟通，这与远程还是面对面并没有必然联系。

延伸阅读：https://pvs-studio.com/en/blog/posts/0952/

技术招聘面试，到底该如何设计？

面试是个双向选择，企业在面试候选人时，候选人也在考察企业，糟糕的面试体验，常常会错失优秀的工程师。如果招聘流程可以影响到团队的价值观和优先级，那么好的招聘流程也能促成好的工程团队文化。好的招聘流程包括三个要素：快速回应、测试驱动、沟通。

如果在面试中碰到好的候选人，在面试结束时对他们说：“你最迟在两天内可以收到我们的通知，如果没有，请直接给我发邮件”。如果候选人在某个领域有很大的影响力，那么就没必要花两个礼拜的时间才把他们招进来。如果动作慢了，就会错过优秀的候选人，从而浪费了时间，还会养成错失良机的习惯。

如果你的客服回应时间比招聘回应时间还要快，那说明你们的招聘流程是很糟糕的。如果想招到优秀的开发人员，在面试后的两天内就要做出回应。没错，就是两天。一个小公司可以在 48 小时远程招聘一个员工，从筛选简历到发出录用通知书。好的开发者在找工作时总是对具有挑战性的工作虎视眈眈。

测试驱动式的招聘

测试驱动开发不管是在理论上还是在实际当中都是一个很好的实践。一个好的 TDD 流程包括：

• 在开始编码之前定义好验收标准。

• 为测试做好准备。

• 找出边界情况。TDD、BDD 或敏捷的起点都是一样的：在动手实现之前先把事情想清楚。借鉴他人的经验来改进你的招聘流程自然是一件很容易的事情，不过不要只是简单地模仿。

在一个好的软件工程团队里，你会在编码之前先想好代码需要完成哪些功能。如果你是一个前端开发人员，你会与利益相关者沟通，这样就会明白他们的期望是什么。如果你在开发一套 API，你会与 API 的重度使用者沟通。如果你在做性能优化，你会先搞清楚你的目标是什么，以及如何验证是否已经达成目标。

类似的，在面试之前，先想清楚你想要招什么样的人。与用人的团队沟通，问问他们的需求是什么。想想你最喜欢和最不喜欢的同事。不要忽略了那些你不喜欢但是对团队很重要的同事。能为团队带来作用的人都有哪些特点？他们身上有哪些不足？在想清楚这些问题之后，开始进行面试，就像运行测试用例那样。先进行测试，然后是更复杂的验收。

如果希望候选人能够马上上手工作，那么就看看他们会不会使用真实的开发工具。如果想要学习能力强的候选人，那么就面试他们学习新技术的能力。

记住，好的测试并不是要最大化测试的通过率，而是要测出代码的行为是否符合预期。在测试按下按钮是否能触发指定的事件时，并不需要显式地测试按钮是否存在（假设如果按钮不存在就不能点击）。类似的，你的招聘流程不应该总是验证与候选人不是很相关的事情。除非你真的需要候选人能够背出很复杂的算法或者能够用马克笔手写代码，否则不要试图去验证他们是否真的能做到这些。

最糟糕的情况是，如果你没有定义好清晰的验收标准，你有可能招到错误的人。那么最好的情况呢？最好情况是，你招聘流程的大部分仍然带有不确定性。

沟通好过文档

在一个沟通积极的小团队里，几乎可以不需要任何文档。而在一个缺少沟通的团队里，再多的文档也无济于事。用于招聘的工具林林总总，不过简短快速的交流胜过最好的打分系统，比如“我对这个人很感兴趣”或“他们虽然与我们的文化不契合，不过我认为他们在技术面试中会有出色的发挥”。文档无法替代培训和人与人之间的信任，也无法替代尽早的沟通和开放性的谈话。

此外，一个最重要的指导思想——尊重候选人的时间。很多企业的面试题，常常疏忽考虑了面试者对于本公司业务的情况，完成试题常常需要半天或者一天的时间，面试体验极差面试。技术招聘的面试题目通常在 2-3 个小时为宜。

技术招聘对企业至关重要，如果只招聘填鸭式或算法式的员工，当他们交付出没有品味的产品时，也无需感到惊讶。设计良好的技术招聘体验，一定是企业着重需要发力之处。

本文文字及图片出自 AI前线