AI 时代,Coding 面试到底该测什么

当代码越来越容易生成，真正稀缺的是判断力、协作力和对结果负责的能力。

如果你准备过Coding面试，你就一定听过对 LeetCode 的吐槽。它与日常工作几乎毫不相干，但对大公司来说，标准化比测得准重要。

日常工作的真正挑战是什么呢？作为新人入职，接手一个完全陌生的代码库，从过期文档和同事口述中拼凑出零散的信息，然后 debug，发 PR，迭代，部署。如果你不做地图开发，你的职业生涯可能永远不需要从零实现一个 Coding 面试中的 Dijkstra 算法。当 Coding 面试的考察内容与现实脱节，而这样的题目还能被 AI 一秒解答时，我们也许都在被迫重新审视，这块别扭地杵在候选人和岗位间的凹凸镜，是否在妨碍我们双方看清彼此。

以前这块凹凸镜还能用。它不准，但便宜、标准、难作弊，也勉强能看出一点计算机基础。

AI 出现以后，这个平衡被打破了。当一道标准题可以被模型几秒 one-shot，面试就容易变成两件事：要么大家开始斗智斗勇，看谁能防住谁用 AI；要么我们一起假装工程师上班是不碰 AI 的。DoorDash 把后一种状态叫 performance theater，我觉得很准确。

AI 没有毁掉一个好测试。它只是让我们看见，这个测试本来就没那么好。

超过 90% 的美国工程师每天都在用 AI Coding 工具，差不多四分之三的人过去半年里交付过 AI 生成的生产代码（HackerRank、CoderPad 今年最新数据）。这些数字不一定需要被神化，但方向已经很清楚：真实工作正在变成人和AI 一起完成的事。

如果工作已经变了，面试还停在“关掉所有工具，一个人写出标准答案”，那它测的就是一个正在消失的岗位。

我现在更关心的不是候选人会不会用 AI。这个问题太浅了。更重要的问题是，他能不能对 AI 产出的东西负责。

他能不能借助 AI 做出原本做不出来的东西？能不能在 AI 给出一个看起来很对的答案时，知道哪里该信，哪里必须自己验证？能不能在模型跑偏时把它拉回来？

这些问题，比“你会不会用 AI”重要得多。

对我来说，AI 像一台有两个旋钮的放大器。它不会凭空给你判断力，但会把你已有的判断力放大。一个本来就会拆问题的人，会用 AI 拆得更快；一个本来就不验证的人，也会更快地把错误代码交出去。

第一个旋钮，是扩大能力边界，让你开始做原本做不了的事。第二个旋钮，是放大已有能力，让你把本来就会做的事做得更快、更大。

我在大厂做研究时，主要工作是设计实验和写论文。开始创业后，我以前几乎没碰过后端代码，却在 AI 的帮助下，一个月内设计并实现了产品的前后端架构。这是第一个旋钮。它把我的能力边界往外推了一圈。

但另一些事情刚好相反。实验设计、假设验证、结果分析，这些原本就是我熟悉的工作。AI 出现后，它们没有消失，只是变成了开发间隙里可以并行推进的背景程序：瞥一眼屏幕，敲几下键盘，确认方向没跑偏。这是第二个旋钮。它放大的不是我的知识边界，而是我已有能力的产出效率。

这两个旋钮并不是彼此独立的。它们会互相影响。我经常和团队里一位工程师讨论模型评估，能明显感觉到他对模型的理解正在以很快的速度加深。很多我当年需要在学校里一点点学的东西，他现在可以借助 AI 边做边学，直接在真实问题里建立直觉。一开始，AI 是在帮他探路，扩大他的能力边界。但用不了多久，这些新理解会变成他的基本功。到那时，AI 放大的就不只是他的边界，而是他的效率。能力就是这样被一圈一圈推开的。

但这也意味着，放大器开得越大，人本身越重要。我们常常讨论，AI-native 人才到底应该怎么定义。比起了解多少 AI 工具和名词，一个 AI-native 的人更了解自己。他知道哪些任务自己有足够经验，可以放心让 AI 加速；也知道哪些任务自己还在学习，必须慢下来，和 AI 一起探索、验证、校准判断。毕竟，不论如何用 AI 放大工作，最终为结果负责的，依旧是我们自身。

面试应该看这些地方。

面试本来就该是一段真实工作的样本。这不是新观点。组织心理学几十年前就有结论，工作样本测试（work sample）是预测效度最高的选拔方法之一。让人做一段真实的项目，通常比让人解谜题更能预测他将来在岗位上的表现。过去的问题是，这件事太贵。让候选人做一个真实项目，可能要几天；面试官看完也要很久。大家最后退回到一套更容易规模化的东西：标准题、标准答案、标准评分。

AI 把这个前提推翻了。一个 scope 清晰的问题，候选人用自己的 IDE 和习惯的 AI 工具，一个小时内闭环一个能跑的东西，这件事现在变得可行。面试官也不必只看最后多了多少行代码，而是可以看整个过程。

我会看候选人打开陌生代码库后的前十分钟。有人会到处乱点，或者直接把需求整段丢给 AI。也有人会先问：入口在哪里？测试怎么跑？现有代码的风格是什么？这个需求最小能做到哪里？后者才像是在工作。

我也会看他怎么和 AI 来回。不会用 AI 的人把 AI 当许愿池，会用 AI 的人把 AI 当一个需要管理的执行单元。他会拆任务，会补上下文，会让模型先读代码再动手，会在关键地方要求它解释假设。

最关键的是，他会不会 blindly trust AI。AI 给了一个看起来很对的答案，他会不会写最小验证，会不会读日志，会不会 challenge AI 说“这段是错的”。这件事比能不能 prompt 出漂亮代码重要得多。

再往后，是 scope 和 tradeoff。AI 很擅长把事情越做越大。一个好的工程师要知道什么时候该停，哪些先不做，哪个方案够用，哪个地方不能糊弄。最后是 ownership。候选人能不能为自己交出去的东西负责，讲清楚为什么这么做。为最终结果负责的是人，不是模型。

Canva 把 AI 放进 Coding 面试后发现，表现差的候选人不是因为不会写代码而卡住，而是不知道该让 AI 做什么，也分不清它什么时候在幻觉（hallucinate）。

这听起来像是降低要求，毕竟我们不再只看候选人能不能徒手写代码。但 AI 出现后，题目反而可以更大、更真、更接近实际工作。我们也因此有了一个更好的 test ground，去观察候选人真实的工作能力。

如果您希望招聘到最佳的 AI 协作力人才，欢迎访问  xmatrix.tech (可点击下方阅读原文)