我面试候选人时主要看什么

我刚开始参与技术面试时，会在面试前准备一张很长的问题清单。

Java 集合、多线程、JVM、MySQL、Redis、消息队列和分布式系统，每个主题下面还能继续列出很多问题。这种方式容易执行，也能较快确认候选人的知识基础，但面试做得多了以后，我发现会不会答题，和进入真实工作以后能不能把事情做好，并不是一回事。

所以我现在还是会问技术问题，只是不再把整场面试变成一次知识点覆盖。我通常从候选人做过的项目开始，顺着项目背景、方案选择和实际遇到的问题继续问。面试结束时，我需要判断的是下面四件事。

他看不看得懂事情。
他有没有真的做过事情。
他能不能把事情做成。
他未来还能不能继续成长。

他看不看得懂事情

很多候选人可以熟练介绍自己做了哪些页面、接口和模块，也能讲清楚项目使用了什么框架。但继续问项目为什么要做、用户是谁、解决了什么问题，回答有时就会变得模糊。

所以我会继续了解项目的业务目标、上下游关系，以及候选人所在的团队在整个链路中承担什么角色。我并不要求工程师替代产品经理，只是想确认他是在接到需求后完成任务，还是知道自己正在解决什么问题。

需求足够明确时，两种工作方式看不出太大差别。一旦时间不够、需求发生变化或者方案必须取舍，是否理解事情就会直接影响判断。哪些部分不能丢，哪些可以暂时妥协，技术方案最后要服务于什么结果，这些都属于工程师对业务和组织的理解。

候选人的工作年限越长，我越关注这一点。如果一个人始终只能描述别人让他做了什么，我很难判断他面对下一件不够清楚的事情时会怎样处理。

简历里的“核心开发”“负责人”和“主导架构设计”，我不会直接当成证据。这些词在不同团队里的含义差别很大，继续向下问才有价值。

我通常先问项目为什么做，他具体负责什么，再顺着回答追到最难的问题和方案选择。讨论过哪些替代方案，运行中踩过什么坑，最后结果怎样，如果重做一次会改哪里，这些问题不要求顺序固定，也不会每一项都问。

真正做过的项目，讲出来的细节通常很具体，甚至有些零碎。候选人知道限制从哪里来，记得某个方案为什么被放弃，也能说出哪些地方当时没有处理好。如果只是参与过，或者主要工作由其他人完成，追到具体判断和取舍时，信息通常会逐渐断掉。

技术深度也在这个过程中判断。例如候选人说项目里用了 Redis，我会继续问为什么需要缓存，为什么不是本地缓存，一致性和失效怎样处理，Redis 不可用时系统会发生什么，数据量继续增加以后原方案是否还成立。

我关心的不只是他知道多少 Redis 原理，还包括能不能把技术放回当时的场景，说明为什么使用、付出了什么代价，以及什么时候不该使用。顺着一个真实项目问下去，技术基础和判断能力自然会逐渐显露出来。

真实工作很少像面试题那样输入明确、边界清楚，还附带一个标准答案。更多时候，需求没有完全想清楚，系统留着历史问题，依赖团队有自己的优先级，项目进行中还可能改变方向。

因此我会问候选人在这些情况下做过什么。需求不清楚时怎样确认，发现风险后什么时候暴露，依赖方没有进展时怎样推进。时间不够时如何取舍，产品和研发意见不一致时怎样处理，线上出现问题后有没有一直跟到关闭。

“我会主动沟通”这样的回答提供不了太多信息，我更愿意听一次具体经历。问题是什么，他找过谁，做了哪些调整，哪些部分由自己解决，哪些部分需要寻找资源，最后有没有得到结果。

我也会区分独立完成任务和独立完成事情。前者是在需求明确以后，自己完成设计、编码、测试和上线。后者接到的可能只有一个目标，需要先确认问题、澄清边界，再拆解任务、协调资源、暴露风险并推动落地。

在我这里，Owner 不是简历上的职位，也不意味着所有问题都要自己解决。事情没有结束以前，知道它处于什么状态，并且能够推动它继续往前，这才是我所看重的 Owner 能力。

面试只能看到候选人今天表现出来的能力，但真正的合作发生在之后几年，所以我也会关注他过去几年的变化。

“平时怎样学习”很容易得到标准答案。我更愿意问他最近主动学了什么，为什么要学，后来有没有真正用到工作中，也会问过去两三年里，他解决问题的方式发生过什么变化。与其听一个人评价自己是否热爱学习，不如看他怎样把原本不会的事情变成能力的一部分。

这种变化不一定表现为学会了一个新框架。有人从前端逐渐扩展到全栈，有人开始补齐自动化测试和工程工具，也有人开始尝试 Agent 等新的方向。我关心的是，这些学习有没有改变他的工作范围和做事方式。

AI Coding 现在是一个很好的观察窗口。我不会把是否使用 Cursor、Claude Code 或 Codex 当成分界，这些工具本身很快就会普及。我更关心 AI 有没有真正进入他的研发过程。

如果候选人说自己已经大量使用 AI，我会继续了解他怎样提供上下文、拆解任务、审查改动和设计验证，项目里的规则、文档和自动化测试是否也随之调整。只让 AI 帮忙补几段代码，与重新安排从需求、实现到 Review 的整个流程，是不同程度的使用。

AI 可以快速产生答案，但仍然需要有人判断答案是否成立，有没有解决原来的问题。能不能定义问题、发现错误并验证结果，在我现在的面试中会越来越重要。

一场面试无法完整判断一个人，它只是有限时间里的证据收集。候选人紧张、性格内向或者不擅长自我展示，都可能影响表达，但不一定意味着思考不清楚。

遇到这种情况，我会尝试换一种问法，给对方一点整理时间，或者请他画出流程。工作本身需要沟通时，表达能力当然属于评价范围，但不应该简单等同于外向、健谈或者擅长包装。

面试官也需要被约束。问题由我选择，通常还来自我熟悉的领域，天然处于更有利的位置。把候选人问倒并不困难，也不说明面试有效。问题应该与岗位相关，结论尽量来自具体表现，而不是“感觉不错”“气场很强”或者“和我很像”。

如果按可信度从低到高排列，大致是自我评价、知识问答、场景推演和真实经历。自我评价只能作为线索，答出知识题至少说明他知道，面对陌生场景能够合理分析，说明他会使用知识。真实经历里的背景、行动、错误、取舍和结果，通常最接近他以后会怎样工作。

所以问题清单依然保留着，只是它的地位变了。一个问题可以确认基础，改变约束可以观察边界意识，加入异常可以看分析过程，再追到真实经历，验证这些能力是否真正出现过。某个方向已经取得足够证据，我不会为了覆盖知识点继续追问。某个回答里出现值得深入的细节，也可能沿着它问完整场面试。

所以我现在更愿意围绕一个真实项目多问一会儿，而不是急着把题目清单走完。面试结束时，我需要回答的还是开头那四个问题，至于每个问题用了多少道题，并不重要。