是时候彻底放弃“高分低能”的 Leetcode了：AI 时代的面试需要大变革！

　　本文来自于微信公众号 InfoQ(ID:infoqchina)，作者:核子可乐、Tina。

　　随着软件开发行业正发生整体转变，我们越来越依赖 Copilot 和 GPT 等 AI 工具来生成代码、提高生产力，所以必然要据此调整对人才的甄选思路。

　　经验丰富的工程师也会过不了“编程面试”，特别是在没有花时间去复习Leetcode习题的情况下。现在很多人已经忘记了最初为什么面试时要做 Leetcode 题。实际上，Leetcode 来源于谷歌的一项面试研究，最初谷歌想确定最聪明的候选人通常也是最擅长算法的。谷歌聘用的重点是智商而非纯粹的编程技能，因此这导致他们的面试主要侧重于算法问题。后来，其他公司也效仿了谷歌的招聘模式，普遍开始问算法编程问题，逐渐整个行业的面试都围绕算法编程，而谷歌最初的研究目的逐渐被大家忽视。

　　算法虽然重要，但在面试场景下却是可以通过死记硬背的刷题方式来解决的，而且对于大多数软件公司来说，工作很大程度上是写在 CRUD 业务。特别到了现在，Copilot 和其他一些 GPT 编程工具已经被开发者们纳入到日常工作中，过分强调“Leetcode 能力”似乎也有一些不合时宜了。

　　花时间在 Leetcode 上练习一下常见的面试问题，然后依靠刷题进入大厂，这就是企业在为工程团队招聘新成员时想看到的效果吗?这事也要从正反两面来看:

　　虽然解决这些复杂的算法问题确实既有益、又有趣，但现实情况是，对于大多数高效开发者来说，我们的大部分编程工作跟这些毫不相干。也就是所谓“面试造火箭，上班打螺丝”。

　　大多数人在日常解决比较困难的编码问题时，主要会参考 Stack Overflow、技术文档和其他在线资源。我们会跟同行聊天，并将不同的思路写在白板上。而随着 AI 编码工具的爆发式增长，许多开发者已经开始将 Copilot 和 ChatGPT 纳入自己的工作流程。

　　对于大部分复杂问题，我们可能只需要处理一到两次，之后就能反复使用。所以说编写这种高度抽象的复杂代码不能说没有意义，只能说意义有限。

　　现在的面试习惯会创造出一种人为的情境，给开发者增添了压力。其实很多朋友都不喜欢在他人的注视下写代码。在现实生活中，也很少有人会给自己的编码任务设置固定的时间。面对难题，我们可能去散会步、跟同事交流、研究算法、先构建个小型实验代码库等。老实说，“心流”状态下的开发工作才是最富成效的，而压力面试显然跟这种状态没有一毛钱关系。

　　开发者会在自己熟悉的环境中使用自己喜爱的工具进行编码。使用不熟悉的工具反而让人迷失方向，并进一步增加他人注入下做开发的压力和焦虑。

　　总而言之，这种面试方法可能是在衡量错误的指标，所关注的东西对于候选人有效融入团队基本没什么帮助。

　　不仅如此，随着团队越来越依赖 AI 生成的代码(无论是 Copilot 还是 GPT)来提高生产力，如今快速理解代码并在更广泛的应用 / 场景上下文中识别细微缺陷，才是最具价值的关键能力。

　　GPT 为 Leetcode 中常见的 N-Queens 问题生成的答案。

　　因此现在已经有面试改换了重点，转向了审查代码、而非编写代码。这无疑是个重要启示，让我们意识到代码审查开始成为评估软件工程师的更好方法，而不再是专注于编码练习。

　　在面试中强调代码审查的八大理由

　　代码审查之所以能够在本质上提高面试效果，主要基于以下几个原因:

　　在 AI 时代，由 AI 生成的代码往往难以适应性能、安全性和内部最佳实践等实际要求(在受监管的行业中尤其突出)。在依赖这些零散生成的代码时，开发者必须有能力在整体项目上下文内有效评估代码质量、把握潜在风险。

　　这种方式能更好地反映工程师——特别是高级职务——所从事的日常工作。从长远来看，向同事、特别是初级团队成员提供有效的指导和意见反馈，更有助于提升整体生产力与代码编写质量。

　　这样可以更好地反映受试者是否具备全面的推理、思考和沟通视角。换句话说，更好地把握受试者加入团队后的整体表现，对其技术经验进行深入剖析。

　　代码审查在本质上更具协作性，而编写代码则往往是项比较孤立的工作(相信有不少开发者更倾向于在晚间一个人静静编写代码)。代码审查也许更能反映受试者在团队中的工作状态，所以效果可能优于让受试者直接解决技术难题。

　　代码审查中包含更多主观性因素，很多问题绝不是非黑即白。这就自然提供了更大的讨论和解释空间。由于不存在单一最优解，代码审查还让我们有机会面对更多异常情况。面对5位受试者，我们可以获得5种独特的观点;相比之下，以往的算法问题可能只对应少数几种最佳答案。

