面试

最近我们团队在招人，主要是 new grad，或者有两年左右经验的工程师。面试方式还是很传统：聊背景，然后做 LeetCode。

每次进入 phone screen，给 candidate 出一道 LeetCode 题，我都会有一种很滑稽的感觉。通过的人，很可能只是把题背了下来，或者在某个环节里借助了 AI 工具；而这个过程，我实际上没有什么可靠的办法验证。没通过的人，也不一定是能力不够。也许只是因为 ta 没背到这道题，也许是因为紧张，也许只是因为不敢作弊，或者内心更诚实。

这让我很不安。

我当然希望给团队招到合适的人。尤其是对于 entry level 的 candidate，我并不觉得专业知识本身有那么重要。一个刚毕业、或者刚工作一两年的人，会不会某个 framework，会不会某个 API，真的不是核心问题。性格、学习能力、沟通能力、合作方式、面对未知问题时的反应，这些东西才更决定 ta 能不能在团队里 survive，甚至闪耀。

所以我能做的，就是尽量多花一些时间聊背景、聊项目、聊知识结构、聊 ta 做选择时的倾向。但问题是，如果 LeetCode 没做出来，我还是很难写下一份有力的 interview report，去支撑 ta 进入下一轮。

很多人把面试看作一场考试。我觉得这是典型的做题家思想。面试应该是一个双向评估的过程：公司在评估 candidate 是否适合，candidate 也在评估这家公司、这个团队是否适合自己。面试没过，不说明一个人低人一等，只说明双方不 match。这不是鸡汤，也不是安慰，而是客观事实。

想象一下，如果一个面试环节就让你感到很不安，让你觉得这里是一个兄弟会式的环境，你真的希望在这里工作吗？

我当然理解，有更多 offer、更多选择，人就会更心安，也能拿来做 competing offer。但这些都是 strategy，不是面试这件事真正应该回答的问题。

我自己内心中的面试准则只有一个：如果 ta 是你的同事，你是否愿意和 ta 一起在一个项目上合作？

你当然可以说这很主观，甚至有点独断。但是如果我是为我的团队、我的组面试，这个人未来就是我除了家庭之外交流最多的人之一，我必须选择一个符合我主观标准的人。因此，每个团队，甚至每个面试官的面试都可能不同。因为没有任何团队是完全一样的，也没有两个人会有完全一样的喜好和倾向。

我倾向于聪明、开放的人。

聪明这点，我主要看一个能力：抽象。

能够透彻理解概念，剥离概念上各种附加的、无意义的内容，从而看到本质，这就是抽象能力。有抽象能力的人经常会遇到一种情况：ta 觉得某些东西非常类似，而其他人完全看不出来。这不是玄学，这就是抽象能力的差距。

抽象能力强的人，脑子里像是有一张概念地图。ta 们未必能像很多人一样快速”理解”某个新概念，因为如果无法把某个东西拆解、抽象、归位，ta 们就很难把它吸收进自己的知识体系。但一旦真正理解了，使用起来就会游刃有余，而且可以很自然地举一反三。

开放则决定了一个人的合作能力和探索能力。

封闭的人只能在规定范围内执行任务。更可怕的是，ta 们也不喜欢别人跳出范围。“业界都这么做，肯定有他们的理由。“这句话一旦成为思考的终点，创意也就结束了。如果这句话永远是对的，那人类世界就不会有任何创新：我们不需要蒸汽机，只需要马；我们不需要高级编程语言，只需要继续给纸带打孔。

开放的人足够自信，同时脑中也会保留一个问题：如果我是错的，会怎么样？

我很喜欢一句常被引用的话：一流智力的标志，是能够同时在头脑中持有两个相反的观点，并且仍然保持行动能力。无论这句话该如何精确归因，我喜欢的是这个意思：真正开放的人，不是没有立场，而是知道自己的立场可能错。

AI 改变了什么

AI 时代的到来，改变了软件行业的很多事情。

过去这个行业进来了很多人。虽然大家的 title 都是软件工程师，但每个人对自己的定位并不一样。有些人只是把自己看成一个把需求转化成代码的工具；有些人则是怀着用软件让世界变得更好的热情来到这个行业。

我一直很讨厌中文语境里把软件工程师叫做”码农”。这个词用久了，很多人真的会以为我们做的事情就是写代码，就是打字。实际上，写代码从来都不是软件工程里最难的部分。《人月神话》给我的一个重要启发是：软件项目真正困难的地方，往往不是怎么把代码敲出来，而是那些因为人、模块、概念、沟通和边界而产生的复杂度。

