Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

招聘有多重要?

Posted on 07/15/201801/30/2020 by 四火

A red vintage “for hire” sign招聘有多重要?

很重要……

嗯,废话!

说 “很重要” 的确是废话,而没有比较就没有差异,同样一句 “很重要” 我看到许多人理解其程度实际上大相径庭。在很多互联网公司,招聘被视为 “最重要” 的事情。这是令许多人不理解,甚至觉得不可思议的事情,这里的 “许多人” 也包括曾经的我。公司不开展业务吗?不管理员工吗?不和了解客户需求吗?这些事情哪个不比招聘重要呢?

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

  1. 假如一个勤奋的中级程序员工程师,一年薪水 200K 的话,一年 365 天,大约有 52 周,扣掉双休日还有 365-52*2 = 261 天,加上法定假大概 10 天,休假大约 3 周,还有乱七八糟的病假、事假大约 10 天,也就是说,工作的时间只有 261-10-3*7-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+3*1+0.5+0.5=9 小时,按照时薪算就要耽误掉 $129*9=$1161,再加上 HR 和 recruiter 等其他人的工作投入,场地费、有时会有的餐旅费等等,onsite 一个人的成本平均在 $1300 往上。
  3. 即便这样的投入后,多数结果当然都是没有录用的,即便给了 offer,还有多家公司在 offer 上的竞争。很多公司的 onsite 的录取率都在 40% 左右,而最终入职率的百分比就要掉到 20% 以下。所以这个数还需要调整:$1300/0.2 = $6500。花了那么多钱,才能录用一个工程师。
  4. 这个计算已经触目惊心了,招人的成本看起来是非常巨大的,而事实上,这个数会更大。考虑其他的开销,它就更扎眼了。比如和招聘机构合作的年费,比如招聘校园行宣讲的费用,比如工程师内推的 bonus(普通工程师通常在 $1000 ~ $2000)……

所以,就如同我一位老朋友程序员所说,“工程师是很贵的”。

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

什么!?

为什么?

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

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

经历过这样一个例子:

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

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

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

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

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

什么情况下会这样?

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

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

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

理儿是这个理儿,可这个逻辑存在几个致命伤:

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

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

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

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

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

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

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

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

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

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 我们到底要怎样招程序员?
  2. 北航招聘会的几个感触
  3. 写在华中科技大学招聘结束之时
  4. Algorithm In Interview
  5. 近期面试求职的经历和感受

5 thoughts on “招聘有多重要?”

  1. 米扑博客 says:
    09/03/2019 at 4:51 PM

    写得很赞 我们公司招聘会参考 多谢分享~

    Reply
  2. 吴中勤 says:
    01/08/2019 at 1:19 AM

    请教大神有没有招聘的一些方法和心得,最近需要招一些靠谱的人

    Reply
  3. 潘力 says:
    07/20/2018 at 3:45 PM

    火哥,想请教一个问题,关于学习英语方面的,我现在是边上边学习英语,报了培训班。本人英语基础很差,做开发 3 年多了,现在的想法就是想学好英语看看能不能去外企。想问下你当时学习英语有效的方法是什么?

    Reply
    1. 四火 says:
      07/21/2018 at 7:52 AM

      右上角的站内搜索 “学英语”

      Reply
  4. russell says:
    07/17/2018 at 10:38 PM

    美国工资水平这么高了啊
    中级程序员一年都有 200K 了

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme