本月，我正式取消了传统的代码面试环节。作为 Anthropic 的招聘经理，我不再要求候选人参与此类测试。过去，这种面试虽预测力有限，但能考察候选人快速定义问题及寻找优雅方案的能力，对判断团队适配度仍有参考价值。小型编程挑战确实能揭示候选人的某些特质。
然而，这一逻辑已不再成立。如今，让候选人完成简单的 React 任务，与考察汇编语言知识一样毫无意义——Claude 在这两方面均已超越人类。那些最具影响力的工程师，无论在此类测试中表现如何，都能取得成功。
尽管代码面试无处不在，却从未真正受欢迎。资深工程师对其消失的反应，折射出职业角色的演变。大量讨论聚焦于 AI 对初级开发者求职的挑战，但在观察初级员工使用 AI 一段时间后，我看到了更积极的一面：影响力不再仅仅取决于积累框架和库知识的年限。
“无知”的优势与话语权困境
首先，需认清自身的优势与劣势。
新鲜甚至天真的视角，长期以来被视为一种力量。加入 Stripe 时，创始人 Patrick Collison 恳请新员工密切关注那些令团队感到奇怪的事物。他的逻辑是，新人能发现老员工早已习以为常的摩擦点和机会。
1991年，James March 指出，组织依赖于“保持无知者和外行人的涌入”。Orson Welles 也曾表示，信心往往源于“纯粹的无知”，因为了解专业领域后，人容易变得胆怯或谨慎。
在 Notion 的一次面试中，我被要求设计离线模式架构。这被视为一种“陷阱”面试，因为当时认为离线模式是不可能的：数据模型过于复杂，无法轻松同步整个工作区，而下载单个页面的体验又是 CEO Ivan Zhao 绝不会允许的。事实证明，数据模型的复杂性确实存在，但创始人的阻力并不存在。人们因视其为常识而未去核实，而我这个“无知”的初学者也未直接提问。
这类轶事容易让人看到他人的决策失误，但发现自己犯错同样困难。加入 Notion 不久，我想为团队配备大屏幕电视以显示实时仪表板，却撞上组织壁垒，最终因缺乏精力斗争而失败。一年后，新员工 Ji Pei 提出同样想法。我嗤之以鼻，劝他别白费力气，因为他已经问过了。第二天，电视就出现了。在那一年里，我变成了那个“老员工”。
“无知”力量的局限在于：没人关心你的想法。科技公司通常层层设卡，将业务目标转化为执行指令。结构上，公司围绕少数人批准或阻止想法的理念构建。在执行成本高昂的世界里，你需要磨练出一定的社会地位，组织才会“押注”你的想法。组织架构变化缓慢，即便相信 AI 的公司，也通常期望初级人员更快执行任务，而非雄心勃勃地追求业务目标。
好消息是：执行不再昂贵。
行动指南
1. 选择业务影响而非待办事项
2011年，Patrick McKenzie 写道：“工程师被雇佣是为了创造商业价值，而不是为了编写代码。”建议将自己与公司赚钱的部分联系起来。首先了解公司（或部门）的实际目标，然后找到合适的切入点——理解你经理的经理所关注的目标，通常是一个有用的代理指标。
2. 选择一个激进的想法
提出几个若能成功将显著提高组织实现目标机会的想法。要有野心！
3. 周末构建原型
小团队和独立工程师已通过构建可工作的原型，绕过了撰写产品需求文档 (PRD)、获得认可以及与设计师或产品经理协商时间的常规流程。
4. 专注于一个好想法
初级人员常犯的错误是将多个想法塞进一个原型，在 20 个糟糕的想法中隐藏三个优秀的想法。如果原型涉及创建新的编程语言、后端及移动应用，很难成功。构建可工作原型的目的是清晰传达一个想法，让领导层快速理解机遇，并意识到你是能驾驭它的人。
5. 利用你的新鲜视角
若从事面向用户的工作，你对用户拥有独特的同理心，能更好感知产品的优劣。Slack 和 Notion 的同事很难内化作为外部用户使用这些产品的体验。若从事基础设施或工具开发，你受益于从未学过所有被视为“不可能”的理由。
未来充满希望
我认为代码面试不会回归。鉴于许多人购买《算法与数据结构》以期解锁好工作，代码面试的死亡标志着软件工程达到新的抽象层次，产生怀旧情绪在所难免。
作为一名长期反对按资历晋升的人，我感到乐观。我已经看到了不少通过这种方式制作出来的热门应用和产品。
在 Anthropic，人们已习惯将 Claude Code 用作命令行界面 (CLI)。两名相对较新的工程师 Anthony Morris 和 Alice Zhao 在一个周末内搭建出了一个可工作的原型，第一个公开版本约八天后上线。毫不令人惊讶的是，Claude Code 的良好图形界面是一个非常受欢迎的产品。
我可能不是唯一一个正在思考如何面试善于利用 AI 构建产品的候选人的经理。我尚未完全做到——但我正在简历和作品集中寻找展现品味、同理心和原则性思维的小原型。如果你找到了更好的方法，我很乐意听听。