Anthropic 工程经理宣告「编程面试已死」，程序员靠什么证明自己？

刷题、手撕代码、白板编程......曾经是程序员求职面试必经环节。

但 AI 越来越会写代码，这套面试方式还管用吗？

近日，Anthropic 工程经理 Felix Rieseberg 认为「编程面试已死」，并分享了他对年轻工程师的建议。

当写代码不再是稀缺能力，程序员又该靠什么证明自己？

这大哥靠谱，他不仅提出了问题，也提出了建议，还都是可以实操的。

以下是他的原文，你可以说Anthropic的员工脑子可能跟常人不一样，但是每个人的思考深度和广度都相当到位。

《渴望胜过资历：给初级工程师的建议》

Hunger Beats Tenure: Advice for Junior Engineers 

作者：Felix Rieseberg，Anthropic 工程经理，曾负责 Claude.ai、Cowork 和 Claude Code Desktop 的工程团队，之前曾在 Notion、Stripe、Slack 和 Microsoft 工作。

原文：Hunger Beats Tenure

原文发布于 2026 年 10 月 27 日。开篇所说的面试变化，是作者作为招聘经理的实践；阅读时不宜扩大成 Anthropic 全公司的统一政策。

这篇建议值得带着自己的工作或者需求读，比如说有没有一件，你每天都觉得麻烦，却一直凑合着做？比如反复查同一批文档、把散落的反馈归到一起。先找出谁在这件事上花时间，再考虑 AI 能帮上哪一段。

如果一时想不到合适的场景，可以先看看别人把大模型用在了什么地方。

带着这个小问题，再看 Felix 的经历。他接下来会讲，新人为什么有时反而能看见团队习以为常的问题。

以下是全文中文翻译，尽量保留作者的表达方式与语气。

第一部分

传统编程面试的终结

这个月，我正式宣告传统编程面试的结束。

作为 Anthropic 的招聘经理，我已经不再要求候选人参加这类测试。

这种面试方式曾经发挥过作用：能否迅速定义问题并找到优雅的解决方案，虽然只是一个较弱的指标，但仍然有助于预测一个人在我的团队中能否取得成功。通过真实代码中的小型编程挑战，我们确实能够了解到候选人的一些重要能力。

但现在，这种判断已经不再成立。

让候选人完成一道简单的 React 编程题，已经和考察他们的汇编语言知识一样，没有太大意义。因为 Claude 现在在这两个方面都比候选人做得更好。

我们团队中那些创造了最大影响力的工程师，无论他们在这些测试中表现如何，都能够取得成功。

尽管编程面试无处不在，但它从来都不受欢迎。

我猜，经验丰富的工程师对于它的消失仍然会有强烈反应——哪怕只是因为这件事揭示了我们的职业正在发生怎样的变化。

已经有大量文章讨论 AI 如何给初级开发者带来挑战，尤其是那些正在寻找工作的人。

但在观察了一段时间初级工程师如何使用 AI 之后，我反而形成了一个更加乐观的看法：

一个人能够创造多大影响力，越来越不取决于他花了多少年积累各种框架和软件库的知识。

我正在看到一些入行不久的工程师，迅速超越那些编程能力可能更强、从业时间也长得多的人。

渴望胜过资历。（Hunger beats tenure.）

这篇文章是我能给初级工程师的最好建议。

不过，「初级」这个词其实并不准确。

这篇文章真正想写给的，是那些还没有积累社会资本、地位或权力的工程师。

第二部分

有眼光，却没有话语权

首先，你需要同时认识到自己的优势和劣势。

人们一直认为，新鲜的视角——即使有些天真——也具有强大的力量。

当我加入 Stripe 时，创始人 Patrick Collison 曾强烈建议我们这些新员工，特别留意那些让自己觉得奇怪的事情。

他的判断是：新人能够发现那些老员工早已习以为常、不再注意的摩擦点和机会。

1991 年，组织理论学者 James March 曾写道，组织需要「持续引入天真且无知的人」。

当奥逊·威尔斯（Orson Welles）被问及，他为什么有信心尝试那些前人从未尝试过的镜头时，他回答：

「无知，纯粹的无知。你知道，没有什么自信能够与之相比。我想，只有当你真正了解某个职业之后，你才会开始变得胆怯或谨慎。」

当我加入 Notion 时，其中一场面试要求我设计一套离线模式的系统架构。

当时我非常困惑，因为面试官告诉我，这是一道「陷阱题」：他们认为离线模式根本不可能实现。

原因有两个。

首先，Notion 的数据模型过于复杂，无法轻松地同步整个工作空间。

其次，如果只允许用户下载单个页面，那么这种用户体验是 CEO Ivan Zhao 绝对不会接受的。

后来事实证明，数据模型确实非常复杂。

但创始人反对离线模式这件事，却并不是真的。

大家都把它当成常识，以至于根本没有人去核实。

而我作为一个什么都不懂的新人，并不知道自己「不应该」去问这个问题。

所以我直接问了。

读到这样的故事，很容易觉得故事里的人做出了愚蠢的决定。

但我必须强调：当你自己身处其中时，发现这类错误有多么困难，几乎无法形容。

加入 Notion 不久后，我曾想给各个团队配备大型电视屏幕，用来展示实时数据看板。

但我遇到了组织内部的阻力，最终失败了。

而且我也没有强烈到愿意为此大动干戈。

一年后，一位名叫 Ji Pei 的新员工加入了公司。

他提出了完全相同的想法。

我当时甚至有点不屑，告诉他不要浪费时间，因为我早就试过了。

但他已经去问过了。

第二天，电视屏幕就安装好了。

在那一年里的某个时刻，我已经从新人变成了那个因循守旧的老员工。