如何做合适的数据建模，如何用清晰的控制流表达业务流程，如何处理边界场景，如何在不确定的需求里做判断，这些才是软件工程师真正的工作。我们首先是工程师，其次才是软件工程师。

有了 AI 生成代码，一夜之间，仿佛”码农”就变得完全不值钱了。我觉得这句话很刺耳，但也不是完全没有道理。纯粹把自己定位成”把需求翻译成代码”的人，确实会越来越没有议价能力。

但很多鼓吹”工程师不重要了”的人，并不理解软件工程的难点究竟在哪里。

确实，我们不再需要死记硬背大量语法和 API contract。AI 可以帮我们补全代码，查文档，生成样板，甚至给出一个还不错的初版实现。但这并不意味着工作变少了。相反，很多原本隐藏在实现细节里的判断，被更快地推到了我们面前。

AI 可以辅助建模，但它无法替你承担建模错误的后果。AI 可以生成架构建议，但它不知道你们团队三个月后会不会被这个抽象拖死。AI 可以根据 prompt 满足需求，但它不会天然知道这个需求本身是不是应该被拒绝。

哪怕是 vibe coding，对普通人来说也有不小的门槛。你可以去观察一下非软件技术背景的人如何使用 AI：很多时候，他们不是不会提需求，而是不知道应该如何切问题，不知道什么叫可验证，不知道怎么判断一个结果是”看起来能跑”还是”真的可以维护”。AI 生成产品这件事，和普通人之间仍然有很大的 gap。

所以我的判断是：纯粹意义上的”码农”会被淘汰，而真正的软件工程师会变成更全能的职业。

这个职业不再那么强调你记住了多少细枝末节，而是更强调你是否理解业务，明白产品，知道如何吸引用户，并且对美学、交互和系统复杂度有足够好的判断。

我脑中一直有一个模型：从用户需求到实际实现是一条光谱。最左边是模糊的用户痛点和需求，最右边是落到实处的代码。运营、PM、Engineering Manager、IC 都在这条光谱上的不同位置，分别覆盖其中的一部分。

这个模型有三个重点：

1. 如果光谱上有任何一段没人覆盖，产品就会出问题。
2. 只有光谱有重叠的人，沟通才是有效的。
3. 一个人能覆盖的光谱越大，ta 对产品就越重要。

AI 的出现，与其说是直接覆盖了光谱中的一大段，不如说是变成了光谱里的空缺填充者。它可以填充最靠近实现的部分，也可以填充用户沟通、交互设计、文档整理、原型生成之类的部分。

当你试图让 AI 覆盖一大片光谱时，它会出错，也可能失控。但即便如此，它仍然比多找一个人来得便宜，也来得快。PM 可以 vibe coding，engineer 可以 vibe design，产品落地的人力成本大幅下降。个人开发者比任何时候都更容易完成一个项目，一个不会写代码的产品经理也可以做出一个 proof of concept。

这件事非常大。

新的混乱

在这个基础之上，软件行业正在为一个愿景做尝试：如果有一天，人完全不需要直接写代码，而是通过自然语言描述来完成”编程”工作，会怎么样？

想象一个 4-6 人的团队，通过 AI 每个月交付 10-20 个功能。这是一个非常诱人的数字。背后有巨大的商业利益，所以先行者已经开始尝试。vibe、spec、plan mode、harness，一个个名词轮番上场。大厂逼着自己的员工烧 token，试图用这种养蛊的方式烧出一个明星。

在这种 FOMO 环境下，各种 AI 使用乱象也开始出现：大量垃圾代码和屎山涌现，开源项目被 AI 生成的 PR 淹没，准备上线的代码由 AI 生成、AI review、AI 测试，最后在没人真正负责的情况下进入生产环境。

这不是 AI 的问题，而是人的问题。

我看到过一个讨论：如果你的团队里有人不负责任地使用 AI，不 review，不 care，产出大量屎山，你会怎么办？有人说，炒掉 ta。

这当然是一个办法。如果你 care，如果你不想让屎山增加到不可维护，你可以让这个人离开团队。但你不能永远靠招人、炒人解决问题。团队经验没法积累，团队会陷入动荡，招聘也非常花钱。这显然不是长久之计。

真正的长久之计，是找到一种合适的方式，评估一个人是否适合在 AI 时代负责任地用好 AI 这个工具。

