java面试官如何面试别人：以场景实操筛选真实技术能力

做了三年后端面试官，摸透了java面试官如何面试别人的核心思路，早前一直死守行业通用的面试套路，不仅筛错不少优质候选人，也招进来不少只会纸上谈兵的技术水货。

最开始面试的时候，流程死板到一成不变，上来就轮番轰炸Java八股知识点，从HashMap的扩容机制、线程池七大参数，到JVM分代回收、SpringIOC源码原理，挨个挨个提问。候选人只要背诵流畅、应答自如，就直接判定技术功底扎实，轻松给到面试通过。那时候完全没意识到，书面理论背得再熟，和实际开发干活是两码事。之前招过一个八股问答近乎满分的求职者，入职之后连基础的接口参数校验都写不明白，遇到线上简单的空指针报错，半天找不到问题根源，硬生生拖慢了小组的迭代进度。折腾好久才搞明白，纯靠理论提问的面试方式，根本筛不出能落地干活的开发人员。

面试的核心从来不是考察记忆力。

后来彻底推翻了原来的面试模式，不再拿着题库机械提问。拿到候选人简历后，优先锁定对方标注最熟悉、参与最深的业务项目，所有问题都围绕真实业务场景展开，绝不问脱离实操的空泛理论。比如对方做过电商支付模块，就追问高并发下单时的防超卖方案、支付超时的补偿逻辑、数据一致性怎么保障，全程顺着业务细节深挖，不设置标准答案，只看对方能不能讲清真实的开发过程。

真正深耕过项目的人，回答都是有细节、有痛点的。能清晰说出自己写的核心代码逻辑、上线前踩过的坑、调试问题的具体步骤，甚至会主动提及当时代码存在的缺陷和后续优化方向。而靠包装项目、背诵面试题的候选人，一遇到深度场景追问就会露馅，只会用通用理论套话，一旦要求结合具体业务举例、梳理落地流程，就开始含糊其辞、逻辑混乱，真假实操经验，一问就能分辨出来，这是比八股问答更精准的筛选方式。

固定会留几分钟现场手写代码的环节。

从不考复杂的算法压轴题，只出日常开发高频使用的基础逻辑，比如list集合高效去重、异步线程任务编排、事务失效场景模拟修复这类实操内容。不苛求代码极致简洁优雅，重点观察编码习惯、逻辑思维和细节把控。很多理论对答如流的人，手写代码时漏洞百出，不会做参数判空、循环边界出错、变量命名混乱，这些肉眼可见的问题，足以说明日常编码的真实水平，是口头提问完全发现不了的短板。

面试最后都会留自由提问的时间，用来辅助判断候选人的适配度。只纠结加班时长、固定薪资、工作闲忙的人，大多是被动干活、不愿深耕技术；主动询问项目架构、技术迭代方向、团队技术规范的求职者，普遍有主动学习的意识，愿意跟着业务成长。技术能力决定能不能入职，职业心态和学习意愿，决定能不能长期留用。

每次面试结束整理完台账，都会顺手删掉题库里固化的八股问答清单。