从运营、到产品、再到技术研发落地，都需要一个团队的执行，尤其要仰仗团队的核心骨干来执行落地。对于 CTO 等技术领导者来说，招聘始终是绕不过去的话题，毕竟，任何一个团队，都不是每个岗位都齐整，等着你来领导的。如果技术领导者不能搭建自己的强大团队，是无法胜任其岗位的。

那么，招聘前需要做好哪些准备工作？如何定岗定级？有哪些有效的招聘渠道？本文将就这些问题展开探讨。

明确发展阶段

首先要明确的是公司发展阶段，这点非常重要。产品从 0 到 1，和 1 到 N 的过程中，对团队的人员需求，能力诉求是完全不一样的。在从 0 到 1 的过程里，讲究的是如何高效的利用现有的条件实现产品研发落地，而不过分追求技术的先进性。

这个阶段中，往往从 CEO 开始到一线的产品、研发人员未必清楚产品在市场上的响应，整个团队的核心思想其实是需要将产品放到市场上试错，从而收集第一手的用户数据，这时，时间决定一切。这个时候的 CTO（未必就是一个 CTO，可能是技术总监或者技术专家的角色）更多应该扮演的是技术专家的角色，主要的工作是根据产品的设计，带领大家一起写代码，并在团队资源紧张的情况下，自己撸起袖子写代码。

随着产品在市场的反响越来越好，慢慢的有了一些用户基础和用户数据，数据日益增长，原来的系统架构越来越不能胜任用户增长、数据增长的需求，要求平台从会员、商品、WMS、交易等进行划分，甚至微服务化，此时对团队的技术能力要求也越来越高，需要专人专岗负责，甚至专业的团队来负责。这时，团队规模较公司创立之初有了较大幅度的扩张，CTO 应该将更多的精力转移到团队管理，如绩效、战略等。

明确团队发展阶段对于 CTO 来说，是招聘的前提，比如在创业之初，没有 P9 级别的诉求。做技术的人都有一个通病，总是希望将技术做到极致。殊不知，在 QPS 1000 都到不了的情况下，从技术上将 QPS 做到 100 万级别没有任何价值。

在本人的从业经历中，遇到过这样的例子：当时公司 TPS 大概在 100 左右，本人空降过去成为技术 Learder，团队里有一个技术控，他的技术能力确实不错，一眼就能看穿我们当时的系统技术上的瓶颈。但是当时的系统足够使用，没有从技术上改造的必要。而当时另外的一个业务产品需要新的团队来负责，我希望由他来负责，但是他就是不想负责这个业务产品，就是想对平台的技术进行改造，希望团队能协调资源支持他进行改造。多次沟通无果，最后不欢而散。

我也遇到过另外一个相反的例子，当时我们系统的 TPS 大概在 3000 左右，而实际的用户场景中对 TPS 的需求已经达到了 30000+，直接导致系统每天都要不定时的重启。我认为每天对生产系统不定时的重启是不合理的，而且没有监控系统，不知道什么时候需要重启。在本人未入职之前，整个技术团队为了解决这个问题，将所有的精力都投入到了新产品的研发中，而置生产系统不顾，关键是新的产品不知何时落地何时上线，也不知能否解决这个问题。我上任之后的第一件工作就是希望解决这个问题，其实从技术上来说并不难，但由于团队里没有合适的人，只能是我自己带领技术人员来解决。

以上例子说明，作为技术领导者，在用人和招人时，要非常明确团队所处的阶段，在合适的阶段用合适的人，当然也包括 CTO 在内。

定岗定级

大多数的创业型互联网公司都是靠融资活着，在公司扩张方面，有人任性，有人谨慎。当然也见过有人任性到拿到投资时无限制招人，到最后裁员的结局。任何一家公司都不可能无限制的扩张，基本都是根据业务的需求制定合理的招聘需求，对于技术领导者来说也是一样的。

作为一个技术领导者，需要根据业务和产品的需求，结合现有团队的资源（现有团队的能力分布对于新的业务需求在招聘岗位上的能力需求是很有意义的参考），定义岗位的能力要求。

比如，现在要做一个 WMS，那么首先就要评估团队的现状，明确团队的技术栈（比较忌讳采用全新的技术栈，一般沿用现有的技术栈）。从产品角度来说，如果团队成员对 WMS 都比较熟悉，但就是没有资源能将想法落地，此时需要一个对 WMS 有点概念或者比较资深的产品经理来设计落地即可，至于招聘还是内部提拔，视不同情况而定。

对于研发技术人员的需求，本人比较崇尚根据目前团队某个产品的 duty team 的构成作为参考，而不是盲目地提升团队的需求，导致招人困难，致使项目延期；也不需要为了便于招人，刻意降低团队的需求，从而导致最后产品质量没法保障。

