写点什么

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

  • 2023-10-23
    北京
  • 本文字数:3481 字

    阅读完需:约 11 分钟

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

编译 | 核子可乐、Tina

 

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

 

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

 

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

 

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

 

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

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

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

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

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

 

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

 

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



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

 

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

 

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

 

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

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

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

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

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

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

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

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

  8. 这种方式能更好地反映受试者在初入团队后的表现:通过阅读代码来学习现有系统。很明显,考察这方面能力比衡量他们能否解决 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/

 

2023-10-23 13:233705

评论 1 条评论

发布
用户头像
有参考意义
2023-10-24 10:14 · 浙江
回复
没有更多了
发现更多内容

中国农发行的全面预算管理新举措

用友BIP

全面预算

软件测试—性能测试的专业术语1

测吧(北京)科技有限公司

测试

软件测试 | 性能测试误区(二)

测吧(北京)科技有限公司

测试

JMeter笔记11 | JMeter事务

测试 Jmeter 性能测试 自动化测试 接口测试

API网关-APISIX简介

天翼云开发者社区

云原生 API

用好支付宝小程序云云开发,告别繁琐的小程序开发流程

TRaaS

小程序 支付宝小程序

TRUNCATE 语句到底因何而慢?

爱可生开源社区

MySQL 源码 innodb TRUNCATE

数智人力:如何通过搭建全球人才供应链帮助企业海外扩张?

用友BIP

人力资源 数智人力

社交泛娱乐全球化,看融云出海如何助力玩法创新催生长线黑马?

融云 RongCloud

音视频 融云 泛娱乐 出海 通讯

华为云苏光牛:坚持产品能力的升级,做金融数字化的坚实数据底座

华为云开发者联盟

华为云 华为云开发者联盟 企业号 6 月 PK 榜

中国移动云能力中心捐赠 secScanner 和 ksPack 项目,助力openEuler社区繁荣发展

openEuler

Linux 操作系统 openEuler 移动云 开放原子基金会

软件测试—性能测试的专业术语2

测吧(北京)科技有限公司

JMeter笔记12 | JMeter集合点

测试 单元测试 Jmeter 性能测试 接口测试

霍格沃兹测试开发学社线下班开班啦!无offer返学费哦!

测吧(北京)科技有限公司

测试

一文读懂火山引擎A/B测试的实验类型(2)——可视化实验

字节跳动数据平台

A/B 测试

合约交易所系统开发搭建流程

薇電13242772558

系统开发

软件测试 | 性能测试的种类有哪些?

测吧(北京)科技有限公司

测试

SCADA系统架构的类型

2D3D前端可视化开发

物联网 web组态 工业自动化 SCADA 工业组态

OpenHarmony社区运营报告(2023年5月)

OpenHarmony开发者

OpenHarmony

如何提升企业在全面预算中管理组织水平?

用友BIP

全面预算

四行代码开启流计算之旅

吴英骏

数据库 开源 流计算 云原生 存储

软件测试 | 性能测试的误区(一)

测吧(北京)科技有限公司

测试

华为云邓明昆:云原生时代,以开源赋能数字化转型

华为云开发者联盟

云原生 后端 华为云 华为云开发者联盟 企业号 6 月 PK 榜

快速掌握 Axios 请求库的基本用法

Liam

程序员 开发 HTTP API axios

国外服务器助力你的网站实现全球业务拓展!

一只扑棱蛾子

国外服务器

数字底座的连接集成加速数智企业互联互通

用友BIP

数智底座 数字底座 连接集成

openEuler+Linaro合作成果展示|2023开放原子全球开源峰会

openEuler

Linux 开源 操作系统 openEuler linaro

冠军!天翼云在国际AI顶会大模型挑战赛中拔得头筹!

天翼云开发者社区

人工智能

沉浸式下载Niconico视频到手机相册,手残党们快快跟上!

frank

70+页实战经验分享,《研发效能红宝书》重磅发布 | 附下载

思码逸研发效能

研发效能

是时候彻底放弃“高分低能”的Leetcode了:AI时代的面试需要大变革!_团队搭建_Tina_InfoQ精选文章