new hire，你本可以有wlb

我是刚工作不久的ng。

看到隔壁狗家新来的L3的贴子，很多人说新人需要努力工作，只有熟悉组里的东西才能每天工作4-5小时。我并不以为然。我觉得，对于一个非卷组，新人每天认真工作4小时，对ramp up来说，本可以是够的。但是，这非常依赖于老人创造一个ramp up friendly的环境。

单开一贴，不针对任何人的特殊情况，只是根据我和我前后几个月来的新人的经历，写写对老人如何提升新人的onboarding体验的一个看法。

适用于帮助低级别ramp up。想到哪儿写到哪儿。

1. 最根本的，还是doc。一个详尽的onboarding doc绝对会让ramp up事半功倍（这就是我为什么说4小时够了）。我见过的大多数的onboarding doc，并不是从最基础的，你该如何一步步安装程序，基本语法的cheatsheet，如何获得组里的资源等等小事开始。还有一种错误，是给某个主题直接扔了个链接了事，那个链接指向了个几百页的tutorial。而没经验的新人很难预估到是什么block了他，很难快速找到能帮助他的人，会大大拖慢进度（根据我之前来的新人的体验）。
我来了之后，从最基础的地方写了个onboarding doc，既是给我自己的reference，也让后来的人方便。我跟新人说，有问题及时找我，也是帮助我改进doc（减轻他们怕打扰我的心理压力）。我的第一版当然有遗漏，下一个人碰到了问题也是及时找我。更重要的，是我能告诉他应该找谁，省得到处撞墙。我也发现了不是所有new hire的权限是一样的（原因不明），或者最近某个东西更新到下一个release了，针对性地在doc里补充了东西。他的ramp up比起我之前来的人，明显地障碍更少，进度更快。

2. 避免jargon。我发现，组里的doc，往往是一个工作N年的人跳槽了，给另一个工作N年的人接手时候写的。doc里会很多老人间默认的jargon，也会缺乏很多基本的config设置。

3. 在写doc时，有时会只着重于代码功能。新人还需要知道这个代码在哪里跑，如何提交，这个任务是否可以打断，如何debug。有的文档只是扔了个repo link，新人看代码完全懂代码在干什么，可不知道代码在什么平台上跑，如何调试，修改。

4. 别人的速度不能作为参考。有的人说他第一天/第一周就修bug了，不能适用于别人。比如我ml相关，有的只是改个command line的参数，当时就能改。有的要改feature，那就要动好几个模块。要改model arch，那输入格式输出格式训练步骤metric等等等等都要和model一起改，是个大工程。不知道sde是否类似，我觉得上手快慢也依赖于任务难度本身。

5. 发现新人ramp up慢时，老板不要指责，而是先要试图了解原因，是否新人ramp up遇到了障碍。

6. 之前有老人怼我，说他们自己有活儿，没时间给新人ramp up。请这种人有多远死多远。
你拿了更高的工资，有义务做更多的事情，更何况，只是把你做的东西写清楚而已，能造福组里很多很多新来的人。而且，即使我这个新来的写ramp up doc，平摊到每天，顶多也就半个小时，也持续不了一个月。

总之，磨刀不误砍柴工。

如果是，读书时候负责任地当过TA的人（如我），大概会更理解新人可能遇到的困难，知道如何用心教导新人。我觉得，很多码农是master毕业直接来的，技术可以，但不太会指导，造成了一些ramp up的障碍。












补充内容 (2022-07-13 04:47 +8:00):
我写这个，只是我对如何帮助新人ramp up的一些观点。如果你说，你不想/没精力帮新人，那这篇文章与你无关。

我带过组里三个新人，他们对我的评价都很好并且都给了peer bonus。在这说两句吧。

楼主的看法太理想化了，并不适合很多公司和组。

有些产品的发展和迭代很快，可能现在的设计和算法在几周甚至几天之后就有变化。每次有变化都写详细的文档，就会做很多无用功，大大拖慢进度。

