别被简历忽悠了：一个老猎头的“技术验货”实操手册

说真的，干我们这行，最怕的不是找不到人，而是找到的人是个“水货”。尤其是那些简历写得天花乱坠，什么“精通分布式架构”、“深度参与过亿级流量项目”，结果一上技术面试，连最基本的TCP三次握手都说不明白。这种经历，每个资深猎头都有一箩筐。所以，怎么在动用昂贵的面试资源之前，或者在面试官被候选人“带节奏”的时候，我们自己能先摸个底，这就成了一门核心手艺。这篇文章，不讲那些虚头巴脑的理论，就聊聊我这些年摸爬滚打总结出来的“验货”土办法，希望能给你点实在的启发。

第一道坎：简历的“滤镜”有多厚？

我们先从最基础的简历筛选说起。一份简历，其实就是候选人的“精修图”。我们的工作，就是把这个滤镜给它扒下来，看看素颜到底长啥样。

别看“会什么”，要看“用什么解决了什么”

很多人写简历，喜欢堆砌技术名词，恨不得把市面上流行的技术栈都写上。比如“熟悉Java、Python、Go，了解MySQL、Redis、Kafka”。这种写法，信息量几乎为零。什么叫“熟悉”？是写过“Hello World”，还是用它独立开发过一个完整的模块？

我更倾向于看那些具体的、有上下文的描述。比如：

• 错误示范： 负责后端开发，使用Spring Boot和MySQL。
• 正确示范： 在XX项目中，为了解决高并发下的订单超卖问题，我使用Redis实现了分布式锁，并结合Spring Boot的AOP切面，将下单接口的响应时间从500ms优化到了100ms以内，同时保证了数据的一致性。

看到区别了吗？后者包含了场景（高并发订单超卖）、技术选型（Redis分布式锁 + AOP）和量化结果（500ms -> 100ms）。这种描述，真实性高得多，也更能体现一个人的真实水平。如果一份简历里，全是第一种描述，那基本可以判定，这个人要么是刚入行，要么就是个“API调用工程师”，深度很有限。

深挖项目细节，寻找“魔鬼”细节

对于简历上提到的每一个项目，我都会像一个侦探一样，去寻找那些只有真正做过的人才知道的“魔鬼”细节。这些细节，是伪装不出来的。

比如，一个声称做过微服务架构的人，我会在心里默默问几个问题：

• 你们的服务是怎么拆分的？是基于业务领域，还是别的什么原则？有没有遇到过“分布式事务”的问题？怎么解决的？（如果他只说了用Seata，但说不清TCC和AT模式的区别和应用场景，那就要打个问号了。）
• 服务之间怎么通信？同步的还是异步的？有没有考虑过服务雪崩？熔断和降级是怎么做的？（如果他只说了用Hystrix或Sentinel，但说不清具体配置的参数含义，比如超时时间、阈值等为什么那么设，那很可能只是照猫画虎。）
• 你们的配置中心和注册中心用的什么？为什么选它？遇到过配置推送失败或者服务实例上下线抖动的问题吗？（真正踩过坑的人，会跟你吐槽Nacos和Eureka在某些场景下的“坑”，而不是只说它们的好处。）

这些问题，不需要他当场给出完美答案，但他的反应很重要。是眼神闪躲、含糊其辞，还是眼睛一亮、滔滔不绝地讲自己当时是怎么排查和解决的？后者，才是我们要找的人。

第二道坎：技术电话初探，聊什么？

简历筛选通过后，猎头通常会有一个简短的电话沟通。这个环节，很多猎头喜欢问“你为什么离职”、“你对薪资有什么期望”。这些当然要问，但别忘了，这是我们第一次“技术验货”的黄金机会。你不需要懂技术，但你需要懂得怎么“引导”技术。

用“故事”代替“考题”

直接问技术问题，你一个非技术背景的猎头，很容易被对方用专业术语糊弄过去。更好的方式是，让他讲故事。

你可以这样说：“我看你简历上写的那个XX项目挺有意思的，能给我讲讲你在里面印象最深的一件事吗？比如，遇到过什么特别难的技术挑战，当时是怎么想的，又是怎么解决的？”

