别再被简历和面试忽悠了：聊聊怎么挖出技术人才的真本事

说真的，干我们这行（HR、技术Leader、猎头）的，谁没踩过几个坑？简历写得天花乱坠，GitHub 上绿得发光，面试时对答如流，结果一入职，让他写个简单的并发处理都卡半天。这种“面霸”和“简历造车”的现象，在技术圈里简直太普遍了。

技术人才寻访，最怕的不是找不到人，而是找错了人。成本太高了，不仅仅是钱的问题，还有团队的时间、项目的机会成本。所以，怎么评估一个候选人到底是不是“真材实料”，而不是“水货”，成了我们必须掌握的核心技能。

这篇文章，我不想讲那些虚头巴脑的理论，就用大白话，结合我这些年“翻车”和“挖到宝”的经验，聊聊怎么像剥洋葱一样，一层层剥开候选人的伪装，看到他最真实的技术能力。

第一层：简历和开源项目——“数字游戏”背后的真相

我们通常是从简历开始的。但看简历，不能只看“精通”二字。

1. 简历里的“坑”与“宝”

现在大家都会写“精通 Java、Python、Go”，甚至还有写“精通 C++”的（这胆子是真的大）。但这些词的水分太大了。我们要看的是什么？是具体场景。

• 别看“负责”，要看“解决了什么”： 比如，他说“负责支付系统的重构”。这很模糊。你要找的是：“在重构中，通过引入异步消息队列，将支付峰值从 500 QPS 提升到 2000 QPS，同时降低了 30% 的数据库压力”。这种带数据、带技术细节的描述，才是可信的。



• 项目经历的连续性： 如果一个人在三年里换了四个公司，每个公司都做的是“核心开发”，但项目之间没有任何技术深度的递进，这就要警惕了。他可能只是在不断地“熟悉”业务，而不是在“深耕”技术。
• “参与” vs “主导”： 很多人喜欢写“参与了某某系统的设计”。参与？是参与了讨论，还是参与了画图，还是参与了写代码？这区别大了去了。如果可能，尽量找那些明确写出自己主导了某个模块、某个架构决策的人。

2. GitHub 不是摆设，是“代码日记”

对于技术人来说，GitHub (或者 Gitee) 就像是他的第二张名片。但怎么看出门道？

很多人只看绿点多少，那是给机器人看的。我们要看的是：

• Commit 信息的质量： 打开他的一个核心项目，看 Commit Message。是写 “update”、“fix bug”，还是写 “fix: 修复了在高并发下因锁竞争导致的死锁问题”？前者是敷衍，后者是思考。一个连 Commit 都写不清楚的人，很难指望他代码写得清晰。
• 代码的“洁癖”： 看他代码的命名规范、注释、目录结构。是随心所欲，还是有板有眼？代码是给人看的，不是只给机器跑的。如果一个开源项目的代码，你看一眼就觉得头疼，那他写业务代码大概率也是一团糟。
• Issue 和 PR 的互动： 他有没有给别人提过有价值的 Issue？或者在别人的项目里提交过高质量的 PR？这能看出来他的协作能力和技术视野。一个只在自己仓库里“自嗨”的人，技术视野可能比较窄。

第二层：笔试与技术初筛——别搞“做题家”那一套

很多公司还在用 LeetCode 难题或者纯理论题来筛选，我觉得这有点走偏了。除非你是招算法研究员，否则工作中真没多少机会让你手写红黑树或者动态规划。

1. 场景化的小题目

比起算法题，我更喜欢出一些场景化的、贴近业务的小题目。比如：

“假设你现在要设计一个短链接生成服务，怎么设计 API？数据库表结构怎么定？如果要抗住每天百万次的点击，你会考虑哪些瓶颈？”

这种题目没有标准答案，但它能逼着候选人去思考：

• 他会不会考虑哈希冲突？
• 他会不会想到分库分表或者缓存？
• 他会不会考虑到分布式 ID 生成的问题？

通过这种开放式的讨论（哪怕是在线文档里写），你能看到他的系统设计思维和知识广度。这比背题有价值得多。

2. 代码审查（Code Review）环节

这是一个非常高效但常被忽略的环节。你可以给候选人一段有明显问题的代码（比如有内存泄漏风险、逻辑不严谨、命名混乱），让他现场指出问题并修改。

这能考察什么？

• 细心程度： 能否快速发现 Bug。
• 代码素养： 他修改时，是仅仅为了修 Bug，还是会顺手把代码重构得更优雅？
• 防御性编程意识： 他会不会考虑到边界条件、异常处理？

一个优秀的工程师，看到烂代码是会“难受”的，会忍不住想去优化它。这种“职业病”是装不出来的。

第三层：面试中的“深挖”技巧——像侦探一样提问

面试是重头戏，也是最容易被“表演”的环节。关键在于，你要学会“深挖”。

1. STAR 原则的“变种”应用