那么如何定级呢？相信大家对现在互联网行业中的 P／M 定义都非常熟悉，但是不能照搬，要结合自己团队的现状定义合理的级别。此时，HRBP 在这个过程中能够起到很大的作用，通常 HRBP 在每个季度都会对团队的效能进行分析，明确每个团队，每个伙伴的绩效分析，和效能分析报告。CTO 可以根据这些分析报告，结合业务需求，制定比较合理的 headcount。

在技术管理者中不乏这样的人，对 headcount 的诉求是拍脑袋决定的，总觉得人越多越能显示权威，说明自己越厉害。这样的技术管理者自身就是不合格的，我们一定要避免陷入这种思维。

招聘渠道

面向不同岗位，不同定级的招聘诉求，对应的招渠道应该尽量多样化。可能很多人都认为招聘渠道的获取应该是 HR 的事情，这种观点本人并不认可。本人 2003 年参加工作，那个时候领导真的是领导，在办公室高高在上，而现在的领导，尤其是互联网行业的 CTO 等，已经早就不是领导，而是保姆。对于招聘渠道的布置和推广，CTO 至少要参与其中，给出思路，让 HRBP 去执行。

目前比较有效的几个招聘渠道，基本上有下面几种：

1、熟人圈子
这种方式是最可靠的，尤其针对核心岗位，骨干级别，高 P／M 级别的岗位，非常推荐这种方式。熟人圈子最大的优势是，对于业主和候选人都知根知底，背景清楚。

2、猎头
通常企业在需要招聘团队负责人时，才会启用猎头，毕竟利用猎头的成本不低。但是，由于猎头准入门槛较低，滥竽充数者大有人在，作为团队负责人，想要提高命中率，恐怕需要向猎头明确候选人背景、候选人经历、能力、岗位诉求、岗位价值回报等。因为对于候选人来说，猎头是其最先接触，并最先了解企业的入口。候选人往往会希望从猎头口中得知更多的关于企业的信息。这就要求企业在向猎头发布招聘需求时，非常清晰的表达企业的要求之外，还要明确说明岗位的工作内容，价值回报等。

本人经历过太多猎头推荐岗位，大多数的猎头没有办法清晰的描述业主的 vision、企业的商业模式、岗位的基本诉求，更多的在谈该岗位的价值回报，要知道，通过猎头推荐的岗位，候选人往往更加在乎的是能否共同成长。

因此，通过猎头实施招聘，建议选择专业的猎头机构，专业的人员合作。

3、内部推荐
内部推荐实际上是对企业文化的一次考验。记得一位朋友曾经说过，如果公司发布的任何一次关于公司 vision，团队文化建设等，员工都将其分享到朋友圈，说明该公司的企业文化建设相当成功。

大多数创业型团队将内部推荐作为常态工作。根据岗位定级的差异，设计内部推荐的激励制度。内部推荐成功的概率往往比较高，毕竟大家都不希望自己推荐的候选人被拒，从而或多或少影响到自己。

4、扫街
负责团队招聘的 HR 在各大招聘信息网站上海选简历，将符合需求的简历放入到人才库，接着再一个一个电话预约面试。

这种获取简历的方式工作量巨大，效率比较低下，也难以获取符合岗位诉求的候选人。
目前，很多公司已经不大会采用这种方式了。

5、发布招聘信息
大多数希望从传统转型到互联网的企业比较喜欢的招聘渠道。由于深受传统思维的限制，这种类型的企业的 HR 大多认为用人单位是强势的一方，就等着人家主动投递简历过来，我来筛选。

现在的招聘方式变了，候选人更加在乎的是自己做事情的感受，是否被认可，是否受到应有的尊重。不是说不能发布招聘信息，而是应该更加主动的出击，直接面对候选人，而非被动的等待投递的简历上门。

对于招聘渠道，往往需要一个双向的，长期的建设过程，除了正常的维护高质量的招聘渠道之外，还要尽量的对外推广。推广的目的之一是企业形象的推广，实际上是促进招聘的便利。

结语

招聘，对于很多团队来说，只是日常工作的一部分，毕竟业务每天都在变化，团队也每天都在变化，铁打的营盘流水的兵，谁都无法保证在一家公司呆一辈子。以上我分享了一些自己在多年工作中总结的招聘流程和渠道，相信大家也都有自己独特的经验。总之，作为技术领导者，需要在日常工作中不断总结经验，从而不断提升招聘成功率，提升团队效能。

作者简介

吴万港，前中恒云能源 CTO，TGO 鲲鹏会杭州分会服务委员 & 学习委员。10 多年的互联网行业从业经验，带领多个团队完成设计、研发了分布式 K/V，分布式数据库，日处理达到百 T 级别的分布式文件系统。8 年以上互联网行业大型的产品、技术团队的建设、团队发展、团队管理经验。对于从产品需求、技术实现等管理方面有全面的认识和实践经验，深入理解敏捷研发管理办法以及多年的实践经验。