一个好的工程师，会把解决技术问题的过程，讲得像一个破案故事。他会提到：

• 问题现象： “当时我们系统一到下午三点就卡死，用户投诉电话被打爆了。”
• 排查过程： “我们一开始怀疑是数据库问题，查了慢查询日志，没发现异常。后来用Arthas在线诊断，发现是有个线程池的队列满了，导致请求全部被挂起。”
• 解决方案： “我们紧急调整了线程池参数，同时加了监控告警。事后又重构了这块代码，把非核心逻辑改成了异步处理。”

如果他讲的故事干巴巴的，只有结果没有过程，或者反复强调“我们团队”如何如何，很少提到“我”做了什么，那就要警惕了。这可能说明他只是个边缘角色，或者对技术细节一知半解。

关注“学习能力”和“技术热情”

技术这东西，日新月异。一个优秀的技术人才，一定是个持续学习者。在聊天中，可以不经意地问：

• “最近有在关注什么新的技术方向吗？”
• “平时除了工作，会看些什么技术书籍或者文章？”
• “有没有自己写过什么小工具或者开源项目？”

如果他能跟你聊起最近在看的某个技术框架的源码，或者他自己为了方便工作写了个小脚本，甚至是在GitHub上给别人的项目提过PR，那这种人对技术的热情是藏不住的。这种内在驱动力，往往比他现在掌握的某项具体技术更重要。

第三道坎：技术面试旁听或复盘，抓关键点

如果候选人进入了技术面试环节，作为猎头，如果能争取到旁听（很多公司不允-许，但可以事后找面试官复盘），那是最好的。即使不能旁听，也要和面试官深入沟通，获取最真实的反馈。

基础知识的“地基”牢不牢？

万丈高楼平地起，基础知识就是这个地基。无论面的是什么高级岗位，基础知识的考察都不能少。很多面试官会因为候选人的履历光鲜，就忽略了基础，这是大忌。我们作为猎头，要提醒企业注意这一点。

可以建议面试官重点考察以下几个方面，这些都是我总结的“重灾区”：

技术领域	核心考察点	“水货”常见表现
编程语言 (如Java)	集合框架、多线程、JVM内存模型、垃圾回收机制	能背出概念，但说不清HashMap的扩容机制，或者讲不出多线程并发问题的实际案例。
操作系统/网络	进程/线程区别、TCP/UDP、HTTP状态码、从URL输入到页面展示的全过程	知道TCP三次握手，但说不清为什么需要三次，或者对滑动窗口、拥塞控制一无所知。
数据库 (如MySQL)	索引原理 (B+树)、事务隔离级别、锁机制、SQL优化	知道加索引能提升速度，但说不清什么情况下索引会失效，或者对MVCC的实现原理一脸茫然。

一个真正懂的人，能把这些复杂概念用最简单的比喻讲给你听。比如，解释B+树索引，他可能会说：“它就像一本书的目录，能让你快速定位到内容，而不是一页一页地翻。”如果他只会背定义，那基本就是“理论派”。

系统设计的“灵魂”：权衡（Trade-off）

对于中高级人才，系统设计题是必考的。这类问题没有标准答案，考察的是候选人的综合能力。评估的关键，不在于他最后画出的架构图多完美，而在于他整个思考和交流的过程。

一个优秀的候选人，在面对“设计一个短链接生成服务”或“设计一个朋友圈Feed流”这类问题时，会不断地进行权衡和取舍。他会主动说出：

• “如果要保证高可用，我可能需要多地多机房部署，但这样数据一致性会是个挑战。”
• “如果要追求低延迟，我可以把数据都放在内存里，比如Redis，但这样成本会很高，而且有数据丢失的风险。”
• “这里，我选择用哈希算法来生成短链接，但哈希冲突是个问题，我可能会用一致性哈希或者增加自增ID来避免。”

他能清晰地告诉你，为什么选A方案而不是B方案，各自的优缺点是什么，未来的扩展性如何。而一个经验不足的候选人，往往会一头扎进细节，或者给出一个“银弹”式的方案，忽略了现实中的种种约束。面试官的复盘，重点就应该放在这些“权衡”的讨论上。