大家都听过 STAR 原则（Situation, Task, Action, Result）。但在技术面试里，光听结果不行，要死磕 Action（行动） 和 Thinking（思考）。

当候选人说：“我优化了接口性能，提升了 50%。”

你不要只说“很好”，你要像连珠炮一样追问：

• “等等，你具体是怎么优化的？是加了索引？改了 SQL？还是上了 Redis？”
• “为什么选这个方案？当时有没有考虑过别的方案？比如加机器？或者异步化？”
• “在这个过程中，你遇到了什么困难？你是怎么排查问题的？”
• “如果数据量再大十倍，你的方案还适用吗？瓶颈会在哪里？”

通过这种层层递进的追问，你可以把那些只“知道结果”但没“亲手做过”的人问得哑口无言。真正做过的人，能清晰地描述出当时的思考路径、踩过的坑、以及对细节的把控。

2. 暴露“知识盲区”而不是“知识储备”

面试不是为了证明他懂多少，而是为了搞清楚他不懂的边界在哪里。每个人都有不懂的东西，这很正常。关键看他的反应。

• 遇到不会的问题： 是直接说“不知道”，还是会尝试着去分析、去推测？比如你问他一个冷门的网络协议，他虽然没听过，但他可能会说：“我不太了解这个协议，但如果是为了解决某某问题，我可能会从 TCP/IP 的哪几个层面去考虑……”这种迁移能力和解决问题的思路，比死记硬背重要。
• 承认错误的勇气： 你可以问他：“你过去做过最失败的技术决策是什么？”如果他开始吹嘘自己从未失败，或者把锅甩给别人，这人不可信。一个成熟的工程师，一定踩过坑，并且能从坑里学到教训。

3. 考察“软实力”：沟通与协作

技术再牛，如果是个“刺头”或者“闷葫芦”，在团队里也是灾难。

你可以通过一些假设性问题来观察：

• “如果你和产品经理在需求上有严重分歧，他会坚持己见，你会怎么处理？”
• “如果你的代码被同事批得体无完肤，你第一反应是什么？”

观察他的语气、表情（如果是视频或现场）。是表现出开放、愿意讨论的态度，还是防御性很强、急于辩解？技术人需要有“对事不对人”的职业素养。

第四层：背景调查——听听“别人”怎么说

背景调查绝不仅仅是核实学历和工作履历，那是 HR 的基础工作。作为技术面试官或 Leader，你的背调要更有针对性。

动用你的人脉，或者通过靠谱的渠道，找到他前公司的同事（最好是平级或者直接下属，而不是只找老板）。

问什么呢？不是问“他表现怎么样”，这种问题太泛了。要问具体的场景：

• “他在项目里，通常负责的是哪一类技术难题？”
• “他代码的 Review 意见多吗？通常关注哪些点？”
• “有没有哪次线上事故，是他主导排查和解决的？过程顺利吗？”
• “如果让你再和他合作一次，你愿意吗？为什么？”

有时候，前同事的一句“他是个很好的执行者，但不太主动思考”，或者“技术很强，但很难合作”，这些信息比面试时的两个小时要真实得多。

第五层：试用期——实战是检验真理的唯一标准

说到底，面试再怎么设计，还是有“表演”成分。最真实的评估，还是得看他在实际工作中的表现。

如果条件允许，付费的短期项目合作或者试用期是最好的试金石。

在试用期，重点关注以下几点：

考察维度	具体表现（好的）	具体表现（需警惕的）
上手速度	能快速理解业务逻辑，搭建好开发环境，主动查阅内部文档。	环境搭了三天还没好，遇到问题不查文档只等人教。
代码质量	提交的代码风格统一，单元测试覆盖到位，注释清晰。	代码逻辑混乱，经常出现低级 Bug，需要别人大量返工。
解决问题的能力	遇到阻塞，会先尝试自己查日志、看源码解决，实在不行才求助。	一遇到报错就慌，立刻在群里喊人，缺乏独立排查能力。
团队融入	积极参与团队讨论，乐于分享，能接受别人的意见。	独来独往，不愿意 Code Review，或者对别人的建议置若罔闻。

通过这些日常细节的观察，你才能真正判断一个人是否“靠谱”。

写在最后的一些“碎碎念”

评估技术人才的真实能力，其实没有一劳永逸的“银弹”。它更像是一种综合的判断，需要你既懂技术，又懂人性。

不要迷信大厂光环，也不要轻视野路子出身。有些人虽然没在大厂待过，但解决实际问题的能力极强；有些人在大厂里只是个“螺丝钉”，出来啥也干不了。

最重要的是，保持一颗好奇心和怀疑精神。多问几个“为什么”，多看几个实际的细节，多听听不同的声音。

找对一个人，能顶半边天。愿大家都能少踩点坑，招到那个能和你一起打硬仗的“真大牛”。毕竟，好的队友，比什么都重要。

紧急猎头招聘服务