不过，这种来自「无知」的力量有一个问题：

没有人关心你的想法。

大多数科技公司都存在多层中层管理结构，负责把更宏观的商业目标转化为具体的执行任务。

从组织结构上看，公司往往围绕着这样一种机制运作：少数人负责批准或否决各种想法。

在执行成本高昂的世界里，你通常必须花费很长时间积累一定的社会地位，整个组织才愿意在你的想法上「下注」。

而组织架构的变化往往极其缓慢。

因此，即使是那些相信 AI 的公司，也经常只是希望初级员工利用 AI 更快地完成分配给他们的任务，而不是主动追求更有雄心的商业目标。

但现在有个好消息：

执行已经不再昂贵。

第三部分 

你应该怎么做？

1. 优先考虑商业影响，而不是待办任务

早在 AI 编程出现之前的 2011 年，Patrick McKenzie 就曾写道：

「企业雇用工程师，是为了创造商业价值，而不是为了让他们编写程序。」

他建议工程师主动靠近公司真正创造收入的业务领域。

你应该从这里开始。

首先，理解你的公司究竟想实现什么目标。

如果你所在的是一家大型企业，那就先理解你所在团队或部门的目标。

然后，找到合适的思考层级。

一个通常很有用的方法是：尝试理解你上司的上司正在追求什么目标。

2. 选择一个具有颠覆性的想法

提出几个想法。

这些想法一旦成功，就应该能够显著提高组织实现其目标的可能性。

要有雄心！

3. 利用一个周末把它做出来

我已经看到，一些小团队甚至单个工程师，直接跳过了传统的产品开发流程。

他们不再先花大量时间编写产品需求文档（PRD）、争取各方支持，或者游说设计师和产品经理分配时间。

他们直接做出了一个能够运行的原型。

4. 专注于一个真正好的想法

根据我的经验，初级工程师经常犯的一个错误，是试图把多个想法塞进同一个原型里。

结果，三个极其优秀的想法，被埋没在另外二十个糟糕的想法之中。

如果你的原型需要同时创造一种新的编程语言、开发一个后端系统，还莫名其妙地涉及移动应用，那么你大概率不会成功。

开发一个可运行原型的真正目的，是把一个想法表达得足够清楚，让管理层迅速理解其中的机会，并且意识到你就是那个有能力推动它落地的人。

5. 充分利用你的新鲜视角

如果你正在开发面向用户的产品，那么你拥有一种独特的优势：

你能够更自然地站在用户的角度思考，因此更容易判断产品究竟好不好用。

我在 Slack 和 Notion 的同事们，常常很难真正理解，一个外部用户使用 Slack 或 Notion 时是什么体验。

如果你从事的是基础设施或开发工具工作，那么你的优势则在于：

你从来没有学过那些告诉你「这件事不可能实现」的理由。

读到这里，可以把「一个周末做出来」理解成一次范围很小的尝试。比如同事经常找不到某份文档，第一版先用几份可公开使用的材料，做到输入一个问题、返回相关段落和出处。挑几道真实问题试一试，找不到时也要能说明，而不是为了演示好看随便编一个答案。

这样的原型已经能拿给别人试用：结果有没有帮助，哪里还需要手动查。接入更多数据、做账号系统，都可以等这个问题得到验证以后再考虑。

第四部分

未来一片光明

我不认为传统的编程面试还会回来。

当然，人们很容易对此产生怀旧情绪。

毕竟，曾经有那么多人购买《算法与数据结构》相关书籍，希望借此找到一份好工作、获得更好的未来。

而编程面试的消亡，也标志着软件工程正在进入一个更高的抽象层次。

与此同时，作为一个长期反对按照资历决定晋升的人，我无法不对未来感到乐观。

我已经亲眼看到不少受欢迎的应用和产品，通过这种新方式诞生。

在 Anthropic，大家已经习惯了把 Claude Code 当作命令行界面（CLI）来使用。

以至于最终需要两位入职时间相对较短的工程师——Anthony Morris 和 Alice Zhao——站出来，在一个周末内快速做出一个能够运行的图形界面原型。

大约八天后，第一个公开版本就发布了。

你大概不会感到意外：一个好用的 Claude Code 图形界面，最终成为了非常受欢迎的产品。

我想，我应该不是唯一一个正在思考如何面试那些善于利用 AI 创造产品的工程师的管理者。

我自己还没有完全找到答案。

但现在，当我浏览候选人的简历和作品集时，我会特别留意那些小型原型项目。

它们应该能够体现出一个人的：

• 品味（Taste）：判断什么值得做、什么才是好的能力。

• 同理心（Empathy）：理解用户真实需求的能力。

• 原则性思考（Principled Thinking）：基于清晰原则进行判断和决策的能力。

如果你已经找到更好的方法，我非常愿意听听你的想法。

知友讨论

@Index：

「聊天已死」、「前端已死」、「后端已死」、「程序员已死」、「翻译已死」、「UI 已死」、「汇编已死」……「程序员没有严冬了；因为 2026 是最后一个冬天」

@舟公：

想法到落地的过程越来越容易了，所以可实现的想法越来越重要了

@VETC：

面试：你的创意，用codex、claude 复刻 需要多久才能被抄完？

@小牛拉大策：

但是现在有一个很矛盾的问题：

如果一个初级开发者具备全栈开发一个软件产品的经验，他清楚的知道这个产品的目标用户、产品解决的痛点，亲自设计软件系统框架和功能运行逻辑，但是因为他完全依赖AI来进行代码编写，甚至没有怎么看过代码，不清楚其中具体的技术实现。这样一位应聘者是否符合现在很多科技公司的招人需求呢？

阅读更多