第四道坎：代码能力的“试金石”

前面聊了那么多，最终还是要落到“动手能力”上。代码能力是工程师的核心，也是最难伪装的一环。

线上编程测试（Coding Test）

现在很多公司都用LeetCode之类的平台做第一轮代码测试。作为猎头，你要了解这个环节的通过率和难度。如果一个候选人连简单的算法题都做不出来，那他的编程基本功肯定不过关。但也要注意，刷题高手不一定就是好工程师。所以，这只能作为第一道过滤网。

“白板”或“共享屏幕”编程

这是更深入的考察。面试官会出一个具体的业务场景，让候选人现场写代码。我们关注的重点是：

• 代码风格： 变量命名是否规范？代码结构是否清晰？有没有大段的重复代码？（这反映了工程师的素养和严谨性。）
• 边界条件处理： 他有没有考虑输入为空、数据越界、并发请求等异常情况？（这体现了代码的健壮性和思考的全面性。）
• 与面试官的互动： 他是闷头就写，还是会先跟面试官确认需求、沟通思路？（这反映了沟通能力和团队协作意识。）

我曾经遇到一个候选人，算法题刷得飞快，但让他设计一个简单的用户登录模块，他写的代码完全没有考虑密码加密、防暴力破解等安全问题。这种就是典型的“解题家”，而不是“工程师”。

开源项目和GitHub贡献

对于资深候选人，他的GitHub主页就是一份最真实的简历。你可以去看看他提交的代码（Pull Requests），看看他写的文档，甚至看他给别人的项目提的Issue。一个高质量的PR，能反映出他对代码规范、单元测试、代码审查的理解。这比任何面试都更有说服力。

第五道坎：背景调查的“技术侧写”

背景调查，通常被认为是核实工作履历和薪资的。但对于我们猎头来说，它也是评估技术能力的最后机会。关键在于，你要找对人，问对问题。

找谁？

首选是候选人的直接上级，其次是合作密切的同事（比如项目里的技术骨干）。避免找HR或者行政人员，他们对技术能力一无所知。

问什么？

问题要具体，引导对方给出事实和例子，而不是主观评价。

• 别问： “他技术能力怎么样？”（太宽泛，对方可能只会说“还行”、“不错”。）
• 要问： “在你们合作的XX项目中，他主要负责哪块技术？有没有遇到过什么技术难题？他当时是怎么解决的？在这个过程中，他扮演了什么样的角色？是自己独立解决的，还是在别人的帮助下完成的？”

通过这些问题，你可以拼凑出候选人在真实工作场景中的技术画像。他是那个遇到问题冲在最前面的人，还是那个习惯于求助的人？他是团队的技术“定海神针”，还是一个需要别人不断“带”的 junior？

还可以问一些开放性问题，比如：“如果让你评价他在技术上的优点和需要提升的地方，你会怎么说？”一个客观的上级，会给出非常中肯的评价，比如“他算法基础很好，解决常规问题很快，但在系统架构设计的前瞻性上还需要多锻炼”。这种反馈，对推荐决策非常有价值。

写在最后的一些心里话

说到底，评估一个人的技术能力，就像中医的“望闻问切”，是一个综合判断的过程，没有一招鲜的秘诀。它需要我们猎头自己，至少要对技术有敬畏之心，要懂一些基本的门道，要能听懂工程师们的“黑话”。更重要的是，要保持耐心和好奇心，多问几个“为什么”，多挖几层“怎么做”。

我们不是技术面试官，我们的职责不是去考倒候选人。我们的目标是，通过我们专业的眼光，为企业筛选出那些真正“靠谱”的技术人才，同时，也帮助那些有真才实学的工程师找到能发挥他们价值的舞台。这个过程，既是为企业负责，也是为候选人负责。当你能准确地判断出一个人的真实技术段位时，那种成就感，远不止是成了一单生意。这，或许就是我们这份工作最大的魅力吧。 海外分支用工解决方案