为什么IT公司天天都在招人？很多程序员却找不到工作，理由扎心

互联网公司招聘是很重要的环节，互联网公司离职率普遍较高，传统企业离职率较低，所以对于公司招聘是很重要的环节，同样一句“很重要”我看到许多人理解其程度实际上大相径庭。在很多互联网公司，招聘被视为“最重要”的事情。这是令许多人不理解，甚至觉得不可思议的事情 ，这里的“许多人”也包括曾经的我。公司不开展业务吗？不管理员工吗？不和了解客户需求吗？这些事情哪个不比招聘重要呢？

中午吃饭的时候，同事老兔和我算了这么一笔账。估算非常之粗略，请勿以之作为任何有效依据，但是从大略上足以窥其端倪。

1、假如一个勤奋的中级程序员工程师，一年薪水 20w 的话，一年 365 天，大约有 52 周，扣掉双休日还有 365-52x2 = 261 天，加上法定假大概 10 天，休假大约 3 周，还有乱七八糟的病假、事假大约 10 天，也就是说，工作的时间只有 261-10-3x7-10=221 天，平均每个工作日的薪水是 200k/221≈905元，那么按照多数人朝九晚五且扣除一小时午休等原因的一小时以后，每天工作 7 小时，时薪大约是905/7=129元。

2、另一方面，考虑 Google、FB、Microsoft、Amazon 之类的知名互联网公司，粗略地如下假定：onsite 都要经过 5 轮左右的面试，每轮大约 1 小时，外加最少 1 小时左右的电话面试（有些电话面试要两轮），而且电话面试的录取比例大概是 1/3，所以每一个 onsite 认为绑定了三轮电话面试，debrief meeting 讨论面试情况半小时，以及面试官的面试准备，和面试完毕后 report 的撰写半小时后，那么光是工程师就要投入 5+3x1+0.5+0.5=9 小时，按照时薪算就要耽误掉129元*9=1161元，再加上 HR 和 recruiter 等其他人的工作投入，场地费、有时会有的餐旅费等等，onsite 一个人的成本平均在1300元往上。

3、即便这样的投入后，多数结果当然都是没有录用的，即便给了 offer，还有多家公司在 offer 上的竞争。很多公司的 onsite 的录取率都在 40% 左右，而最终入职率的百分比就要掉到 20% 以下。所以这个数还需要调整：1300/0.2 = 6500。花了那么多钱，才能录用一个工程师。

这个计算已经触目惊心了，招人的成本看起来是非常巨大的，而事实上，这个数会更大。考虑其他的开销，它就更扎眼了。比如和招聘机构合作的年费，比如招聘校园行宣讲的费用，所以，就如同我一位老朋友程序员所说，“工程师是很贵的”。

可是，我要说的是，这只是“小钱”。

什么！？

为什么？

因为对于许多互联网公司来说， 招聘这个环节，和后面的环节比起来，性价比太高了，投入相对更值得 。在招聘上省钱，很有可能，会让之后的团队运作付出多得多的代价，还不一定能识别并挽回造成的损失。

也许你会猜，我大概会举招聘的 bar 太低，入职员工技术能力不足，拖累团队的例子。诚然，这样的例子很典型、很普遍，但是这方面绝大多数团队和招聘流程都会关注，并无新意可言。而且，对于一个技术或者业务能力不足的人，无论在决策还是实现层面，由于缺少技术或者业务影响力，往往造成的负面影响比较有限 ，换言之，更可怕的人，可能是技术或者业务足够强，但是种种原因不契合团队，严重影响工作输出的那些，而这，足以带来超出想象的破坏力。

经历过这样一个例子：

有一位黑客界的牛人，费了九牛二虎之力把他招到团队，结果入职以后工作能力并不达标，或者说，并不契合他所擅长的内容和方式，结果搞出一大堆问题不说，deliver 也不合格，同事不得不跟在他后面给他收拾残局，给他的代码修 bug、打补丁，他本人更是非常痛苦。最后他自己和公司双方都选择“解脱”，他入职不到半年就离职了。

