2026年5月，一位候选人走进Google面试室，接到的是60分钟多文件代码阅读任务——旁边坐着能随时调用Gemini的AI助手。
一、一道让LeetCode信徒沉默的面试题
Google新面试长什么样：读代码、找Bug、调AI
Google 2026年5月启动试点，用 Code Comprehension 轮次替换传统编码面试环节，面向 L3 和 L4 软件工程师岗位，覆盖部分美国团队。
面试形式是60分钟，候选人在 CoderPad 里拿到一个不熟悉的多文件代码仓库，语言可能是 C++、Java 或 Go。题目不给算法提示，不要求手写二叉树反转，而是要求完成三件事：找到代码里的 bug，提出改进方案，和设计面试官讨论架构取舍。
允许调用 Gemini。这意味着候选人可以问 AI「这个函数为什么抛出这个异常」「这段代码的性能瓶颈可能在哪里」，而不是被要求凭记忆写出最优解。
Agent 运行时过载
Google 的逻辑很直接：真实工程场景里，开发人员大部分时间在理解别人的代码，而不是从零发明算法。面试应该反映这个现实。
Databricks 工程师 Yuchen Jin 在 X 平台公开质疑 LeetCode 模式。他的核心论点很简单：LeetCode 主要考察记忆力，而 AI 时代，即使是 3B 参数的小模型也能比人类更快解完这些题。企业继续用这种模式筛选人，是在考察已无价值的技能。
更狠的是，他引用了 Google 自己拒绝 Homebrew 作者 Max Howell 的例子：「你们 90% 的工程师都在用我写的软件，但你不会反转二叉树，所以滚蛋。」
这句话讽刺意味拉满。AI 面试不是噱头，是行业对算法题面试失效的承认。
候选人实测：60分钟对抗万字多文件仓库
有候选人分享了体验。多文件仓库规模约一万行，涉及配置、工具函数、业务逻辑多个模块。任务不是写新代码，而是读懂、定位问题、提出改进。
时间压力很大。60分钟内要完成代码阅读、问题定位、方案设计、与面试官讨论。Gemini 能帮忙解释代码，但候选人的核心能力体现在：能否快速建立代码地图、能否判断优先级、能否清晰表达问题。
一位候选人描述：「以前刷 LeetCode，目标是写出最优解。现在要读懂别人的烂代码，找出问题，并用 AI 辅助验证猜想。」
这本质上是工程能力的重构。不是会不会写代码，而是会不会看代码、会不会问问题、会不会用工具。
Code Comprehension 面试流程
这种变化背后是 AI 改变了编程的工作方式。当 AI 能帮你写代码、查文档、解释逻辑，面试考察的重点自然从「能不能写」转向「能不能判断」。
二、Yuchen Jin为什么炮轰LeetCode
AI时代，背诵算法模式已成原罪
Yuchen Jin在X平台上发过一条被转发了不少的内容：「AI会在编程领域率先被攻克，因为代码输出可以被单元测试验证——但对的地方，不一定是好的地方。」
这句话里有两层意思。第一层说的是事实判断：编程是唯一一个产出物可以被机器自动验证的领域。写出来的代码跑不跑通，一跑就知道。第二层说的是价值判断：能写出「对」的代码是一回事，能写出「好」的代码是另一回事。后者需要的不是算法记忆，而是对现有代码的理解能力。
背诵算法模式还能走多远
LeetCode刷题的本质是模式匹配。二叉树遍历、滑动窗口、动态规划——每个题型都有固定套路。过去这套筛选机制至少保证了候选人的基础算法能力，但在AI已经能秒解这些题目的时代，考察点必须重新校准。
Databricks工程师的3B模型测试实验
Yuchen Jin的实际测试提供了一个量化的参照点。他让一个只有3B参数的开源模型去刷LeetCode典型题目，结果显示模型在很多中等难度的算法题上表现稳定。这意味着，一个普通工程师在面试中引以为傲的「我一周刷了50道LeetCode」，在AI面前已经不具备区分度。
更重要的是，Jin在另一条推文中提到了一个经典的案例：Google曾拒绝Homebrew创始人Max Howell的工程师申请，理由是「你不能在白板上手写二叉树反转」。这条推文后来被大量引用，因为它揭示了一个荒谬的事实——一个创造了被90%工程师使用的工具的开发者，会因为一个基础算法题而被淘汰。
当3B模型能在你刷力扣前解完题，面试官考察的只能是你能不能看懂别人写的屎山。这不是夸张，而是Google新面试轮次的设计逻辑。
三、Google的Code Comprehension到底在考什么
从「写出答案」到「读懂代码」
Google在2026年5月试点的Code Comprehension轮次，考察的是候选人在多文件代码仓库中的理解能力。候选人在CoderPad中面对的是一个不熟悉的代码库，任务是找出bug、提出改进建议、讨论设计决策——并且可以使用Gemini AI作为辅助。
代码阅读比写代码更考验耐心
这种设计的核心转变在于评估重心的迁移。传统编码面试问的是「能不能写出正确的算法」，Code Comprehension问的是「能不能理解一段已经存在的代码」。后者更接近日常工作的真实状态。工程师入职后面对的从来不是一个空白的文件，而是一个需要阅读、理解和改进的既有系统。
Databricks内部的技术面试也在向类似方向演进。根据公开的招聘反馈，越来越多的团队开始在面试中加入代码阅读和缺陷定位环节，以替代纯算法题。这不是Google独有趋势，而是整个行业在AI能力提升背景下的被动调整。
多文件仓库里的真实战场
Code Comprehension的难度不在单个函数，而在跨文件的依赖关系。候选人需要理解模块之间的调用链、数据流向、异常处理逻辑。这才是真实工程中工程师每天花费的时间——阅读代码、理解上下文、判断修改的影响面。
Jin在LinkedIn上讨论这段观点时，有另一个关键补充：「AI能写的代码是结构良好的代码，但现实中的代码库是由无数人接力维护的产物。」这意味着，未来的面试不再考察你「能写出什么」，而是考察你「能理解什么」。
读懂代码是工程师的核心能力
这一转变对候选人的直接影响是准备方式的改变。背诵算法模板的价值在下降，阅读开源项目、参与代码评审、理解大型代码库的能力价值在上升。这也是为什么一些正在准备新面试模式的团队开始强调「代码品味」而非「解题速度」。
四、面试题变了，准备方式也得变
LeetCode还有价值吗
说LeetCode没有价值是错的。它在考察基础算法思维和边界条件处理能力上仍然有效。问题在于：当AI已经能完成这些任务时，面试官考察的重点必须转移。
更准确地说，LeetCode的价值在于训练思维严谨性，但面试的核心应该是评估工程判断力。这两者不冲突，只是权重不同。对于初级工程师，算法基础仍值得关注；对于需要独立负责的岗位，代码理解能力更重要。
新面试模式下的可执行建议
面对Code Comprehension这类新面试形式，候选人可以尝试以下准备方向：
- 找一个中等规模的开源项目，通读其核心模块的代码结构。
- 练习在代码中找到潜在bug和边界case。
- 尝试用自然语言描述一段代码的设计意图和数据流向。
- 理解常见的设计模式在实际代码库中的体现方式。
刷题不如读代码
更重要的是，候选人需要重新定义「准备好了」的标准。不再是「刷了多少道题」，而是「能否在陌生代码库中快速定位关键逻辑」。这是工程师日常工作的真实状态，也是新面试模式想要筛选的能力。
五、这场变革的边界在哪里
算法题不会一夜消失
Code Comprehension是趋势，但不是唯一标准。很多团队仍在混合使用算法题和代码阅读题，原因包括：算法题便于规模化筛选、代码阅读题评分主观性更高、不同岗位对能力的侧重点不同。
Jin的批评针对的是「只用算法题筛选工程师」这一极端做法。行业不会完全取消算法面试，但权重正在重新分配。那些坚持只用LeetCode作为唯一筛选标准的公司，可能会在未来面临人才流失——不是因为公司不够好，而是因为人才流向更贴近真实工作的评估方式。
面试官和候选人的共同选择
这场变革的最终受益者是那些真正热爱工程的人。算法记忆只是入门门槛，代码理解和工程判断才是长期的竞争力。当面试不再考察背诵能力，而是考察理解能力，候选人的准备方向自然会跟着调整。
坦白讲，如果还在每天花8小时刷LeetCode而不读任何开源项目，你的准备策略已经跑偏了。算法题可以作为思维训练，但不应该成为面试准备的唯一重心。真正的区别是：算法题是封闭问题，有标准答案；代码理解是开放问题，考察的是判断力和工程品味。
这不是终点，而是工程师职业能力的重新定义——从「写出正确答案」到「理解复杂系统」。
对于候选人来说，下一步很具体：找一个代码质量较好的开源项目，花一周时间通读核心模块，尝试写出它的架构说明文档。这比再做十道LeetCode Hard更接近真实工作的能力要求。
参考文献
- Google's New Code Comprehension Interview Round: www.finalroundai.com/blog/google…
- Yuchen Jin on X: x.com/Yuchenj_UW/…
- Yuchen Jin on LeetCode and AI: x.com/Yuchenj_UW/…
- Google-Style Code Comprehension Interviews: medium.com/@weissmann.…
- Yuchen Jin on LinkedIn: www.linkedin.com/posts/itama…
- Google-Style Code Comprehension Interviews: medium.com/@weissmann.…
- Yuchen Jin on LeetCode and AI: x.com/Yuchenj_UW/…
- Yuchen Jin on Claude Code Computer Use: x.com/Yuchenj_UW/…
延伸入口
- 原文归档：tobemagic.github.io/ai-magician…
- 公众号：计算机魔术师
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
In May 2026, a candidate entered the Google interview room and was given more than 60 minutes to read the file code — sitting next to an AI assistant who could call Gemini at any time.
I. An interview to keep the LeetCode silent
What's Google look like?
Google launched a pilot in May 2026 to replace traditional coding interview sessions with Code Comprehens, for L3 and L4 software engineers, covering parts of the United States team.
The interview took 60 minutes and the candidate was given an unfamiliar multi-file code warehouse in CoderPad, probably in C++, Java or Go. The title does not provide algorithms, it does not require handwritten dident tree reverses, but it requires three things to be done: finding the bug in the code, proposing improvements and designing the interviewer ' s discussion structure.
Allows call to Gemini. This means that candidates can ask AI, "Why does this function throw out this anomaly?", "Where are the performance bottlenecks of this code?" instead of being asked to write the best solution by memory.
Agent ran past Load
Google's logic is straightforward: in a real engineering landscape, developers are understanding other people's codes for most of their time, not from zero-invented algorithms. Interviews should reflect this reality.
Databricks Engineer Yuchen Jin publicly questioned the LeetCode mode on X platform. His core argument is simple: LeetCode primarily looks at memory, and even a small model of 3B parameters in the AI era can solve these questions faster than humans. Enterprises continue to use this model for screening people and are looking at skills that are no longer valuable.
Even worse, he cites Google's own rejection of Homebrew author Max Howell: "You 90% of your engineers are using my software, but you don't reverse the fork tree, so get lost."
The irony is full. AI The interview was not a bump, it was an industry recognition of the expiration of the algorithm interview.
Candidatures: 60 minutes against multiword file warehouse
Candidates shared experiences. The multi-file repository is about 10,000 lines in size and involves configuration, tool functions, business logic modules. The task is not to write new codes, but to read, locate and propose improvements.
Time pressure is high. Code reading, problem positioning, programme design, and discussions with interviewers are to be completed within 60 minutes. Gemini can help explain the code, but the core competencies of the candidates can be demonstrated by the ability to quickly create code maps, to judge priorities and to articulate problems.
One of the candidates described it as: "I used to paint LeetCode, the goal was to write the best. Now you have to read someone else's bad code, find out what's wrong, and use AI to back up guesses.
This is essentially a reconstruction of engineering capacity. It's not about writing codes, it's about reading codes, asking questions and using tools.
Code Comprehension Interview Process
Behind this change is AI changing the way it works. When AI can help you write codes, check files, explain logic, the focus of interviews naturally shifts from "can write" to "can judge".
ii. Why is Yuchen Jin shelling LeetCode?
In the AI era, rereading algorithms has become a sin.
Yuchen Jin sent a number of messages on platform X: “AI will be the first to be attacked in the programming area because the code output can be validated by unit testing - but not necessarily in a good place”.
There are two sides to that. The first level is a factual judgement: programming is the only area where the output can be automatically validated by the machine. The code that's written doesn't run. We'll find out. The second level is about value judgements: it's one thing to write "right" and it's another to write "good". The latter would not require algorithmic memory, but the ability to understand existing codes.
How far can we go with a rereading algorithm?
The nature of the LeetCode brush is pattern matching. The fork tree runs through, slides windows, dynamic planning - there is a fixed set of paths for each issue. In the past, the screening mechanism had guaranteed at least the basic algorithms of the candidates, but in an age when AI had been able to decipher the topics, the site had to be re-calibrated.
The 3B Model Test for Engineer Databricks.
The practical tests by Yuchen Jin provided a reference point for quantization. He asked an open source model with only 3B parameters to paint the typical theme of LeetCode, which showed that the model was stable in many medium-cost algorithms. This means that an ordinary engineer was proud of "I brushed 50 LeetCodes a week" in an interview, and that there was no distinction in front of AI.
More importantly, Jin mentioned a classic case in another tweet: Google rejected the application of the engineer of Homebrew's founder, Max Howell, on the grounds that "you can't write a fork tree back on the whiteboard." This tweet was later quoted extensively because it revealed the absurd fact that a developer who created a tool used by 90 per cent of engineers would be eliminated because of a basic algorithm.
When the 3B model solves the problem before you brush the button, the interviewer will only look at whether you can read the shit mountain written by others. This is not an exaggeration, but rather the design logic of Google ' s new interview cycle.
iii. What the hell is the Code Comprehension of Google doing?
From "writing the answers" to "read the code."
Google piloted a Corde Comprehension round in May 2026 to examine the candidate ' s understanding capacity in the multi-document code warehouse. Candidates faced an unfamiliar code library in CoderPad, tasked with identifying bugs, proposing improvements, discussing design decisions — and using Gemini AI as a complement.
Code reading is more patient than writing code.
The central shift in this design is to assess the shift in focus. The traditional code interview was about "can we write the correct algorithm," and the Code Comprehension was about "can we understand a code that already exists?" The latter is closer to the reality of day-to-day work. Engineers were never presented with a blank document, but rather an established system that required reading, understanding and improvement.
Technical interviews within Databricks are also evolving in a similar direction. On the basis of open recruitment feedback, an increasing number of teams have begun to include code reading and defective location links in interviews as an alternative to pure algorithms. This is not a trend unique to Google, but rather a reactive adjustment across the industry in the context of AI capacity enhancement.
The real battlefield in the multi-file warehouse.
The difficulty of Code Comprehension is not a single function, but a cross-file dependency. Candidates need to understand the transfer chain between modules, data flow, and unusual processing logic. This is what engineers spend every day in real projects — reading codes, understanding context, judging the impact of changes.
When Jin discussed this point on LinkedIn, there was another key addition: "The code that AI can write is a well-structured code, but the actual code library is the product of numerous relays." This means that future interviews will not look at what you can write, but what you can understand."
Read the code is the core ability of an engineer.
The direct impact of this shift on candidates is a change in the way they are prepared. The value of rereading algorithm templates is declining, and the ability to read open-source projects, participate in code evaluation, and understand large code libraries is increasing. This is why some of the teams that are preparing new interview formats are beginning to emphasize "code taste" rather than "problem speed".
iv. Interviews have changed, the way they are prepared.
Is LeetCode worth anything?
It's wrong to say LeetCode has no value. It remains valid in terms of basic algorithm thinking and the ability to deal with border conditions. The problem is that when AI is able to accomplish these tasks, the focus of the interviewer ' s mission must shift.
More precisely, the value of LeetCode lies in the rigour of the training thinking, but the core of the interview should be to assess engineering judgement. The two are not in conflict, but have different weights. For junior engineers, the algorithm base remains a concern; for jobs that require independent responsibility, code understanding is more important.
Possible recommendations under the new interview model
In the face of new forms of interview such as Code Comprehension, candidates can try to prepare for:
- Finding a medium-sized open source project to read the code structure of its core modules.
- Practice finding potential bugs and boundary case in code.
- Attempt to describe the design intent and data flow of a code in natural languages.
- Understanding how common design models are reflected in actual code libraries.
I'd rather read the code.
More importantly, candidates need to redefine the "ready" standard. It's not "how many questions have been brushed," it's "the ability to quickly locate key logic in a strange code library." This is the real state of day-to-day work of engineers and the ability of new interview models to filter.
V. THE BORDER OF THE CHANGE
The algorithm won't disappear overnight.
Code Comprehension is the trend but not the only criterion. Many teams continue to use a mix of algorithmic and code-reading topics for reasons such as ease of scalability, higher subjectivity of code-reading questions and different focus on competencies.
Jin's criticism is directed at the extreme practice of "sifting engineers only with algorithms". The industry will not completely cancel the algorithm interview, but the weight is being redistributed. Companies that insist on the sole selection criteria of LeetCode may face a brain drain in the future — not because the company is not good enough, but because it is closer to the way real jobs are assessed.
Joint selection of interviewers and candidates
The ultimate beneficiaries of this change are those who truly love engineering. Algorithms are only entry thresholds, and code understanding and engineering judgement are long-term competitiveness. When interviews no longer take place to look at rereading skills, but rather at understanding skills, the candidate ' s preparation will naturally be adjusted.
Frankly, if it still takes eight hours a day to brush LeetCode without reading any open source projects, your preparedness strategy is already off course. Algorithms could serve as thought training, but should not be the sole focus of interview preparation. The real difference is that the algorithm is a closed question with a standard answer; the code is understood as an open question, looking at judgement and engineering taste.
This is not the end point, but a redefinition of engineers' professional capabilities — from writing the right answer to understanding the complex system.
For candidates, next step is specific: to find an open source project with better code quality, to spend a week reading the core module and trying to write its framework description document. This is closer to real work than the ability to do 10 more LeetCode Hard.
References
- Google's New Code Comprehension Interview Round: www.finalroundai.com/blog/google…
- Yuchen Jin on X: x.com/Yuchenj_UW/…
- Yuchen Jin on LeetCode and AI: x.com/Yuchenj_UW/…
- Google-Style Code Comprehension Interviews: medium.com/@weissmann.…
- Yuchen Jin on LinkedIn: www.linkedin.com/posts/itama…
- Google-Style Code Comprehension Interviews: medium.com/@weissmann.…
- Yuchen Jin on LeetCode and AI: x.com/Yuchenj_UW/…
- Yuchen Jin on Claude Code Computer Use: x.com/Yuchenj_UW/…
Extension entrance
- Original archive: tobemagic.github.io/ai-magician...
- WeChat Official Account: Computer magician
Auto-fetched and translated by AI Atlas. All rights belong to the original author.