Title: 技术面试已死？AI 时代，真正拉开程序员差距的是什么？ Author: 易师傅 Tags: 前端, 后端, 程序员

前言

大家好，我是易师傅，在 AI 时代，也要坚持古法手搓文章。

回想一下，你是否对刷算法题、背框架原理、手写代码、技师（机试）代码这样的场景历历在目？曾经这些都是程序员求职绕不开的一道关卡！！！

但最近，Anthropic 招聘经理 Felix Rieseberg 做了一个决定：不再使用传统编程面试。

原文：Hunger beats tenure: Advice for junior engineers

一、为什么传统手写/技师（机试）代码面试已死？

原因很简单：

过去的技术面试，现场必不可少的会有一道 前端/后端的手写、技师代码相关的题目 ，虽然这个不能完整代表一个人的能力，但多多少少能看出候选人如何拆解问题、组织代码，可以粗略预测他进入团队后的工作能力了。

但是现在嘛，AI 来了，这样的编程任务显然已经没那么重要了，所以继续考同样的内容，其实也是越来越难预测一个人进入团队后的真实表现。

毕竟，一个工程师可以让 AI 阅读项目、修改多个文件、补测试用例、分析报错等，甚至根据一句需求搭出能运行的原型。过去需要几天完成的东西，现在可能几个小时就有第一版。

当然这也并不意味着程序员以后不用懂代码，也不代表所有公司的技术面试会立刻消失。真正发生变化的是：

当“把代码写出来”越来越简单且廉价，公司的领导们更多的是关心你能不能找到问题&idea，并把它解决&落实。

原文用一句话概括：

Hunger beats tenure.（机译：饥饿胜过任期）

个译：主动性与执行力，比工作年限更重要！！！

二、新人的劣势是什么？优势又是什么？

你是否还记得，刚进一家新公司时，你在这家新公司能有多少的资源和影响力？答案显而易见，那几乎约等于“无”。

毕竟你还不了解公司复杂的组织关系，也很难只凭一个想法，让产品、设计和领导们为你投入更多的资源和时间。

所以新人的劣势就很明显了：缺少话语权

老人嘛，摸鱼等下班呗！

---

在很多公司里，大部分都有所谓的历史包袱等较难完成事情：

• 这个系统太复杂，改不了；
• 那个功能老板不会同意；
• 这套流程以前试过，别再折腾；
• 用户已经习惯了，没必要调整；
• 以前的产品就是这样干的。

这些原因随便拎出来一个是不是就能说服你？

但是你不试试又怎么能知道不行呢？？？

如果你一直持有固有成见，不知不觉的你也会从敢于质疑的新人，变成劝别人别折腾的老人。

所以，新人的价值不只是便宜、执行快，而是能看到老员工的那些习以为常，并问一句：

为什么一定要这样？现在还能不能换一种做法？

所以新人的优势就很明显了：

那就是脑海中的那些天马行空的想法，且敢为天下先的勇气！

三、AI 真正改变的，是什么？

打过工的同学，应该都知道一个普通工程师有了产品想法，往往要先写对应的方案、排优先级、向上级争取资源，再协调产品和设计等等。这样的成本其实是很高的，你是老板你也背不住吧！？

所以往往只能让少数人（your leader）来决定哪些想法值得执行。

好了，现在 AI 把差价打下来了！！！

如果你有了新想法，你不一定要先说服所有人。可以先花点时间，把最关键的核心功能做成能点击、能运行、能说明价值的 1.0.0-Alpha 高保真的原型。

要不然真等到你去说服你领导们的时候，你连个像样的计划都没有，那怎么可行！【毕竟人家老板拉投资也要先出一个BP(商业计划书)，不是吗？】

有了这个版本，你领导看到的不只是你的一个建议，也会看到的是你的执行力，觉得提出建议的人也是有能力继续推进的。

So：

AI 真正改变了让年轻工程师们第一次有机会用较低成本去跨过 没有资历，所以拿不到资源；没有资源，所以证明不了自己 的循环。

四、应届/新工程师可以怎么做？

1）别老是盯着你的需求，学会先理解业务目标

工程师不是为了实现某个 PRD 或多写几行代码而存在的。先弄清楚公司、部门和团队真正想解决什么：

• 是提高付费转化？
• 是降低用户流失？
• 是减少客服和运营成本？
• 还是让内部团队更快交付？

有个很重要点就是站在产品的角度去思考业务，与产品“共创”。

如果你不知道从哪开始，可以看看你上级的上级的OKR是什么。毕竟需求可能会变，但业务目标通常很稳定。

2）选择一个有明显影响的想法

翻译成人话：你做的要让你领导看得见

不要只想“这里能不能再加一个按钮”，而要问：

如果加了，能不能明显提高团队实现目标的概率？

