1.人才要自己去找、去抢
从团队的角度出发,Leader“主动出击、寻找合适人选”的观念符合逻辑,你既然是团队的一号位,自然最应该了解团队现状,以及团队需要的人选。与此同时,找到合适的人对你的影响最大而非 HR,因为你才是对团队“生老病死”、进人和离人最直接的决策者和结果的影响者,你既要为招来的人负责,也要靠其去优化并改变团队的现状。另外,通常 HR 服务于多个团队,未必是 1v1 针对你团队的,如果单纯依赖 HR 找人,最终的结果可能不会符合你的期望。
出于这几点原因,我认为招聘是技术 Leader 的责任而不是 HR 的。并且你要清楚招人和找人的区别:找人是一个主动寻找的动作,招人是一个被动等待的状态。
既然已经明确了责任的主体,接下来的重点就是怎么找到人,我结合自己的经验,总结了三个步骤:定需求找人选、面试甄别、做决定。
2.招人不等于盲目加人
业务快速发展必然会让系统日渐庞大,需求不断增加,研发的压力也会随之加大,在这种情况下,为了缓解压力我们自然而然地会选择最容易的解决方案:“业务需求增多 + 人手太少 = 招人”。
看起来,招人似乎能解决研发领域的一切问题,如果不能就再多招点儿。这背后反映出一个问题:很多时候我们并不知道自己要解决什么问题,也不知道真正要找什么样的人,只是感觉加人就能解决问题。
而这就衍生出一个辩证的问题:加人能不能解决问题?
在 07 讲中,我也提到了这一点,在我看来,如果从系统开发层面出发,单纯加人未必能解决实际问题,系统开发这项工作并不是标准化生产的流水线作业,一味地加人并不能提升整体效率。
如果一个系统在最初设计时没有进行很好的规划,导致实现的复杂度过高、模块间结构模糊,“高耦合低内聚”,之后是很难通过清晰的分工调整让生产力最大化的,即使后期发现进度不理想,想加人也未必能发挥效果,原因有这样几点。
-
时间上赶不及: 新加入的成员需要花费大量时间理解业务和系统,并不是人员到位之后就会立刻发挥作用,这个周期可能是几天也可能是一两周。
-
拖慢整体进度: 新成员加入势必要老人花费时间与精力帮助他们熟悉系统,老人反而增加了任务,影响整体进度。
-
质量上有风险: 新加入的成员在短时间了解业务和系统基本情况后,为了赶进度就会尽快上手,但是因为系统复杂度很高,会有更大概率交付Bug,后期要么是风险增加,要么为了覆盖这些风险要额外多做很多事,最终看进展可能和不加人时所差无几。
那加人一定是错的吗?并不是,我反对的不是加人,而是无目的、无脑、下意识地加人。大部分管理者都希望自己的团队规模越大越好,能管理更多的人,能 hold 住更多的事情,从而证明自己的价值。那选择加人是很常见的选择,不过你要做的是加对人,具体可以参考这几个步骤:
-
明确业务目标;
-
盘点团队需求;
-
做出岗位设计;
-
提炼岗位要求。
总而言之一句话: 找人并不等于盲目加人(招人),先明确“找人”动作背后的 WHY,也就是为什么要加人?加人要解决什么问题,以及你加的人是不是能解决这个问题?
为了明确这一点,你需要先梳理业务目标与现状,在此基础上盘点团队的情况与需求。
举个例子,假如我负责订单系统年底业务上的目标是订单量实现翻倍,而业务上为了达到翻倍的目标会开拓很多新业务,比如增加商品的种类、丰富营销的玩法,那么这些新业务就会对系统有新的业务需求,同时也会对系统稳定性有要求。
明确了业务目标与现状趋势后,你要梳理并思考当前团队的人员情况是否够支持接下来的发展需要。
假设目前的团队能 hold 住业务上功能的需求,但是对高并发的场景没有太大把握,你怕在遇到“618”或者“双十一”等大促活动时,系统出现棘手乃至无法解决的问题。那么此时你就需要有过相关经验的同学,专门解决数据存储、性能、高并发等痛点问题,此时你就可以根据业务目标和梳理出的团队现状做出岗位设计,然后再与 HR一起形成岗位 JD。
强调一点:在形成岗位 JD 时,你要做好假设(脑海里要有画面感),假设已经有人符合 JD 的要求,那么他加入团队之后,大家是怎么配合的?他如何展开工作?团队的运转是否能严丝合缝?这些都可以提前考虑下,这也涉及面试甄别的内容(比如需要他有较强的沟通能力,我后面会讲)。
做好上述准备工作后,你要和 HR 确定招聘的渠道:内推、猎头、招聘网站。从过往的经验和普遍认知来看,内推肯定是最优的选择。为了调动同学们内推的热情,你可以采取一些措施,比如组织团队内部的“内推大赛”,在某一个季度发动同学们内推,内推人数排名前三的人选获得一定的内部激励,内推成功后公司一般也会有奖励(我记得在 2019 年,饿了么技术团队内推冠军的奖励就是除了内推奖金外,两张全国任意飞的机票) 。
闻味道、问事实、看能力
当你通过简历筛选到心仪的候选人后,就会进入“面试甄别”环节。各个公司的面试环节往往大同小异,只不过常规现象是:公司越大,面试轮次会越多、周期越长。那么怎么做好面试甄别呢?我的推荐是“面试习惯”与“面试技巧”二者缺一不可,先有好习惯再有技巧。
在我看来,好的面试习惯主要有这样几点。
-
面试前看简历:有的面试官在面试开始后,先用几分钟浏览简历,然后就开始各种提问。这其实缺少了深入思考的环节,只是在根据简历问问题,而没有结合岗位需要问问题。不管是出于对职位的重视,还是更彻底的人员考察,我都建议你在面试开始前花 10 分钟“细看简历”,思考其中你感兴趣的内容,结合岗位的需要,简单设计下面试题。
-
面试中更多倾听:不管是处于目的性还是基本的尊重,不要随意打断候选人的发言和思路,学会倾听 > 不断提问,只有他说的多你才能考察到更多。
-
面试后速写评价:我经常在面试完要去参加其他的会议,当第二天 HR 问我的面试评价时,当时的感受已经忘得差不多了。所以你在面试完候选人时,要立刻记录下面试评价(这时,你的主观意识会更强,感受更强烈),同时也加快面试反馈的时间。
面试技巧主要有:闻味道、问事实、看能力。三者没有孰轻孰重、先后顺序,往往是融合在一起的。不过按照我的习惯,侧重点在于“问事实——看能力——闻味道”。
-
问事实
问事实其实有一套拿来即用的框架 STAR:情境(Situation)、任务(Task)、行动(Action)、结果(Result)。也就是:在什么样的情境下?候选人的任务是什么?采取的行动是怎样的?结果如何?其中的侧重点在于 A ,考察候选人具体的行动,以及为什么这么做。
通常你可以顺着候选人的一些表述来追问,比如:
-
候选人“在某个项目中,我做了高并发的设计。”
-
我“什么样高并发的设计,是什么场景?”
-
候选人“在XX场景下,有短时间超过1K QPS的请求,我通过缓存和消息队列来处理。”
-
我“缓存或者消息队列如果出故障了怎么办?会将系统整体拖垮吗?”
-
候选人“缓存出故障了可能会,消息队列没关系,业务上能接受一定延迟,系统整体应该不会垮”
-
我“缓存出问题了,数据库不会被击穿吗?为什么整体不会垮?”
-
候选人“有并发限制,数据库可能会 Hang 住,这个场景与其他场景是隔离的,整体系统不会一起雪崩。”
-
我“缓存在这里变成了强依赖,这样实现的好坏和解决方案你是怎么考虑的?”
-
……
你可以结合候选人的回答,不断从对话中深挖一些内容,从而进一步判断候选人的实际经历。
“问事实”并不会侧重考察业务或者技术,也并不是完全对能力的深挖,更重要的是:看候选人所说的内容他是否真正做过,以及他的思考过程。
有候选人为了突出亮点,只负责了某一模块却说负责了整个项目,那么在问事实中,一旦你深挖候选人的落地思路,很容易证明哪些项目是他真正做过,哪些是他根本没做。
-
看能力
看能力主要是看候选人的技术能力(比如编程语言、高并发、高可用等)与业务能力(比如候选人做过电商,那就看他对电商领域的理解深度与广度),你可以把看能力与问事实相结合。
类似 “redis 怎么实现接口缓存?” 并不是一个好问题,候选人在面试前可能都会做足准备,应对一些纯粹的技术问题,所以这样的问题可能是“背出来”的,并不代表他有解决这类问题的能力。要把纯技术问题与业务场景相结合起来问题,比如“你之前做个那个XX系统,如果用户量增加 10 倍会有什么问题,怎么解决,如果增加 100 倍呢?”。以具体的业务场景,考察候选人对这个问题的理解程度。
-
闻味道
不管是饿了么还是阿里,经常说“面试候选人一定要闻闻他的味道”。直白点儿说,就是看候选人与你、与你们团队是否合得来,你们是不是同路人,是否可以一起共事,会不会为团队发展一起努力?如果味道不同,很可能对团队造成不好的影响,拿不到好的结果。
那怎么闻呢?交流中的感觉占据很大比重,其次是一些回答的倾向,比如有些候选人不管你问什么都会先反驳下你说的可能,那么有可能你会觉得他比较傲或者沟通困难,但是在他看来自己并没有什么问题,所以闻味道是一个比较主观的事儿,和找女朋友类似,并不存在客观标准。
对不同的 Leader 来说,倾向的味道也会不同,就我自己而言,我更喜欢“皮实”“自省”“乐观”这样几个关键词:候选人是否玻璃心?是否足够自省和乐观?你要清楚自己倾向的“味道”是什么。
宁缺毋滥,守住底线
在多轮面试中,你的面试只是其中的一环,在面试结束之后,还要综合候选人的表现,做出决定(是否发放 Offer 以及发怎样的 Offer)。
这一步往往是最纠结的环节,如果候选人足够优秀,你可以不用考虑直接通过,反之,如果候选人明显不符合要求,你也很容易 Pass 掉,但大多数情况下,你遇到的总是模棱两可的情景,一边觉得候选人不太合适但是也不是不能用,一边业务压力大非常需要人,那么这时你要考虑什么呢?有两个关键点可供你思考:
-
关注未来;
-
宁缺毋滥。
先明确招聘是为了未来的,远水解不了近渴,你重点关注的应该是候选人来了之后团队会有何改变,是不是对未来的团队有更好的作用?可以问自己这样 4 个问题。
-
他是否有能力的同时还有潜力?比如很强的发展欲望或学习能力?
-
他身上是否有特质足够吸引你?比如让你觉得当他未来会比你更优秀?
-
你是希望与他这样的人一起共事的?
-
当他加入团队后,能否将团队氛围激活,形成鲶鱼效应?
除了关注未来,还要宁缺毋滥,守住底线,你同样需要考虑这样 2 点。
-
能力水平超过团队 50% 的人以上:确保团队越来越强,而不是越来越弱,有的 Leader会觉得候选人比团队最差的两个人好就可以了,但这样一来,随着时间拉长,你的团队会越来越差。
-
内心是否非常犹豫?犹豫往往意味着“不想要 > 想要”,如果是迫于业务压力不得不加人,我建议你还是不要勉强,因为有可能本来解决业务压力就可以的问题演变成还要额外解决不适合的新员工的问题。
讲到这儿,与“找到人”有关的理论知识就全部讲完了,接下来,让我们简单模拟一个场景:假设你现在需要为团队招聘一个技术专家,解决下半年业务发展中高并发、高可用的技术问题,现在有几个候选人,你会把 offer 给谁?
-
张三: 加入公司意愿很强烈,人很踏实,虽然技术深度不够(受限于过往经历),但是跟业务匹配度很高,来了就能上手干活发挥作用。
-
李四: 技术过硬,面试时也一直在追求技术的深度,人也比较踏实,但在沟通中他表示希望做的内容有足够高的技术挑战,而你团队现阶段的业务对他来说没有太大的技术难度。
-
王五: 在技术和业务上契合团队现状,但在沟通中你发现,他过于自信,不够自谦。
-
陈六: 跟业务很匹配,也很有冲劲,离职原因在于公司架构调整,认为在原公司缺少发展空间。
-
孙七: 以寻找机会为主,货比三家。
分析:我会把 offer 发给李四,技术挑战是一个追求,可以与团队现状动态平衡 。张三只解决现状,没有未来;王五 不符合自谦的味道,太过自信不仅未来成长容易受限,团队协作也可能有问题;陈六很常规,如果没有李四,陈六也可以考虑,但陈六存在一个问题:因为公司组织架构调整而离开,那他能否适应新公司的组织结构调整?孙七很明显不用考虑,因为如果孙七 单纯货比三家的话,你很难在团队未来发展上与其达成共识。