经验丰富的工程师也会过不了“编程面试”,特别是在没有花时间去复习 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,看他们能否发现根本原因、打算如何解决该缺陷,他们的方案跟实际修复之间有何不同等。
可能公司刚刚对某些代码进行了重构,或者正打算进行重构,这时候就可以将重构前的代码作为素材,考察受试者如何看待原有代码、打算用什么策略规划和实施重构。另外,也可以询问受试者能否确定为什么有必要进行重构,并评估他们所提出方法的复杂性。大家可能会惊讶地发现,这绝对是种考察技术能力的全新途径、而且相当有效!
如果受试者表现良好,就基本可以认定他们能够快速融入现有工作流程。
找点最近刚刚做过性能修复的代码,看看受试者能否发现导致一段代码运行缓慢的原因,包括他们能否提出算法、替代设计或修复思路以提高代码性能。
具体包括应用程序所需执行的现有 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/
年终盛会——QCon 全球软件开发大会·上海站将于 12 月 28-29 日在上海中优城市万豪酒店举办。此次大会策划了 LLM 落地应用、AI Agent 、Code Assistant 、业务安全 、金融科技 、信创软件集成开发环境技术 、LLM+ 质量效能 、高性能网关等方向。
本次大会以「启航·AIGC 软件工程变革」为主题,目前大会议题正在同步征集中,点击「阅读原文」即可查看详情。现在购票即可享受 7 折优惠,立减 ¥2040。咨询购票可联系票务经理 18514549229(微信同手机号)。
今日荐文
你也「在看」吗? 👇