有些组的领导很push，或者正处于比较赶时间的阶段，老人本来的活都快做不完了，要求他们写详尽文档和随时解答问题也太强人所难了。可以只写比较关键或者比较难的几个点，以及一周meet两三次集中回答问题。新人也需要分担一些压力，在meeting之间自己搜索和解决一些力所能及的问题。

基本语法的cheat sheet和安装软件的详细步骤？如果有当然好，尤其是和组里工作高度相关并且很难在外网上找到的知识。但是如果是外网可以搜到的，就不要强求了。在网上查找知识和解决问题是每个工程师必备的能力。如果公司比较大了，可以写一个全公司统一用的总结，小公司就算了吧。

老人工资高就有义务带新人？你知道有种现象叫工资倒挂吗？老人的工资比新人还低但是还要带新人，很不公平吧。就算没有倒挂，给力的老人自己做的事情也完全值得甚至远远超出这个工资差。带新人只不过是因为他们需要帮助，并不是说新人有什么需求都有义务满足。

老人应该把路全都铺好所以新人可以只工作四个小时，可以有WLB？Excuse me？一天工作四个小时才有WLB？八个小时不是正常的工作时间吗？如果组里需要老人做比较多的事情，新人要自己多花几个小时学习一下，工作满八个小时，这个要求很过分吗？

谢谢lz分享。我接下来要连续onboard四个新人，很希望能帮他们事半功倍地ramp up，但距离自己的ramp up已经六七年了，完全不知道新人的角度如何看待这个流程。接下来的几周我要好好写doc了，也希望我带的新人可以互相分享经验，把ramp up的心得写下来分享给后面的新人。

onboarding 不一定需要doc好呀

我一般带人，前几天或者第一周给一个删几行或者加几行的task，这样知道怎么acces code base，怎么test，怎么交代码
之后的一个月会做几个复杂一点（写好todo，比较简单，但是步骤多coverage大）的task，照顾到我们组的几个大块
最后开始查缺补漏，看哪里没有cover/或者新人想熟悉哪里。
一般experienced hire一个月上手，好的new grad 一个半月到两个月，慢的new grad 三个月。诚然我们没有gg那么复杂，但online service也没那么简单。

我不太鼓励直接看doc，我自己都不一定能看懂。一般让他们过一下doc大概知道什么名词，然后布置任务的时候说那些doc有用。带着task看doc效率高多了。
作为前gg员工，个人感觉最大的问题不是系统复杂，或者doc不好，而是mentor不上心，都是给一些他们不想做的边角活。活没意思倒是没问题，关键不适合new hire，没有循序渐进。我现在给的task都是专门给new hire设计的，有的甚至我自己先test一边。其实也没多花多少时间。

new grad/new hire刚来适量教育还是需要的，否则有的人来了天天跑errand办各种手续一个月啥都不会。我会很明确说一般ramp up 多久，好的new hire ramp up多久；我不鼓励加班，但是productivity很重要；现在是build trust 阶段，对你来说很重要；一旦做得好多鼓励。

find_advice 发表于 2022-7-12 17:37
至于我的mentor，他已经把我的新onboarding doc给全组新人用了。

补充内容 (2022-07-12 23:48 +8:00):

我是被admin置顶的高赞得主。

换个角度来看，manager和组里的老人的确应该想想如何做好onboarding process，来帮助新人尽快上手。这点，agree with you。你的onboarding doc被分享给全组新人用，你做的很好。

但作为新人，不能对此寄已希望。一个新人，如果没法客观衡量自己的产出是否达标，那在职场初期至少把8个小时的工作认真做足。站稳脚了，perf确认没问题了，再去躺平。

给楼主讲个故事。我毕业以后的前五年，一直在同一家公司，同一个组，写同一套代码。大概在那个组两年以后，我接手了公司某个new hire training class，每堂课50分钟，就讲我们组在公司技术栈的哪部分，你们写代码碰到什么方面的问题应该找我们，云云。每两三个月会讲一次，听众都是刚招进来不到一个月的。

