是时候彻底放弃“高分低能”的 Leetcode了：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 作为面试主体，不仅能帮助团队更好地对受试者做整体分析，更能强调其核心技能和团队协作表现等现实指标，为行业内软件构建范式的整体转变做好准备。
参考链接：
https://chrlschn.dev/blog/2023/07/interviews-age-of-ai-ditch-Leetcode-try-code-reviews-instead/
声明：本文为 InfoQ 翻译整理，未经许可禁止转载。
今日好文推荐B 站广州研发工作室解散；外媒曝光苹果中国区丑闻；OpenAI 被曝已叫停新大模型项目 | Q 资讯
“MySQL 之父”的 MariaDB 要完蛋了？叫停两款核心产品并裁员 28%，分析师：该行为无异于自毁长城剑指 Kubernetes！微软发布开源平台 Radius：高效构建、运行云原生应用程序
前端根本不需要构建！“技术邪教” Ruby on Rails 之父再出激进言论引争议 活动推荐
年终盛会——QCon 全球软件开发大会·上海站将于 12 月 28-29 日在上海中优城市万豪酒店举办。此次大会策划了 LLM 落地应用、AI Agent 、Code Assistant 、业务安全 、金融科技 、信创软件集成开发环境技术 、LLM+ 质量效能 、高性能网关等方向。
读者福利