解读一下这篇博客，重点讲述里面对于初级工程师的一些建议，你也可以拓展着讲讲https://felixrieseberg.com/hunger-beats-tenure-advice-for-junior-engineers/

回复 群友 3131 作者 Felix Rieseberg 是 Anthropic 的 hiring manager。他开篇第一件事就是宣布：他自己停掉了传统 coding interview。理由很直接：让你写个 React 小 demo 已经跟考汇编差不多，Claude 两样都比人强；而在他看来，真正带来高影响力的 builder，做题好坏与他们的产出高低关系不大。 所以全文的主命题是标题那句：hunger 胜过 tenure。资历是你积累了多少年框架和库知识，而影响力现在不那么受这个约束了。他特别说了一句，“junior” 这个词其实不对，这篇真正写给的是缺 social capital、缺 status、缺权力的人。 文章前半在讲新人的优势和劣势，这部分我觉得是最值得琢磨的： 一是 fresh eyes 是真的有价值，前提是你肯问。他举了三个例子。Stripe 的 Patrick Collison 新员工入职就让他们盯着“哪里让你觉得不对劲”的；James March 1991 年那句组织要靠“不断涌入的天真者”来保持活力；Orson Welles 被问哪来胆子拍没人拍过的镜头，说“无知，纯粹的无知，没什么自信比得上它”。最关键的是他在 Notion 面试时设计离线模式，被人提醒这是道“陷阱题”，因为大家普遍认为离线不可能——数据模型复杂是真的，但“创始人绝不接受下载单页”这条阻力其实没人去核过，只是当常识传了下来。他这个不知情的新人一张嘴问，就发现那条常识是假的。 二是这个优势会自己消失。他入职 Notion 一年后想给团队挂大屏显示实时看板，撞了墙、失败了、也没坚持。一年后新人 Ji Pei 提同一个想法，他劝人家算了，我已经试过了。结果 Ji Pei 早就问过了，第二天电视就来了。他写这句很扎心：“在那一年里的某个地方，我变成了那个老家伙。”所以新人的窗口期是有时限的，等你自己也把“不可能”当成常识，你就没这个能力了。 三是劣势：没人在乎你怎么想。公司结构本来就是围绕少数人能放行或否决想法来搭的，执行成本高的时候你必须先熬出社会资本，组织才愿意“押注”你。而 org chart 改得极慢，所以很多公司嘴上信 AI，实际还是指望新人把手头的活干快一点，而不是去追业务目标。 然后文章给的转折是：好消息，执行已经不贵了。这是他所有建议的共同前提，没有这个前提，下面五条一条都做不成。 具体五条建议： 一，抓业务影响，不抓 backlog。他引 2011 年 Patrick McKenzie 的话：工程师是被雇来创造商业价值的，不是被雇来写程序的。你要先搞清公司、至少你所在部门在追求什么；找 altitude 有个实用技巧，去看你 manager 的 manager 定了什么目标。 二，选一个激进的想法。不是改进 10%，是想清楚如果成了，能显著提高组织达成那些目标的概率。 三，一个周末把它做出来。他强调这是绕开 PRD、要 buy-in、排队等设计师和 PM 的捷径：一个能跑的原型比一叠文档说话快。 四，只做一个好想法。这是新人最常见的坑，把一堆想法塞进一个原型，三个好东西被埋进二十个坏东西里；如果你那个原型还要顺带发明一门新语言、一个后端、再来套移动端，肯定成不了。原型的目的是让 leadership 一眼看懂机会，并且看懂你是能把它跑下去的那个人。 五，用足新鲜视角。做用户面向的东西，你对用户有独特的同理心，Slack 和 Notion 的人其实是很难理解外部用户真实体验的；做基础设施和工具，你的好处是你没被灌输过所有“这事不可能”的理由。 结尾他给了个很硬的例子：Anthropic 内部把 Claude Code 当 CLI 用惯了，是两个相对新的工程师 Anthony Morris 和 群友 6718 Zhao 用周末做出 GUI 原型，第一个公开版本大约八天后就发了——就是现在很受欢迎的那个图形界面。他还坦白自己也没完全想好怎么面 AI 时代的人，现在是在简历和 portfolio 里翻那些小而美、能看出 taste、同理心和原则性思考的原型。 我想往下再延伸几层，对在国内这些环境里的初级工程师可能更有用： 先说不成立的地方。这套建议的前提是“你可以直接拿周末去搞一个没人批准的东西”，这在有些团队是加分，在有些团队是越界。特别是动到线上数据、客户流程、合规领域的原型，先做的代价可能是事故而不是机会。所以第一周该做的不是写代码，是搞清楚你们组织里“能自己动手的边界”在哪，还有谁能给你的东西做背书。这不是怂，是把整个策略的风险控制住。 再说“业务影响”这一条，很多人理解成“去做离钱近的需求”，其实作者的意思更偏“搞清楚目标是什么”。具体动作可以是：把你 manager 的 manager 的季度目标原文找出来，逐条对上你手上的活，看哪些活根本挂不上——那些就是可以砍的。这个动作本身在两周内就能做完，而且做完你会发现自己有谈判材料了。 关于原型，有个技术细节他一带而过但很关键：原型的成功标准是“被看懂”，不是“能上线”。所以要做到能演、能点、数据可以是假的、边界情况可以是断的，但主线故事必须 30 秒内讲清。反面是那种花了三个月、工程极其优雅、但演示的时候要人解释半天的东西——那不是原型，那是你偷偷做了一个项目。 还有一层他没明说，但我觉得对 AI 时代的初级工程师是核心：你做原型的杠杆其实在 Agent 上。以前一个周末能做出可演示的东西，得靠你自己手速；现在真正稀缺的是“知道该做什么”的判断和“把判断翻译成验收标准”的能力。所以初级工程师该练的不是更快地写，而是更快地把一个模糊想法收敛成可验证的最小版本，然后能判断 agent 给的东西对不对。这也是他说的那些招人标准——taste、同理心、原则性思考——其实是这三件事的名字。 最后一点现实的：他这套是“高信任、低流程”组织的玩法。如果你所在的地方 PRD 流程很重、晋升靠 tenure，那五个步骤要改造着用——原型照样做，但先把原型当成“说服你直属 manager 的材料”，而不是直接往 leadership 那里打。找一个人当你的放大器，比一个人硬冲有效得多。 一句话总结：这篇真正在说的事，是执行成本塌了之后，“有没有想法、敢不敢问、能不能一个周末把它变成能演的东西”变成了新的分水岭，而这个优势会因为你自己变得“懂事”而消失。