　　这种方式，也让受试者更难通过生成式 AI 或者 Leetcode 刷题的方式作弊。

　　这种方式更适合评估那些负责理解代码、而非直接编写代码的技术角色，包括工程经理、架构师和技术支持人员等。

　　这种方式能更好地反映受试者在初入团队后的表现:通过阅读代码来学习现有系统。很明显，考察这方面能力比衡量他们能否解决 N-Queens 问题更有实际意义。

　　具体策略

　　在代码审查中，我们还可以将以下几种策略搭配起来，借此衡量受试者的实际水平。这些策略的共同点在于，都更强调代码审查能力、而非代码编写能力。换言之，重要的不是能否在特定时间之内解决问题，而是能否适应现有代码库中的零散内容和团队遇到的实际挑战。

　　“道法自然”

　　从实际代码库中提取那些有意义、重要且有趣的部分，将它们作为审查工作的具体场景。比如说数据访问、异常处理、输入处理等等，这些都是审查受试者能否适应现有代码库，以及能否看懂、理解实际代码资产的好办法。

　　找出 Bug

　　故意引入一些逻辑缺陷或问题，看看受试者能不能顺利发现。比如说要求他们找到并处理最近公司里刚刚修复掉的 bug，看他们能否发现根本原因、打算如何解决该缺陷，他们的方案跟实际修复之间有何不同等。

　　重构与重新设计

　　可能公司刚刚对某些代码进行了重构，或者正打算进行重构，这时候就可以将重构前的代码作为素材，考察受试者如何看待原有代码、打算用什么策略规划和实施重构。另外，也可以询问受试者能否确定为什么有必要进行重构，并评估他们所提出方法的复杂性。大家可能会惊讶地发现，这绝对是种考察技术能力的全新途径、而且相当有效!

　　如果受试者表现良好，就基本可以认定他们能够快速融入现有工作流程。

　　以性能为导向

　　找点最近刚刚做过性能修复的代码，看看受试者能否发现导致一段代码运行缓慢的原因，包括他们能否提出算法、替代设计或修复思路以提高代码性能。

　　具体包括应用程序所需执行的现有 SQL DDL 架构及常见自然语言查询。或者删除索引定义，看看受试者能否提出索引或替代设计来提高性能。

　　不要询问什么 Big-O 表示法的原理，而应考察受试者能否真正发现数据访问代码中的那些 O(n^2) 代码或 N+1问题!

　　关注测试

　　选择一段代码并匹配一组代码单元测试，询问这是否涵盖了所有情况?还有哪些情况未能涵盖?如何对单元测试做改进?在即将到来的 AI 生成代码时代，这种判断力往往更加重要:理解领域空间和用例，以及如何编写高覆盖率单元测试(或者评估 AI 生成的单元测试的完整性)将成为一项关键技能。

　　安全嗅觉

　　选择包含微妙安全缺陷的代码，看看受试者能不能发现这些问题。不要单纯询问什么是 XSS 或者 SQL 注入攻击，而是要看他们能否意识到当前代码缺乏对此类攻击的保护机制。同样的，随着团队越来越多地依赖由 AI 生成的代码，这种从生成代码中发现潜在安全缺陷的能力将变得愈发重要。

　　最佳实践

　　对于更高层级的职位，则应考察他们能否把握最佳实践，并借此与技术新人 / 直接下属顺畅沟通、传授软件开发经验。拥有这种能力，才是一名好的技术管理者。

　　写在最后

　　在《平均的终结:如何在崇尚标准化的世界中胜出》一书中，Todd Rose 写道:几乎任何有意义的人类特质、尤其是天赋，总会包含多个维度。问题在于，当我们试图衡量一个人的才能时，却经常诉诸平均值，想要让参差不齐的个体简化为单一维度，例如标准化的考试分数或者工作绩效排名。

　　事实上，如果我们选择狭隘的问题解决技能，那么最终得到的就只会是“平均”或者说平庸的候选人。他们只是在简单学习并应付这些考察维度，反而让我们错过许多真正能够提升团队生产力的卓越人才。将代码审查作为面试中的团队技能考察指标，有助于更好地衡量受试者的整体技能水平，避免靠 Leetcode 刷题导致的“高分低能”问题。

　　随着软件开发行业正发生整体转变，我们越来越依赖 Copilot 和 GPT 等 AI 工具来生成代码、提高生产力，所以必然要据此调整对人才的甄选思路。机器人就能解决的算法难题，在考察受试者时应当占据更低的比例和权重。相反，未来的核心技能也许是阅读并审查代码是否正确、贯彻最佳实践并保障安全性等能力。

　　用代码审查替代 Leetcode 作为面试主体，不仅能帮助团队更好地对受试者做整体分析，更能强调其核心技能和团队协作表现等现实指标，为行业内软件构建范式的整体转变做好准备。