第一次讲感觉好多东西讲啊好多细节要和他们解释，一个小时都讲不完，而且学生们好多乱七八糟的问题。然后每次讲快一点，每次讲快一点。。。到我工作第四年的时候我惊奇的发现，同一套ppt我20分钟就讲完了。听讲的没人问问题，大概是压根没听懂。然后我有在思考我哪儿可能没解释清楚，可是翻遍了整个ppt都觉得，这也是明摆着的那也是明摆着的，学过计算机的不都应该懂吗，我还啰里八嗦讲一遍，会不会反而不太尊重他们的智商？当我发现这个问题的时候，我马上把这个讲课的活儿扔给我们组一个毕业不到两年的小哥了，刚好我自己刚升职完😂

说这么多就是想让楼主了解一下有这么个东西叫curse of knowledge。真不是老人不耐心或者是不肯抽时间写documentation，而是离new hire状态越远越反而不知道怎么写，很难分清主次。你觉得每天抽半个小时写一下就好了吗，啊不我觉得写这个比写代码难多了。。。

倒是像楼主现在这样刚ramp up完没多久的，就最适合写新人documentation，毕竟学习中遇到的瓶颈还历历在目，也知道下一个人可能会踩什么坑。现在我们组想改进documentation也是叫了一帮去年入职的孩子们在整。。。

非常感谢lz的发言，我来说两句：
. check 1point3acres for more.带好新人实际上是一个很好的artifact，在一个发展健康的组内，你完善文档，给新人onboarding就是提高了全组的productivity，不是单做项目可以show impact（当然这是IC show impact最主要的形式）， 带新人也可以。
这些我都理解，然而理解和做到是两码事，做到和心甘情愿心情平衡地做到又是两码事。
比如说我们组，新人onboard几大需求，文档mentor exclusive environment这些组里也都有持续investment，所以本来新人onboarding应该是smooth的。但是人员前一阵子流失严重，在组内时长一年以上的就剩下俩人，然后manager三下五除二招了四个人，于是老板提议给新人们每周上课，帮助他们理解系统，讲课的任务自然就落在老人的（尤其是我们两个最老的）头上。
讲课的前两周我还感觉良好，上课前精心备课，看看已有的文档，再看看代码细节把自己对系统的了解查缺补漏，不断练习自己的slides技巧，讲课时发现可以回答大家的问题也很有成就感。
但是过了两周就渐渐吃不消了，首先备课很花时间，一次课大概讲一个service，几十个file的代码，大多数我都碰过，但是并不都能牢记在心，另外一些系统为什么设计现在这个样子，很多时候光看现在的logic无法理解，还要去看之前的文档，甚至blame之前的代码；讲完课后还会出现很多follow up question，其中一些很valid，另一些其实讨论价值有限，但是不得不挨个回答，还有的是说课上没听懂私下找我询问的，我没法拒绝只好带着看代码（因为有些逻辑确实很绕）。
如果光做这些我还能够心平气和，但是自己的三个project都要跟进，这些project的timeline也并不因为我要花时间答疑而可以放缓，很多事情不做就会block别人。所以经常会出现的情况就是：我本来打算趁没有会的半天写点代码，结果刚写一半，有个新人来'do you have a minute'，且问题不是扔一个文档过去可以回答的，于是一个小时的时间在peer program中度过了，加上我还有自己的mentee要带，通常只能故意work from home来获得focus time。
而且新人问的问题通常跟他们之前的工作学习背景有关，千奇百怪，就跟带小孩一样，有时候实在不耐烦，想要跟他们说：“你只要ramp up就好了，但是我还有十几个ticket要做的！”，”这个逻辑不是很清楚，我说的不是人话吗，为啥你还是没明白？”，“不好意思你的理解完全不对，为什么不自己去看看代码再来问我？”。甚至有一次一着急中文都憋出来了，给对面的老哥（非华人）吓了一跳——讲道理我跟人撕design，跟别组push back各种奇葩要求的时候也都是平心静气的，但是不知道为什么对于新人就无法自控。
正好看到这个帖子，不知道哪位大神能给我解解惑，是我的做法哪里不妥当还是心态哪里失衡了。。。

