“至少在我负责的 Anthropic 团队里，编程面试已经死了。我已经看得足够多，可以确定它不再能提供有效的判断信号。这个月，我已经把编程面试从招聘流程中取消了。”Anthropic 工程经理、Electron 联合维护者 Felix Rieseberg 在推特上表示。
Rieseberg 目前在 Anthropic 负责工程管理工作，曾领导 Claude.ai、Cowork 和 Claude Code Desktop 等产品的工程团队，此前先后任职于 Notion、Stripe、Slack 和微软。他作出上述判断的理由是：这类测试已经很难继续提供有效的招聘信号。
他认为，过去一道 React 小题或真实代码中的小型编程挑战，虽然无法完整衡量一名工程师的能力，但多少能够反映候选人定义问题、快速寻找解决方案的水平。但随着 AI 编程能力快速提升，这种相关性正在下降。
在 Rieseberg 看来，用 React 小题测试候选人的意义，已经越来越接近今天考察一名工程师能否熟练手写汇编：Claude 在这些任务上的表现已经足够强，而团队中最具影响力的工程师，也未必是传统代码测试成绩最好的人。
“老人”被“潜规则”束缚了
这次招聘调整背后，Rieseberg 更想讨论另一个问题：当 AI 能够完成越来越多过去需要多年编程经验才能完成的工作，年轻工程师和资深工程师之间的差距会发生什么变化？
他的判断颇为乐观。“Hunger beats tenure”，即强烈的行动意愿可能比资历更重要。
Rieseberg 称，自己已经看到一些进入行业时间并不长的工程师，借助 AI 快速超过编程基础更好、工作年限更长的同行。过去，工程师需要多年积累框架、库和工具知识，这些经验构成了一部分职业壁垒；现在，AI 正在降低这种知识积累对执行速度的限制。
他认为，经验较少的工程师一直拥有一个容易被低估的优势：他们还没有完全接受组织内部关于“什么事情做不了”的默认判断。
Rieseberg 回忆自己加入 Stripe 时，创始人 Patrick Collison 曾提醒新员工，要特别留意那些第一眼看起来奇怪或者不合理的地方。新人缺少历史包袱，反而更容易发现已经被老员工习以为常的摩擦和机会。
他自己在 Notion 也经历过类似事情。面试时，Rieseberg 被要求设计一套离线模式架构。面试官告诉他，这实际上是一道带有“陷阱”性质的问题，因为团队普遍认为 Notion 无法实现离线模式：工作区的数据模型过于复杂，单独下载页面又被认为无法提供足够好的用户体验。
其中关于数据模型复杂度的判断后来被证明是成立的，但当时大家认为“创始人不会接受”的产品限制，并没有想象中那么牢固。很多人长期把它当成共识，以至于已经很少有人重新询问这件事。作为刚加入公司的新人，Rieseberg 恰好不知道这条“潜规则”，因此选择重新问了一遍。
有趣的是，一年后，他自己也成为了那个告诉新人“别折腾了”的老员工。
Rieseberg 曾尝试为团队配置大型电视，在办公室展示实时 Dashboard，但遭遇组织阻力后没有继续推动。一年后，新员工 Ji Pei 提出了同样的想法。Rieseberg 告诉对方自己已经尝试过，不值得继续折腾，然而 Ji Pei 还是去问了，第二天电视就出现在办公室里。
Rieseberg 借这个故事想说明，所谓“经验”很容易同时携带两种东西：对真实技术限制的理解，以及过去失败后形成的组织惯性，两者时间久了很难区分。
两个新人在周末做出了公司爆品
过去，新人工程师即使发现了问题，也很难推动组织行动。一个新想法往往需要写 PRD、争取经理支持、协调产品经理和设计师，再获得工程资源。执行成本越高，组织越倾向于把决策权交给资历更深、拥有更多内部影响力的人。
AI 正在改变这个前提。
Rieseberg 给年轻工程师的第一条建议，是把注意力放到业务影响上。他引用 Patrick McKenzie 在 2011 年的一句话：工程师受雇是为了创造商业价值，而非单纯编程。工程师需要先了解公司、业务部门以及上级真正希望完成什么，再围绕这些目标寻找能够显著改善结果的机会。
接下来，Rieseberg 建议年轻工程师选择一个足够大胆的想法，然后用一个周末做出能够运行的原型。
在他观察到的一些案例里，小团队甚至单个工程师已经可以绕开过去漫长的产品立项流程，直接用 AI 搭建出可工作的 Prototype。当领导能够看到一个可以点击、运行和体验的产品时，一个新人的想法也就无需完全依赖职位、资历和内部人脉获得注意。
不过，他并不建议在原型中塞入太多想法。年轻工程师容易一次加入十几个功能，最终让几个真正有价值的创意被大量次要功能淹没。一个好的原型首先承担沟通作用，需要让决策者迅速理解机会在哪里，以及为什么提出这个方案的人适合继续负责它。
对于用户产品，新员工还拥有另一项优势：他们离普通用户更近。Rieseberg 回忆在 Slack 和 Notion 工作时，长期参与产品开发的员工往往已经很难重新体会一个外部用户第一次使用这些产品是什么感觉。如果负责基础设施和开发工具，新人同样没有背负那么多“这个东西以前试过了”“这里一直不能改”的既有认知。
Rieseberg 还给出了 Anthropic 内部一个相当有代表性的例子。
随着 Claude Code 使用量增加，Anthropic 内部员工逐渐习惯把 Claude Code 当作命令行工具使用。随后，两名入职时间相对较短的工程师 Anthony Morris 和 Alice Zhao，用一个周末做出了一个带图形界面的可工作原型。大约 8 天后，第一个公开版本正式发布。
Rieseberg 提到，Claude Code 的图形界面后来成为相当受欢迎的产品。这类项目在过去可能需要经历需求讨论、PRD、产品设计、开发资源协调等一系列过程，而 AI 让一个规模很小的团队可以先完成产品，再用成品证明需求存在。
这一变化也是他认为年轻工程师机会正在增加的原因。没有职位和组织影响力的人，以前很难让公司为一个未经验证的想法投入资源；当一个人可以依靠 AI 把想法推进到可运行阶段，组织内的资历壁垒会随之降低。
不考传统 Coding 了，新工程师该怎么面？
那么，如果传统代码面试越来越难以衡量工程师能力，应该用什么取代它？
Rieseberg 坦诚，自己目前也没有完整答案。他目前的做法是：会在简历和作品集中寻找“小型原型”，重点观察候选人在这些作品里体现出的产品品味、用户同理心，以及是否拥有清晰、成体系的思考方式。
这也是 Rieseberg 的 X 帖发布后遭到质疑的地方。“我们都知道，在 AI 时代，传统的编程面试已经无法提供足够有效的判断信号。问题在于，一场 60 分钟的面试里，目前还没有找到更好的替代指标。你的文章里我也没有看到这样的答案。”
一名刚参加过 Anthropic 招聘的候选人也提到，自己做的是 Take-home 测试，相比传统代码面试，新的评估方式同样存在不确定性。还有开发者建议，可以给候选人一个“AI 写得很自信但实际上存在错误”的代码仓库，观察候选人能否识别模型错误并坚持自己的判断。
社区也并非都认同“编程面试会被取消”的判断。有开发者认为，Anthropic 这样的 AI 公司具有特殊性，大量传统企业未来多年仍可能继续使用算法和代码测试。也有人指出，当前最大的难点并不是年轻工程师能否借 AI 表现出足够强的执行力，而是他们如何在简历筛选阶段获得展示这种能力的机会。毕竟，现在一些企业越来越不喜欢招聘新人工程师了。
不过，Rieseberg 仍然认为，传统编程面试很难恢复到过去的地位。软件工程已经经历过多次抽象层级上移，从汇编到高级语言，从手写大量基础代码到调用框架和云服务，如今 AI 又把一部分编程实现向上抽象了一层。
对于刚进入行业的工程师，这种变化也带来一种与过去不同的竞争方式。工作年限依然意味着经验，但执行能力与工作年限之间的绑定正在减弱。一个能够理解业务目标、发现被组织惯性忽略的问题，并借助 AI 迅速把想法做成产品的人，获得影响力所需要等待的时间可能会越来越短。
全新招聘范式还未成型
目前，像 Rieseberg 这样直接取消编程面试的还不多，更多是考察候选人被允许使用 AI 编程工具后的表现。
今年 1 月，Anthropic 性能优化团队负责人之一的 Tristan Hume 公开了一段颇有戏剧性的招聘经历：为了招聘性能工程师，他从 2024 年开始设计了一套模拟加速器优化的 Take-home 测试，而且明确允许候选人使用 AI 工具。他们想评估候选人在有 AI 辅助的情况下还能否展现自己的判断力和优化能力。
约 1000 名候选人完成过这套测试，Anthropic 借此招聘了性能工程团队中的大量成员。它对年轻候选人格外有效，一些履历并不突出、刚从本科毕业的工程师，依靠测试中的出色表现获得了 Offer，入职后也证明了自己的能力。
这期间，Claude 逐渐“做穿了”面试题。Claude 3.7 Sonnet 已经达到一个临界点：超过一半候选人如果直接把题目交给 Claude Code 完成，成绩反而会更好；Opus 4 进一步超过了绝大多数人在 4 小时内取得的成绩；团队于是把题目升级到第二版，并把测试时间从 4 小时缩短到 2 小时；几个月后，Opus 4.5 又追了上来，它在 2 小时限制下已经能够达到最强人类候选人的水平。团队最终只好再次设计新题，并刻意加入模型此前没有见过的约束、迷你指令集和新型谜题。
Hume 自己承认，这套新测试牺牲了原来与真实工作的相似度，因为越接近真实开发工作的题目，Claude 越容易完成。
值得注意的是，Anthropic 官网目前仍显示，有技术岗位会使用 Colab、CodeSignal 等工具进行 Live Coding。同时，候选人 AI 使用指南仍规定：Take-home 测试默认不能使用 Claude，Live Interview 同样默认不允许 AI 辅助，除非另有说明。
OpenAI 现在也是“混合”模式。不同团队可能安排 Pair Coding、Take-home 或技术测试；部分面试允许 AI，部分面试专门观察候选人在没有 AI 帮助情况下的独立解决能力。OpenAI 明确表示，他们关心的不只是最终答案，还包括候选人如何分析问题、做决定以及解释自己的思考。
国内也已经出现类似实践。月之暗面从事研发并负责开发者关系的唐飞虎此前接受 InfoQ 采访时提到，自己做面试官时不会阻止候选人使用 AI，会设计必须通过人机协作才能完成的任务，并故意留下问题，观察候选人能否理解发生了什么、识别模型错误并调整方向。
Canva 走得更远。Canva 去年重新设计 Backend、Frontend 和机器学习岗位的技术面试，明确要求候选人使用 Copilot、Cursor、Claude 等 AI 工具。团队此前把传统计算机基础题直接交给 AI 测试，结果 AI 几秒钟就能给出正确且带有完整解释的答案。因此，继续禁止 AI，只会让面试和工程师实际工作的方式越来越远。
于是，Canva 把问题改得更复杂、更模糊，也更像真实产品开发。候选人需要澄清需求、拆解任务、指导 AI、检查生成代码、Debug，并对最终技术方案负责。
测试一段时间后，Canva 发现，表现最好的人通常不会把整个任务交给 AI。他们会主动控制问题边界，只把合适的子任务交给模型，持续审查 AI 生成的代码，并在模型犯错时迅速接管。AI 经验少的候选人遇到的困难，很多也不在写代码本身，而在于缺少判断 AI 输出好坏的能力。
从数据看，这场变化刚刚开始。
Karat 今年调查了美国、印度和中国的 400 名工程负责人。美国只有 38%的企业允许候选人在现场技术面试中使用 AI，中国企业达到 68%；同时，62%的受访组织仍然禁止 AI 参与技术面试。
CoderPad 今年约 650 名开发者和招聘人员的调查结果类似：34%的组织完全禁止 AI，46%允许或在一定约束下允许，另有 20%看情况决定。
有意思的是，当 AI 被允许以后，企业开始寻找完全不同的招聘要求：66%的招聘方最看重候选人能否发现和修复 AI 错误；56%关心能否解释技术取舍和正确性；只有 7%的招聘人员认为异步技术测试最能反映实际工作能力，技术讨论和 Live Coding 得到的认可明显更高。
原文链接：
https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/
https://x.com/felixrieseberg/status/2115200995546566910
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
"At least in my Anthropic team, the programming interview is dead. I have seen enough to make sure that it no longer provides an effective signal of judgement. This month, I cancelled the programming interview from the recruitment process.” Anthropic Engineering Manager and Electron Joint Maintainer Felix Rieseberg tweets:
Rieseberg is currently in charge of engineering management in Anthropic and has led engineering teams for products such as Claude.ai, Cowork and Claude Code Desktop, which previously served in Notion, Stripe, Slack and Microsoft. The reason for his judgement is that it is already difficult for such tests to continue to provide effective recruitment signals.
In his view, a small programming challenge in a React sub-issue or real code in the past, while not a complete measure of an engineer ' s ability, reflected somewhat the degree to which candidates defined problems and sought solutions quickly. But with the rapid increase in AI programming capacity, this correlation is declining.
In Rieseberg, it seems that testing candidates for the React sub-issue has become closer to today’s examination of an engineer’s skills in hand-written compilation: Claude has performed well enough on these tasks, and the most influential engineer in the team is not necessarily the best in traditional code testing.
"Older" is bound by the "submarine rule."
Behind this adjustment in recruitment, Rieseberg would like to discuss another issue: how will the gap between young and senior engineers change when AI is able to do more and more work that has taken years of programming experience in the past?
His judgment is optimistic. “Hunger beats experience”, i.e. a strong willingness to act may be more important than seniority.
Rieseberg states that it has seen a number of engineers who have not been in the industry for a long time and have quickly exceeded their colleagues with better programming base and longer working lives through AI. In the past, engineers needed to accumulate knowledge of frameworks, databases and tools over the years, which constituted a part of the occupational barrier; AI was now reducing the constraints on the pace of implementation of such knowledge accumulation.
In his view, less experienced engineers had always had an advantage that could easily be underestimated: they had not yet fully accepted the tacit judgement within the organization that “what could not be done”.
Rieseberg remembers that when he joined Stripe, Patrick Collison, the founder, reminded the new employees to pay special attention to what seemed strange or unreasonable at first sight. The newers lack the burden of history and are more likely to discover frictions and opportunities that old employees have become accustomed to.
He's been through something like that himself in Notion. During the interview, Rieseberg was asked to design a model architecture for offline. The interviewer told him that this was in fact a problem of a “trap” character because the team generally believed that Notion could not achieve the offline model: the data model in the work area was too complex and the downloading of a single page was considered not to provide a sufficiently good user experience.
The judgement on the complexity of the data model was subsequently proven to be valid, but it was not as strong as expected at the time that “founders would not accept” product restrictions. Many people have long considered it as a consensus, to the extent that very few have asked the matter again. As a newcomer to the company, Rieseberg happened to be unaware of the sub-rule, so he chose to ask again.
Interestingly, a year later, he himself became the old employee who told the new guy, "Don't fuck up."
Rieseberg tried to set up a large television for the team, displaying real-time Dashboard in the office, but did not continue after organizational resistance. A year later, the new employee, Ji Pei, made the same idea. Rieseberg told the other party that it had tried and that it was not worth it, yet Ji Pei went and showed up in the office the next day.
Rieseberg uses this story to illustrate that it is easy for so-called “experiences” to carry two things at once: the understanding of real technological constraints and the organizational inertia that has developed as a result of past failures.
Two newcomers made company explosives on weekends.
In the past, it was difficult for new engineers to push organizational action even if they discovered problems. A new idea often requires a PRD, manager support, coordination of product managers and designers, and access to engineering resources. The higher the cost of implementation, the more the organization tends to give decision-making power to those with more seniority and internal influence.
AI is changing this premise.
Rieseberg's first recommendation to young engineers is to focus on business implications. He quotes Patrick McKenzie, who said in 2011 that engineers were hired to create commercial value rather than simply programming. Engineers need to know what companies, business departments and superiors really want to do before looking for opportunities around these goals that can significantly improve outcomes.
Next, Rieseberg suggested that young engineers choose a bold enough idea to make a prototype that could run over a weekend.
In some of the cases he observed, small teams and even individual engineers had been able to bypass the long product-setting process of the past and build a working Prototype directly using AI. When leaders are able to see a product that can be clicked, operated and experienced, the idea of a new person does not have to rely entirely on jobs, qualifications and internal connections for attention.
He did not, however, suggest inserting too many ideas into the prototype. Young engineers are easily added to a dozen functions at a time, which eventually leads to several truly valuable ideas being drowned by a large number of secondary functions. A good prototype begins with a communication role that requires that decision makers quickly understand where the opportunity is and why the proponents of the programme are fit to remain responsible for it.
For user products, new employees have another advantage: they are closer to ordinary users. Rieseberg recalls that when working in Slack and Notion, it is often difficult for employees who have been involved in product development for a long time to rediscover what it feels like to be used for the first time by an outside user. If it is responsible for infrastructure and the development of tools, it is equally true that the newcomers are not burdened with “this thing has tried before” and “there has been no change”.
Rieseberg also gave a fairly representative example from within Anthropic.
With the increase in the use of Claude Code, anthropic internal staff became accustomed to using Claude Code as a command line tool. Subsequently, two relatively short-term engineers, Anthony Morris and Alice Zhao, developed a working prototype with a graphical interface over a weekend. About eight days later, the first official version of publish.
Rieseberg mentioned that Claude Code's graphical interface later became a very popular product. Such projects may need to go through a series of processes in the past, such as needs discussions, PRDs, product design, development resource coordination, etc., and AI allows a small team to complete the product and then prove demand with finished products.
This change is also the reason why he believes that opportunities for young engineers are increasing. Those without a position or organizational influence have previously had difficulty in getting companies to invest in an untested idea; when an individual can rely on AI to move the idea to an operational stage, the seniority barriers within the organization will decrease.
Forget the tradition. What about the new engineer?
So, if traditional code interviews are becoming increasingly difficult to measure, what should replace engineers?
Rieseberg, frankly, has no complete answer. His current practice is to focus on the search for “small prototypes” in his curriculum vitae and work, focusing on the taste of the products that candidates present in these works, the common sense of the users, and whether there is a clear and systematic way of thinking.
This is also where the X post publish of Rieseberg was questioned. “We all know that, in the AI era, traditional programming interviews have not been able to provide sufficient judgement signals. The problem is that in a 60-minute interview, no better alternative indicators have been found. I don't see that in your article either."
A candidate who had just been recruited for Anthropic also mentioned that he had conducted the Take-home test and that there was also uncertainty about the new assessment approach compared to traditional code interviews. It was also suggested by developers that candidates could be given a code warehouse “AI written with confidence but in fact wrong” to see whether candidates could recognize the error of the model and maintain their judgement.
Not all communities agree that “programming interviews will be cancelled”. According to developers, AI companies such as Anthropic are unique and a large number of traditional enterprises may continue to use algorithms and code tests for years to come. It was also pointed out that the greatest difficulty at the moment was not whether young engineers could demonstrate sufficient enforcement power through AI, but how they could be given the opportunity to demonstrate that capacity during the curriculum vitae screening phase. After all, there is a growing reluctance on the part of some enterprises to recruit new engineers.
However, Rieseberg continues to believe that traditional programming interviews are difficult to restore to their former status. The software project has undergone many abstract shifts, from compilation to advanced languages, from handwritten basic codes to call frames and cloud services, and now AI has made part of its programming an abstract layer.
This change also leads to a different way of competing with those who have just entered the industry. While the number of years of work continues to mean experience, the binding between capacity for implementation and the number of years of work is diminishing. A person who understands the business objectives, discovers that he or she has been neglected by the organization ' s inertia, and uses AI to quickly make his or her ideas a product, may have less and less time to wait to gain influence.
The new recruitment paradigm is not in shape yet.
At present, few direct cancellations of programming interviews, such as that of Rieseberg, have taken place, more so after the candidates have been allowed to use the AI programming tool.
In January of this year, Tristan Hume, one of the team leaders of the Anthropic Optimizing Performance, released a dramatic recruitment experience: In order to recruit performance engineers, he designed, from 2024 onwards, an optimised Take-home simulation accelerator test and explicitly allowed candidates to use the AI tool. They want to assess whether candidates, supported by AI, can also demonstrate their judgement and ability to optimize.
About 1,000 candidates completed the test, and Anthropic recruited a large number of members of the performance engineering team. It has been particularly effective for young candidates, some of whose curricula vitae are not prominent and who have recently graduated from undergraduate studies, and who have acquired Offer on the basis of the outstanding performance of the tests, and who have proved their ability on the job.
During this period, Claude gradually “doed it through” interviews. Claude 3.7 Sonet has reached a critical point: more than half of the candidates would have been better off if they had submitted the subject directly to Claude Code; Opus 4 had gone further than the vast majority of people had achieved in four hours; the team then upgraded the subject to the second edition and reduced the test period from four hours to two hours; and a few months later, Opus 4.5 came back and it was already able to reach the highest level of human candidate under the 2-hour limit. The team eventually had to re-design new questions and deliberately add constraints, mini-directions and new puzzles that the model had not previously seen.
Hume herself admits that this new set of tests sacrificed a similarity to real work, as Claude became easier to complete as he approached the topic of real development.
It is noteworthy that the Anthropic network still shows that there are technical jobs using tools such as Colab, CodeSignal, and so on. At the same time, the guidelines for the use of candidate AI still stipulate that the default for the Take-home test does not allow the use of Claude, Live Interview, and also the default does not allow AI support unless otherwise specified.
Open AI is now also a hybrid mode. Different teams may arrange for Pair Coding, Take-home or technical tests; some interviews allow AI and some interviews are dedicated to observing the independent resolution of candidates without AI assistance. Open AI made it clear that they were concerned not only with the final answer, but also with how candidates analysed questions, made decisions and explained their thinking.
Similar practices have emerged at the national level. In his previous interview with InfoQ, Tang, who was engaged in research and development on the dark side of the moon and was responsible for the development of the relationship, mentioned that he would not prevent candidates from using AI when he was an interviewer, would design tasks that had to be carried out with human collaboration, and would deliberately leave a question as to whether candidates could understand what was going on, identify a mismodel and reorient.
Canva went further. Canva re-engineered the technical interviews for Backend, Frontend and Machine Learning jobs last year, explicitly requesting candidates to use the Copilot, Cursor, Claude and other AI tools. The team previously referred the traditional computer fundamentals directly to AI for testing, and the result is AI can give the correct and fully explained answer in a few seconds. Therefore, continuing to ban AI will only make the way interviews and engineers actually work increasingly distant.
As a result, Canva changed the problem to more complex, more ambiguous, more like real product development. Candidates need to clarify needs, dismantle tasks, direct AI, check generation codes, and be responsible for the final technical programme.
After a period of testing, Canva found that the best performers usually do not give the whole mission to AI. They take the initiative to control the problem boundary, hand over the right subtask to the model, review the codes generated by AI on an ongoing basis and take over quickly if the model is wrong. AI encounters difficulties for less experienced candidates, many of which do not write the code itself, but rather lack the ability to judge the quality of AI output.
In terms of data, the change is just beginning.
Karat investigated 400 engineering directors in the United States, India and China this year. Only 38 per cent of enterprises in the United States allowed candidates to use AI for on-site technical interviews, and 68 per cent of Chinese enterprises; at the same time, 62 per cent of organizations interviewed still prohibited AI from participating in technical interviews.
The findings of the CoderPad about 650 developers and recruiters this year are similar: 34 per cent of the organizations are completely banned from AI, 46 per cent are permitted or subject to certain constraints, and 20 per cent are on a case-by-case basis.
Interestingly, when AI was allowed, the enterprise began to look for completely different recruitment requirements: Sixty-six per cent of the recruiters placed the highest priority on the ability of candidates to detect and repair AI errors; 56 per cent were concerned with the interpretation of technical trade-offs and correctness; only 7 per cent of the recruiters considered that the different-step technical tests best reflected actual ability to work, and technical discussions and Live Coding received significantly higher recognition.
Original link:
https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/
https://x.com/felixrieseberg/status/2115200995546566910
Auto-fetched and translated by AI Atlas. All rights belong to the original author.