作者 | 赵钰莹
最近，一篇题为《"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 多年，很难想象有什么问题是通过搜索就可以得到答案的，因为大部分问题都是与业务逻辑相关的，很难找到答案。
对于事情发生后的处理方式，很多网友也提出尝试通过沟通引导这些程序员知道自己的任务范围，隐藏的问题，训练这些人逐渐掌握主动权，克服可能的障碍并鼓励在遇到问题时主动寻求沟通，这与远程还是面对面并没有必然联系。
