我是骆启衡，做技术团队负责人第十年。
这篇文章，我想和你聊的，不是宏大的“人才战略”，而是你明天就能用上的 工程师招聘实操方法：怎么写 JD，怎么筛人，怎么面试，怎么避免踩坑。读完，你至少能做到两点：
- 招到的工程师，和团队真正匹配，而不是“来了就后悔”；
- 招聘效率更稳定，不再完全看“运气”和“缘分”。
文章更适合这样的你：做技术负责人、Tech Lead、创业公司 CTO、或者被老板临时指定负责招聘的工程师。如果你现在正为招不到合适工程师发愁，可以当作一份小小的“陪跑指南”。
很多技术负责人会说：“我们需求挺清晰的啊，就照着市场上的 JD 模板改一下。”
问题就在这里。你在用别人的 JD，找你心里那个“理想中的人”。偏差，从这一刻就埋下了。
过去两年，我帮几家中小公司改过 JD，有一个统计挺刺眼：只改 JD，不改薪资、不加 HC，不动流程的情况下，平均相关简历投递量提升了约 38%，面试通过率提升接近 20%。只是写得更清晰、更诚实，效果就这么明显。
我自己写 JD，有三个坚持：
说人话，不说诗不写“追求极致”、“对代码有洁癖”这种空话，而是写：“你会维护一套已有 5 年历史的核心系统，代码风格不统一，文档不完整，你需要有耐心去一点点梳理，而不是嫌弃转身就走。”真话一出来，那些只想写新项目、讨厌维护老系统的人自然就不会投。你省掉了很多无效面试。
把“这个岗位一年后的样子”写出来比如：
入职 3 个月：熟悉现有核心服务，能独立接 1～2 个需求，从评估到上线全流程跟进入职 12 个月：负责某个子系统的整体稳定性，并能给出重构或优化建议，落地 1～2 个改进项目这种描述，会吸引那些真的在乎成长路径的工程师，也会吓退只想“混个安稳”的候选人。
把“你可能会不开心的地方”写在 JD 里比如：
- 文档当前不完善，需要边做边补
- 需求变更比较频繁，产品团队也在调整节奏
- 没有专职测试，开发需要参与部分测试工作很多公司不愿写这些，总担心吓跑人。现实是：你确实会吓跑一些人，但留下来的，是已经对这些点有心理预期的人，上岗后磨合冲突会少很多。
工程师其实很会“读空气”。当一个 JD 只有大词、没有细节，他们会默认：这里的现实情况，可能比我想象中还糟糕。而当 JD 写得细一点、真一点，他们反而会觉得：这家公司起码不骗我，值得聊一聊。
一堆简历摆在你面前，技术负责人一般只有两种极端做法：
- 一份份看，看到想躺平；
- 只看大厂/学历，几秒钟一个决定。
在 2026 年这个行情下，工程师的简历比过去复杂得多，频繁跳槽、跨技术栈、Gap 期都很常见。如果筛选还按老眼光，很容易错过好苗子。
我现在用的是一套很简单的“三段式快筛”，每份简历看 2～3 分钟就能有但比纯凭感觉可靠得多：
看“解决问题的痕迹”，不只看“堆技术名词”例如简历写：
负责订单系统的开发，使用 Java、Spring Cloud、Redis、MySQL这种信息几乎没价值。如果写成：订单高峰期接口平均响应在 800ms 左右，通过拆分服务、添加缓存，将 80% 请求控制在 200ms 内你立刻能看到：他在解决问题，而不是只在“写业务代码”。
看“时间线和成长速度”一个人在同一家公司 2 年，却一直写“参与 XXX 项目开发”，没有任何“负责”“主导”的字眼，多半说明成长有限。另一种情况，1 年换 3 家公司，但每一段都能说清楚：自己接手了什么、做出了什么结果，哪怕公司很小，也可能是一块宝。
看“和你这个岗位的交集”做后端的，不必排斥曾经干过前端或运维的候选人。关键是看：
- 他在你当前用的技术栈里，是否有 30% 以上的重叠；
- 他是否有你短期迫切需要解决的问题的相关经验，比如“接手遗留系统”“从 0 到 1 建监控”“给老系统补自动化测试”。只要交集足够，技术栈完全匹配反而不是最高优先级。
很多时候，你觉得“一个也不合适”，并不是市场上没人才，而是筛选时你的“雷达”只盯着学历、年限、名企。这种雷达，在 2026 年已经严重过期。
工程师招聘最容易失真的是面试环节：
- 候选人提前刷过题库，你问的一大半问题，他都背过；
- 面试官图省事，拿着一套固定题问所有人。
这样筛出来的人，很可能是“考试型选手”，进了团队却不一定能搞定真实项目。
我现在做面试，更偏向“拉着对方一起解决一个小问题”。形式大概是这样：
准备一个和你业务类似、但不涉及公司隐私的场景比如你在做电商，就给一个简化的订单扣库存场景；你在做 SaaS，就用一个简单的多租户权限设计；不用特别难，但要有取舍、有边界情况。
一起画草图，而不是只听他说给对方一张纸或一个在线白板，让他画出大致的设计：
- 哪些服务？
- 数据怎么走？
- 哪里可能出问题？边画边问：“如果这里挂了，你打算怎么兜底？”这种互动比背八股更能看出：
- 他有没有工程直觉；
- 他遇到未知情况，会不会发懵。
把沟通也当成评估的一部分很多技术人忽略这一点：工程师不是只对代码负责，还要对人负责。在面试里留意这些小细节：
- 他解释问题的时候，会不会自发地做“背景→方案→可能的问题”这种组织；
- 他遇到不会的问题，是坦然承认，还是试图胡扯过去；
- 他对你指出的风险，有没有反馈和思考，而不是一味迎合。
我面过一个工程师，算法一般，框架用得也就中规中矩，却能把一个异常场景拆得非常细，把“我们可能在凌晨两点被运营叫醒”的情况想到前面。这种人进团队，往往会在真正关键的时候救你一命。
很多公司都有这样的经历：“费了九牛二虎之力招来一个人，半年就走了。”
2026 年的工程师，比以往任何时候都更看重三件事：
- 做的事情有没有意义；
- 能不能持续成长；
- 团队氛围和自由度如何。
薪资当然重要，但只靠涨薪很难解决留人问题。工程师招聘，在我看来，一半是招，一半是“前置的留人动作”。
在面试和 offer 阶段，我会刻意做几件事：
直接聊“你来这儿一年后，想变成一个什么样的人”有人说想带团队，有人说想把基础设施补起来，有人说只想静静写代码。你要诚实判断：
- 公司有没有相应的空间给他；
- 你的团队是否真的需要这样的定位。如果没有，不要勉强。短暂的“招到了”换来的是更快的“离职申请”。
在面试里就开始“入职前的对齐”很多冲突，都是因为信息不对称。所以我会提前讲：
- 我们现在的交付压力大概是什么水平；
- 加班的节奏，是真的极端情况才会出现，还是每周都是常态；
- Code Review 是怎么做的，是否鼓励提出不同意见。工程师对这些感知非常敏感，比你想象的敏锐得多。
认真对待前两个月的体验，而不是“招到就算完成任务”一个新同事进来，如果：
- 没人带，只能边问边摸索；
- 文档混乱，环境搭建要折腾一周；
- 第一个需求就被安排一个又急又乱的坑；他对公司的印象几乎会直接定型。如果你把这两个月当成招聘的一部分来设计，新人留下的概率会明显提高。
有一家公司，我帮他们做了一件特别简单的事：拉了三个平时爱分享的工程师，轮流当“新人向导”，只负责前两周的答疑。半年之后，他们新人的 6 个月内离职率，从 30% 降到 15% 左右。工程师招聘的“性价比最高改造”，往往就在这些看起来“不够酷”的细节里。
很多技术负责人在抱怨：“今年招人太难了，市场上怎么都这样的人。”但每次我被拉去帮忙看招聘流程，都会发现一些非常基础但常见的问题。你可以对照着，给自己做一个小体检：
我们究竟在找“能把事做完的人”，还是“气质上看着像大牛的人”？如果你特别在意 title、学历、年限，就很可能把真正“能搞定活”的人挡在门外。问问自己：
我现在最需要的，是一个能稳定接住需求、把系统维护好的人，还是一个能在技术大会上讲炫酷方案的人？你的答案，会完全改变你的招聘策略。
我们有没有愿意为“好人才”做一点点让步？市场上真正合适的人，往往会同时拿到好几家 offer。一家公司愿意为他多等两周入职，另一家公司要求他必须一个月内到岗，你猜他更倾向哪一边？有时候，你只要在地域、上班模式（例如混合办公）、技术栈迁移上多一点弹性，就能多拿下一两个关键工程师。
我们是不是把所有问题都归咎于“市场不好”，而没看自己的招聘体验？简历投递后，三天没人回；面试约了三轮，间隔一两周；Offer 流程模糊，对方问“进度如何”你也说不清楚。工程师非常敏感，这种体验在他们心里会直接折算成：
这家公司做事流程可能也差不多。如果你把候选人的流程体验当成产品体验来优化，你会惊讶于转化率的变化。
工程师招聘，永远不会变成一件“完全不费力”的事。但它绝对可以变成一件“更有掌控感”的事。
你可以从改一份 JD 开始，从重新设计一场技术面试开始，从认真对待一个新人的前两个月开始。这些看起来琐碎的小动作，会一点点改变你团队的气质，也会在某个加班到深夜的时刻，让你庆幸：还好当初，我在招聘这件事上多花了一点心思。
如果你现在正卡在“工程师招聘招不对人”的困境，不妨先挑文中一个点试着调整。招聘这件事，从来都不要求一口吃成胖子，但每一次认真选择自己团队同伴的时候，你也在重新选择你未来几年的工作生活。