其实这个问题就出在招聘，他至少在某些方面得到过业界的证明，他拥有顶尖的某些能力。可是无论是工作方法上，还是向往的工作内容和团队的契合程度，都不符合要求。

一个团队的包容力固然重要，可它依然是有限的。太多的鸡汤文推崇招募牛人，可随便什么牛人放到一起工作就可以做得很好，这只是一厢情愿，它只在书本上出现 。

再比如这个更可怕的例子：

有一种可怕的开会，特别是那些十几个人的团队，一开就是一个小时的会议，结果变成了神仙大会，扯的东西看似工作相关，实则都是一些遥远而不甚关联的话题。每一次开会就是十几个小时工时的浪费。按照上面粗略的时薪计算，开销可观。

什么情况下会这样？

招来不干实事，却口若悬河的人。更可怕的是这样的人混成了团队骨干。于是带着一帮人天天在会议上侃大山。

招聘就是这样，招得好，公司和团队长期受益，招得不好，长期危害。

于是有人说，招聘小投入，等到入职以后再来衡量绩效不就好了吗？绩效不好就裁掉，或者其它方式中止合同。经历实战才能出英雄，不是吗？

理儿是这个理儿，可这个逻辑存在几个致命伤：

入职后的绩效衡量，等到得到结果的时候，羊已亡，无论补牢是否已晚。有很多后果是很难弥补的。这个绩效衡量，又怎样保证尽可能客观而有效？一个“最能混”的工程师，也许能够有十种百种奇葩的办法拿到好的绩效，却没有为团队带来真正等效的价值。这里还忽视了中止合同的代价 。虽说合同都是 at will 的，法律上上午说离职，下午就可以滚蛋的。除非涉及种族歧视等法律底线，极少有公司这样做，如果因为绩效原因，通常这样的合同终止，公司都会给员工以数个月的补救或缓冲时间。原因很简单，一个习惯于中止合同的公司，名声就臭了，谁还愿意来？

……

更重要的，也是我要提醒的是，我们不能总把眼光放在“不损害团队利益”这样低层次的层面，而应该盯着怎样提升团队能力这个层面。

招聘就像是唯一的一个损失极小的影响产品方方面面的环节，如果不努力招聘更好的人，怎样要求最后发布的产品变得更好？

这也是 Amazon 最初定下的，要求招的人，“比团队中 50% 以上的人更好”这个说辞的由来。

若说起招聘环节在整个公司运作中的位置，它其实和软件工程里的项目流程同理，越早发现 bug 代价越小 。

从招聘，到入职，到团队建设，到项目输出，整个流程下来，总要在一个环节上面付出很大的代价。如果招聘做不好，那么倒霉的就是后面的环节。这也像软件工程的项目流程一样，如果设计做不好，那么糟糕的设计带来糟糕的版本质量，就要靠大量的测试来弥补，多数还补不过来；而如果测试也草草了事，那就要靠疯狂的 bug fixing 和打 patch 来弥补，还几乎肯定会造成大得多的后果。越往后，代价越大，效果也越差。

因此，把问题解决得越早越好。把工程质量这个 bar 抬高，抬得越早越好，不如就从筛选工程师开始。

招聘到的工程师不只是优秀，还符合团队需要，那么在后面的流程中，就可以减少很多投入。

比如，不需要花钱请人监督工程师的工作，因为工程师又自我鞭策的能力；比如，不需要大量的团队建设活动，因为工作态度和方法上彼此都有大致相似的观点；再比如，不需要招许多测试来保证质量，因为良好的设计和实现阶段的开发期测试已经足够好；比如，不需要再维护优化环节投入很多专职人员，是因为良好的稳定性、易用性和可扩展性配合好用的工具使得开发团队自身就可以搞定这些事情。

最后，回到招聘本身。面试是双向的，一个草草了事的招聘几乎意味着一家草草了事的公司。想知道未来的团队氛围是不是适合自己，那么看看是不是和面试的人聊得来；想知道公司的技术实力如何，那就看看招聘过程反映出来的技术怎样；想知道入职以后身边的人会不会优秀而且契合，那就看看来面试你的面试官是不是优秀，招聘是不是严格且谨慎吧。