“至少在我负责的 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, although not a complete measure of an engineer ' s ability, would somewhat reflect the extent to which candidate definition problems and quick solutions were being sought. However, this correlation is declining with the rapid increase in AI programming capacity.
In Rieseberg, it appears that testing candidates for the React sub-problem has come closer and closer to seeing today whether an engineer can be skilled in hand-written compilations: Claude has performed well enough in these tasks, and the most influential engineer in the team is not necessarily the best in traditional code testing.
The old man is bound by the sub-rule.
Behind this adjustment in recruitment, Rieseberg would like to discuss another issue: how can 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 judgement is optimistic. “Hunger beats experience”, that is, a strong will 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, using AI to quickly exceed their colleagues with better programming base and longer working life. In the past, engineers had needed to accumulate a number of years of framework, library and tool knowledge, which constituted a part of the occupational barrier; AI was now reducing the constraints that such accumulation imposed on the speed of implementation.
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 recalled that when he joined Stripe, Patrick Collison, the founder, reminded the new employees to pay particular attention to the first place that looked strange or unreasonable. The new ones lacked the burden of history and were more likely to discover frictions and opportunities that old employees were used to.
He's been through something like this himself in Notion. During the interview, Rieseberg was asked to design a offline model structure. The interviewer told him that this was in fact a problem of a “trap” nature, as the team generally agreed 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 at that time it was thought that “the founders would not accept” the product limits were not as strong as expected. It has long been considered as a consensus by many, to the extent that very few have asked the matter again. As a newcomer to the company, Rieseberg happens to be unaware of the sub-rule and has chosen to ask again.
Interestingly, a year later, he himself became the old employee who told the new guy not to mess 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 the same time: the understanding of real technological constraints and the organizational inertia that emerged from past failures, which are difficult to distinguish from.
Two new guys made a company explosion on the weekend.
In the past, it has been difficult for new engineers to push organizational action even if they had 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 prefers to give decision-making power to those with more seniority and internal influence.
AI is changing that premise.
Rieseberg's first recommendation to young engineers is to focus on business implications. He quotes Patrick McKenzie in 2011: Engineers are employed to create commercial value, not just programming. Engineers need to know what the company, the business sector and the superiors really want to do before looking for opportunities around these objectives that can significantly improve results.
Next, Rieseberg suggested that young engineers choose a bold enough idea to use a weekend to make a prototype that could run.
In some of the cases that 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 a leader sees a product that can be clicked, operated and experienced, the idea of a new person does not have to rely entirely on the position, seniority and in-house connections for attention.
However, he did not suggest that too many ideas should be inserted into the prototype. Young engineers are easily added to a dozen functions at a time, eventually leading to a few truly valuable ideas being drowned by a large number of secondary functions. A good prototype begins with a communication role, requiring that decision makers quickly understand where the opportunity is and why the person proposing the programme is fit to remain responsible for it.
For user products, new employees have another advantage: they are closer to ordinary users. Rieseberg remembers that, when working at the Slack and Notion, it is often difficult for long-time employees involved in product development to rediscover what it feels like for an outside user to use these products for the first time. If it is responsible for infrastructure and the development of tools, the newcomers also do not carry so much “this thing has been tried before” “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 engineers, Anthony Morris and Alice Zhao, who had a relatively short entry time, developed a working prototype with a graphical interface over a weekend. About eight days later, the first public version was officially 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 demand discussions, PRDs, product design, development resource coordination, etc., and AI allows a small team to complete the product first and then prove demand with finished products.
This change is also why he believes that opportunities for young engineers are increasing. Those without a position or organizational influence had previously had difficulty in getting companies to invest in an untested idea; when an individual could rely on AI to move the idea to an operational stage, the seniority barriers within the organization would be reduced.
Forget about the tradition. What about the new engineer?
So, if traditional code interviews are becoming more and more difficult to measure the capacity of an engineer, what should replace it?
Rieseberg is honest and he has no complete answer. His current practice is to focus on the search for “small prototypes” in his curriculum vitae and his work, focusing on the taste of the products that candidates present in these works, the common sense of the users, and whether he has a clear, structured way of thinking.
This is where Rieseberg's X post publish was questioned. “We all know that, in the AI era, traditional programming interviews have not been able to provide a sufficiently effective judgement signal. The problem is that, in a 60-minute interview, no better alternative indicator has 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 made the Take-home test, and that the new assessment was equally uncertain compared to the traditional code interview. It was also suggested by developers that candidates could be given a code warehouse “AI written with confidence but in fact with errors” to see if candidates could identify 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 have special characteristics 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 use AI to show enough enforcement, 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. Software engineering has been moving up a number of abstract layers, from compilation to advanced languages, from handwritten basic code to call frames and cloud services, and now AI has made part of its programming an abstract layer.
This change has also led to a different way of competing with those who have just entered the industry. The number of years of work continues to mean experience, but the binding between capacity for implementation and the number of years of work is diminishing. A person who understands business objectives, discovers problems that are neglected by the organization ' s inertia, and uses AI to quickly make a product of ideas, may have less and less time to wait to gain influence.
The new recruitment paradigm is not in shape.
Currently, there are few direct cancellations of programming interviews such as Rieseberg, and more so when candidates are allowed to use the AI programming tool.
In January of this year, Tristan Hume, one of the team leaders of the Anthropic Optimistic Performance Optimization, published a dramatic recruitment experience: In order to recruit performance engineers, he designed, starting in 2024, 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 has 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 within four hours; the team had then upgraded the subject to the second edition and reduced the time for testing from four hours to two hours; and a few months later, Opus 4.5 had come back, and it had been able to reach the highest human candidate under the 2-hour limit. Ultimately, the team had to re-design new questions and deliberately add constraints, mini-directions and new puzzles that the model had not seen before.
Hume admits that this new set of tests sacrificed the similarities with real work, as Claude became easier to complete as he approached the subject of real development.
It is noteworthy that the Anthropic network still shows that there are technical jobs that use tools such as Colab and CodeSignal to carry out Live Coding. At the same time, the candidate AI user guide still provides that the Take-home test default does not allow the use of Claude, Live Interview, and the AI support is also defaulted unless otherwise specified.
Open AI is now a hybrid mode. Different teams may arrange 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 a 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 relationships, 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 posts last year, explicitly requiring candidates to use the Copilot, Cursor and Claude AI tools. The team gave the traditional computer fundamentals directly to AI for testing, and the result is AI can give the correct and fully explained answer in seconds. Therefore, continuing to ban AI will only make the way in which interviews and engineers actually work more and more distant.
As a result, Canva changed the problem to more complex, more vague and more like real product development. Candidates need to clarify needs, dismantle tasks, guide AI, check generation codes, and be accountable for final technical programmes.
After a period of testing, Canva found that the best performers usually do not give the whole job to AI. They will take the initiative to control the problem boundary, hand over only 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 good and bad output of AI.
From the data, the change is just beginning.
Karat investigated 400 project leaders in the United States, India and China this year. In the United States, only 38 per cent of enterprises allowed candidates to use AI for on-site technical interviews, and 68 per cent for Chinese enterprises; at the same time, 62 per cent of organizations interviewed still prohibited AI from participating in technical interviews.
The findings of some 650 developers and recruits in CorderPad 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 depend on the circumstances.
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 about the interpretation of technical trade-offs and correctness; only 7 per cent of the recruiters felt 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 Gem Box. All rights belong to the original author.