我让我底下的senior带新人的时候一般都是找要升职的人带的，因为leadership和team development是senior升职要考察的一个方面。暂时不在promotion track上的组员带新人尤其是ng纯粹义务劳动。一般的senior级别的engineer年终performance review上最重要的也是最先写的都是delivery，mentorship只是个加分项。

说实话，我作为EM，新人如果ramp up很慢又天天划水我会觉得你态度不好，没有self motivation。原来组小只有4、5个人的时候我会自己follow up看看能不能帮你做点什么，现在组太大了没时间1:1 coach，只能大概的了解一下情况，最多给这个人换个mentor。senior带不好新人是他leadership的问题，但staff以下leadership对performance毫无影响，所以不是升职senior根本没什么动力去带新人。

lz你作为ng肯定是希望有人带给你铺好路，但实际上ng带的好不好对大多数senior毫无影响。对senior来说mentorship只是leadership的一个dp，对ng来说这100%会影响老板对他的印象和他以后的发展，双方从来都不是对等的关系。所以你应该调整好心态，入职的时候还是要多努力，tech stack搞熟了再考虑怎么划水

不超过8小时都可以算有wlb吧…
非要觉得工作5-8小时在卷你那只能夸你是工人英雄

iresss 发表于 2022-7-12 08:21
不超过8小时都可以算有wlb吧…
非要觉得工作5-8小时在卷你那只能夸你是工人英雄

8小时乱撞，不如4小时高效。

lz写了这么多，无非是想说：如果别人铺好了路，原本需要8个小时的工作，可以在4个小时做完。

这道理没错，问题是有几个这样的“桃花源”？即使是meta这种规模的公司，很多人抱怨全是屎坑，其他公司能好多少？

no，公司老人们没给你铺好路是业界常态；铺好了是你幸运；路没铺好你就躺平，那是你没有判断力。

匿名用户 发表于 2022-7-12 08:30
lz写了这么多，无非是想说：如果别人铺好了路，原本需要8个小时的工作，可以在4个小时做完。

这道理没错 ...

lz写了这么多，无非是想说：如果别人铺好了路

更重要的，是如何“铺好路”吧，my2cents

补充内容 (2022-07-12 23:31 +8:00):
或者，路没铺好，就自己去铺路，然后让老板知道，我在铺路。

“磨刀不误砍柴功”，楼主说的太对了。但是你有没有想过，“磨刀”是你的mentor在干完本职工作之后，付出的额外的时间和精力，而他节省的是你的“砍柴功”，他每天工作8小时，再额外花三小时给你准备保姆级的onboarding 服务，为了你的wlb （每天工作4小时）。建议你把这个提议给你的mentor看，看看他是不是夸你简直太聪明了，然后自己惭愧地低下了头。

其实换个角度，从manager的角度来讲，为新人铺好路是让一个新人快速出活的最佳方式。如果想快速培养新人，拉起一支队伍，主动为新人铺路是既能收获人心又能提高效率的。只可惜现在很多manager都不愿意做这些事，嘴炮ppt才是他们认为的最快的升职途径，而不是好好培养一支队伍

匿名用户 发表于 2022-7-12 08:33
“磨刀不误砍柴功”，楼主说的太对了。但是你有没有想过，“磨刀”是你的mentor在干完本职工作之后，付出的 ...

我说了，每天半个小时就行。而且是我这个新人，这种水平一边ramp up一边整理，额外的半个小时。每天工作7.5和8小时那么大区别吗？不写，每个新人搞不懂，ping他解决问题，就不用时间了吗？做mentor，做senior，自己弄了个东西，写明白不是他的职责吗？

已转ceo查看

匿名用户 发表于 2022-7-12 08:33
“磨刀不误砍柴功”，楼主说的太对了。但是你有没有想过，“磨刀”是你的mentor在干完本职工作之后，付出的 ...

至于我的mentor，他已经把我的新onboarding doc给全组新人用了。

补充内容 (2022-07-12 23:48 +8:00):
我当然不可以教育我的mentor怎么干，但我可以自己干啊，这不是白给的credit么，比调代码简单多了