想法可以大胆，但需要和业务目标相连。咱们不是为了展示技术，而是为了提升你的价值。

3）先做一个能跑的原型

用 AI 把最核心的初始版本做出来，不要一开始就追求完整产品。

例如，你想改善客服效率，第一版可以只证明：把用户问题、订单信息和知识库答案放在一个页面里，能不能减少来回切换。

先验证价值，再讨论完整架构、权限系统和长期维护。

原型不是正式产品，但它能帮助团队判断是否值得继续投入。

4）先干好一个想法

这是最容易踩的坑。

新员工常常想证明自己，恨不得在一个原型里塞进新前端语言、新后端语言、新移动端语言、智能推荐和一整套的设计系统。最后，可能一个好想法被十几个不成熟的功能埋没掉，别人看完反而不知道重点是什么。

一个好原型只需要回答一个问题：

这个机会值不值得继续做？

范围越小，核心价值越容易被看见，也越容易在几天内做完。

5）利用自己不熟悉的阶段

如果做的是用户产品，新人往往更接近外部用户的真实感受。老员工每天都在系统里工作，已经习惯很多特殊逻辑，很难再感受到第一次使用时的困惑。

记住：先把问题问出来，再用原型验证。

五、作品重要还是刷题重要？

以前，我想大家大多沉浸在刷题的乐趣中，但是时代变了，家人们。

在未来，我们应该学会如何去判断一个人是否善于和 AI 一起工作。

作品中应该有的特征：

• Taste（鉴赏力）：知道什么值得做，也知道什么不该塞进去；
• Empathy（共情力）：能站在用户角度发现真实摩擦；
• Execution（执行力）：能把想法推进成一个可以体验的结果。
• Principled thinking（原则性思维）：做选择时有依据，不是让 AI 随机生成；

所以以后你的作品里最有说服力的，可能不再是“熟悉 20 个框架”或者“刷了 500 道算法题”，而是：

1. 你发现了什么问题；
2. 为什么觉得它值得解决；
3. 你用 AI 和代码做出了什么；
4. 你如何验证它有效；
5. 你做了哪些取舍，还有什么没有解决。

一个范围边界、逻辑清晰、真正解决问题的小作品，可能比一套功能堆满但说不清价值的大项目更能证明能力。

六、编码能力你不能丢

“传统技术面试已死”很容易被解读成“以后不用学基础，也不用会写代码”。显然不是这样的，也不是你领导想要的！

AI 可以降低实现成本，却不会自动替你完成这些判断：

• 需求是不是解决了真实问题；
• 生成的代码是否安全、可靠、可维护；
• 数据和权限边界有没有漏洞；
• 原型验证了什么，又没有验证什么；
• 一个方案能不能进入现有系统长期运行。

不会判断代码质量的人，很难知道 AI 写得对不对；不了解系统的人，也很难把原型变成稳定产品。

所以：

过去更看重你能不能亲手把答案写出来；以后更看重你能不能定义问题、调动工具、检查结果，并对最终影响负责。

七、给正在迷茫的工程师的想法

如果你正在找工作，或者担心 AI 会替代你的岗位，可以先做这几件事：

• 选一个你真实遇到过的问题，而不是照着教程再做一遍商城；
• 先查清楚用户是谁、问题为什么值得解决；
• 用 AI 在两三天内做出最小原型；
• 只保留一个最重要的价值点；
• 找几个人真实试用，记录他们在哪里卡住；
• 根据反馈改一轮，而不是只换配色和动画；
• 在 README 或作品介绍里写清问题、取舍、验证和局限；
• 保留关键提示词、设计过程和提交记录，证明你如何与 AI 协作。

不需要等到作品足够宏大才发布。一个能把问题讲明白、让别人愿意试用的小工具，就已经比“我会使用 AI”更有说服力。

总结

这篇文章真正想说的，不是“技术面试已死”，也不是“新人从此可以轻松超过老员工”。

它指出的是一个更重要的变化：主动性与执行力，比你的经验更重要！！！

过去，年轻的工程师即使看到问题，也可能因为没有资源、没有话语权，只能继续完成别人拆好的任务。现在，AI 让个人有机会用更低的成本把想法变成原型，用结果争取讨论，而不是先用资历争取许可。

当 AI 工具迅速抹平一部分基础编码速度的差距后，真正拉开距离的，可能会变成：

• 谁更早看到问题；
• 谁更理解业务与用户；
• 谁能把范围收得足够小；
• 谁能快速做出东西；
• 谁愿意对结果继续负责。

所以，与其只担心 AI 会不会抢走你的工作，不如换个问题：

当实现不再是最难的部分，我能不能找到一个值得实现的东西？

或许，这可能才是 AI 时代，工程师最该练习的新能力？