数据请求利器 React Query
请移步知乎“前端之美”专栏 数据请求利器 React Query 查看全文。
请移步知乎“前端之美”专栏 数据请求利器 React Query 查看全文。
上篇文章,我们谈过了“Hire slow,fire fast”的前半句,今天我们聊下后半句,也即“fire fast”。
历经千辛万苦,新人终于到岗并开始适应新环境,大部分人都可以在两到三个月时间恢复战斗力,进而产出符合预期的价值。 但也有少数例外情况,由于种种原因,新人并没有达成预期。应该怎么处理这样的情况呢?
首先我们要界定这个人是不是达到了需要 fire 的标准,具体各团队可能都有些适合自身的判断。 我个人比较偏向的标准是:
如果新人只是因为对于当前技术栈不熟悉,或者因为外语、远程办公等工作环境的剧烈变化导致的不符合预期,那么我们是可以考虑多给些时间以进一步考察。 但如果新人是因为自身能力问题,譬如一个高级工程师无法产出合格的系统方案设计,或者总是用两倍甚至三倍以上的时间才能交付质量下乘的项目, 这类问题通常无法短时间内通过培训等助力方式快速提升
每个团队可能都有一些”红线“,譬如一个非常分布式的基于信任构建的团队里,非常依赖高度自驱来推进各项目,如果新人无法自律,划水严重, 如果在管理者进行警告督促后仍无有效改正的话,可以认定存在原则性问题。类似的红线问题还有不诚信、泄露公司机密牟利等等
其实第二点只是第一点的一种特例,本质上第一点这一标准就够了。
我曾亲眼见证过这样一个事情:
一个内部工具团队,因为业务增长太快压力山大,某个时间点 lead 在招聘方面做出了妥协,放水招进来一个看起来还凑合的工程师。 过了一小段时间,团队里其他人慢慢开始离职。有几个是我非常熟悉的伙伴,平时跟他们沟通不少,大家普遍的一些感触是:我怎么和这样的人一起工作。 再后来,团队雪崩式解散,部门领导不得不抽调其他资源维系业务运转。
有一次我也跟原来的 lead 闲聊,当谈到为什么当初招那个人的时候,他坦言:业务太多了,内部服务开发又不招人喜欢,没办法。
这些年来,随着团队管理经验的逐步积累,我越来越意识到师傅曾经教给我们的那句话的重要性:“Hire slow,fire fast”。今天我们就先聊一下前半句:Hire slow。
请移步知乎“前端之美”专栏 前端中的 Functional Reactive Programming(二)- 进阶版 AutoComplete 查看全文。
2018 年一段真实的对话:
几天后:
后来小 A 入职后,成长速度的确非常非常好,业余爱好也是一个没落下,说是事业爱好双丰收也不为过。 类似的“话术”后面我也用过几次,在候选人的几个选项比较接近时,成功率还是蛮高的。
请移步知乎“前端之美”专栏 前端中的 Functional Reactive Programming 查看全文。
今天有一位候选人问我:“你作为团队负责人,最重要的工作是什么?”,坦白来说,我自己并没有很深刻地思考过这个问题。脱口而出的答案是:招人,招足够优秀的人。
这时,我看到候选人深以为然地点了点头,似乎是非常认可我这由衷的答复。考虑到他也十足优秀,既然得到了肯定,那我不妨继续沿着这个思路畅想下,谈谈招聘驱动的组织建设。
在我们这个工程师行业,虽然很多人声称自己是码畜,只是外表光鲜地干着搬砖的体力活。不过纵观最近 20 多年互联网的飞速发展,诚如 Paul Graham 所言,真正意义上的工程师,或者黑客,实际上是最具有可放大性和可测量性的工种之一。当你的代码跑在成百上千台机器上为百万千万甚至以亿计的用户服务时,毫无疑问你的价值也得到了巨大程度的放大。
进一步,优秀的工程师和普通的工程师的差距就像太阳和灯泡一样大,虽然都能发光发热,但是数量级不一样。
基于此,我粗俗地以为,工程师组织建设的核心就是招人,招足够优秀的人:
请移步知乎“前端之美”专栏 React Hooks 原理剖析 查看全文。
请移步知乎“跬步千里”专栏 “觉醒年代”有感 查看全文。
请移步知乎“前端之美”专栏 TypeScript 进阶 查看全文。