从年初到现在，大家在 AI Coding 时代的工作方式已经有了很大变化，但我在社区交流时发现，面试方式似乎没有相应调整。
今年四月开始，我作为面试官进行了多场面试，也在这个过程中尝试调整了一些做法。以下是从面试官视角做的一些阶段性总结，分享出来和大家交流。
一、是否还需要写代码？
在技术讨论环节，我已经不再要求候选人当场手写代码了。
但这不意味着可以跳过技术基础。为了了解候选人是否只是会用 AI、自己却不理解技术，我仍然认为有必要考察基础的编码知识和计算机原理。使用 AI 完成开发，也需要理解代码在做什么，能够判断结果是否合理。
二、AI Coding 能力要不要考察？
我推荐在面试中安排一个 AI Coding 环节。现在大家或多或少都会使用 AI 协同开发，但使用的深浅不一。完全不涉及 AI 的考察，和实际工作会有一些脱节。我也和候选人交流过，他们会通过面试形式，反推团队平时使用 AI 的程度。
在这个环节里，我主要关注三个阶段：
- 开始写之前，候选人能不能抓住题目里的关键点。
- 进行 AI Coding 时，有哪些实践习惯，可以作为后续交流和追问的内容。
- 最后留一段时间，让候选人离开代码，把方案完整讲一遍，再围绕方案往外延伸几个问题。
实践下来，我也发现了一些需要调整的地方。
时间是最大的限制。 我试过给这个环节三十分钟，但等待生成、阅读方案和审查代码就会占掉不少时间，候选人很难再深入展开。一个可以考虑的调整，是把 AI Coding 任务放到面试前，让现场有更多时间用于思考和表达。至于实时面试里如何分配这段时间，我还没有特别好的解法。
AI 会抬高基础产出的水平。 在我接触的一些题目里，AI 给出的基础答案已经相当完整，和前几年只靠候选人现场完成的结果相比，差别很大。这也对面试官提出了更高的要求：需要更深入地准备题目，才能通过后续讨论，了解候选人对方案究竟掌握到什么程度。
三、不看写码看什么？
我重新用起了白板，让候选人手绘技术方案。
这和系统设计类题目很接近：从候选人熟悉的项目出发，延伸或切分出一个相关的产品功能或业务场景，请他做一个完整的设计。可以画时序、分层、部署、组件关系，模拟几个人围着白板设计一个功能。
我会更多地关注完整的系统链路，而不只局限在前端或后端的单一技术栈。讨论也会由浅入深，先画出基础框架，再选择其中值得深入的部分，继续细化。
以前，这类讨论更多出现在对经验要求较高的岗位面试中；现在，我会把它扩展到更多经验阶段的候选人。
之所以加大这部分的比重，是因为在开发工作中，我们越来越多地需要给出合理的方案，再让 Agent 执行。理解方案的取舍、判断设计是否合理，变得更加重要。
为什么要画在白板上，而不只是口头表达？我发现，把系统画出来、具象化，能让一些原本模糊的概念和关系显露出来，也更方便双方继续追问和澄清。
四、技术之外还有哪些要求？
我现在习惯在系统设计和白板讨论后，根据岗位要求，继续追问产品功能设计或业务逻辑问题，希望了解候选人的产品意识。
例如，可以围绕刚才讨论的产品问一个问题：如果要做一个砍到不能再砍的 MVP，需要保留哪些功能？
我个人理解，这属于一个业务和技术结合的问题。既要理解核心的业务闭环，也要考虑技术实现的可行性和成本。
另一方面，如果候选人在简历中提到某个业务或技术指标的提升，我会继续追问：这个目标为什么合理，它对整体业务的贡献是什么？因为能设定一个好的目标，也是一项重要且有意义的能力。
五、如何考察 AI 实践能力？
上面一套讨论下来，面试时间就快结束了。但我还是想尝试增加一道关于 AI 实践的问题。
我曾经问过：“你有哪些好的 AI 实践可以分享？”后来发现，效果不太理想，主要有两种情况。
一种是，讲的内容听起来过于基础，似乎没有区分度。比如 SDD，里面其实有很多细节，但如果不继续深入追问，就容易把一次具体的实践听成几个常见概念。
另一种是，讲的内容天花乱坠。网上有很多“前沿”实践，即使没有亲自做过，也可能复述得很精彩。仅听这些概括，很难了解候选人实际掌握到了什么程度。
所以，我目前尝试换了一个问法：“你最近一次最失败的 AI 实践是什么？”
失败本身不是扣分项。相比复述别人的成功套路，讲清楚一次自己的失败，更需要具体的经历和细节。我希望从中了解候选人当时遇到了什么问题、怎样理解 AI 的能力边界，以及如何复盘和总结。
最后
以上这些做法，都只是我个人的阶段性实践总结。
AI Coding 变化很快，对工程师的要求也在变化。面试标准往往滞后于工作本身，AI Native 的 Product Builder 会沿着怎样的路径成长，似乎还没有定论。我把现阶段的想法、做法与失败写下来，希望能给同样在思考这些问题的面试官提供一些参考。
评论