而这又回到了最开始的问题：我们到底应该招什么样的人？

范式还没有稳定

AI 生成代码的能力，以及它的不稳定性，让软件行业突然进入了一个范式还没有稳定的阶段。

这个阶段有点像软件工程早期的那些年代。结构化编程、Unix 哲学、面向对象、敏捷开发、TDD，这些今天看起来很自然的东西，并不是从一开始就是共识。它们是在很多年的实践、争论、失败和修正里慢慢形成的。

今天我们习以为常的许多原则，比如抽象、模块化、避免无节制的 goto、用测试保护行为、用小工具组合复杂系统，都曾经是被提出、被质疑、被争论的观点。软件行业不是一开始就知道应该如何开发软件。它是在混乱里长出来的。

过去 10-20 年，软件行业享受了一个稳定红利：在行业没有巨变的情况下，基本盘快速发展。很多人只需要以工人的心态进入这个行业，就可以享受很高的待遇。按流程做事，按 ticket 写代码，按既有范式解决问题，这在过去相当长的时间里是有效的。

但随着 AI 打破过去的开发方式，循规蹈矩的”工人”心态会越来越不适合这个时代。这个时代需要的，不只是执行者，而是先行者。

Ken Thompson、Edsger Dijkstra、Dennis Ritchie、Grace Hopper、Alan Turing，他们当然是巨大的名字。但我这里想说的不是神化这些人，而是强调一种状态：他们都站在当时并不稳定、并不确定的基础上，继续往前探索，提出新的想法，构造新的工具，甚至改变人们理解计算的方式。

有些先行者有机会在历史上留下名字，也有很多失败的先行者没有留下名字。但推动他们往前走的，至少不只是钱，也不只是更好的生活。很大一部分动力，是强烈的求知欲，是对未知系统的好奇，是想知道”如果这样做会怎么样”。

我觉得，在我们的时代，最需要的也是这样的素质。

软件 3.0 的团队，要招的应该是这样的先行者。因为我们正在，也需要开发新的范式。

先行者的素质

先行者有什么样的素质？

第一，知其然，也知其所以然。

对事物的理解不能流于表面。不理解本质，就无法举一反三，也无法融会贯通。对一个问题有透彻的理解，并且能横向、纵向地迁移，是一条很典型的创新路径。只有对事物的内部结构和前提条件有持续的好奇，才能真正把这种能力发挥出来。

第二，学习范式，也反思范式。

循规蹈矩本身不是问题。学习已有范式没有什么不好意思的。问题在于，只知道”应该这么做”，却不知道”为什么这么做”。

一个范式本质上是某种经验的压缩。真正有价值的不是”这个范式永远正确”，而是：“在某些条件下，这个范式是最佳选择。“只是这些条件在过去太普遍了，以至于大家会默认它永远成立。

先行者会对前置条件的变化敏感。当条件变化时，原本正确的范式可能开始失效。能看到这一点的人，才有机会开辟新的道路。

第三，有广泛而强烈的求知欲。

跨领域的融合往往最容易出现创新。今天的 AI 领域里有大量生物、数学、物理、认知科学背景的人；软件行业里也一直不缺理论物理、控制论、语言学和设计背景的人。跨领域创新的关键，不是简单地把两个名词放在一起，而是对不同系统的结构进行抽象、解构和映射。

这需要好奇心。不是表演出来的好奇心，而是真的想知道。

总结

如果你读到这里，是在等我提出一个新的面试方式，那可能要失望了。因为我暂时也没有答案。

但我很确定的是：现在的面试方式，没办法帮我们找出这样的人才。

LeetCode 可以筛掉一部分完全不写代码的人，也可以筛出一部分熟练的做题者。但它很难判断一个人是否有抽象能力，是否开放，是否能在不确定中学习，是否会负责任地使用 AI，是否能在范式变化的时候继续往前走。

而在 AI 时代，有更多这样人才的地方，注定会比其他地方更容易做出事情。

我也希望现在正在这个行业拼搏，或者讨生活的人，不要感到恐惧。我不是想安慰任何人，也不是想说什么鸡汤。我只是觉得，世界本来就是动态的、不确定的，也永远都需要投入才会有产出。

过去那种稳定的安稳生活，可能本来就不是常态。混乱和不确定，才更接近世界的底色。

如果你感到恐惧，我想说，很多人都会这样。明天又是新的一天。你和所有人一样，都还有机会发现一个改变很多人工作和生活的点子。