查看: 5639|回复: 9
收起左侧

[职场感言] 【职场分享】新人如何打基础

    |只看干货
本楼: 👍   100% (27)
 
 
0% (0)   👎
全局: 👍   98% (551)
 
 
1% (6)    👎

注册一亩三分地论坛,查看更多干货!

您需要 登录 才可以下载或查看附件。没有帐号?注册账号

x
在科技公司工作四年半,我从一个新人成长为一个资深工程师,一路上有很多贵人相助,我自己也带了不少新人。有一些工作的感想,会在接下来的几篇博客里跟大家分享一下。这是我的博客

下面是第一篇,新人如何打基础。
. Χ
. 1point3acres.com



新人刚开始工作,特别是new grad和junior,最重要的是打基础,熟悉组里的工作,了解技术,提高自己的工程能力。通过加入公司前一两个月跟组里人的1on1、standup等会议,识别组里有实力靠谱且愿意带新人的老人,在一些比较成熟且roadmap清晰的项目开始练手,提升自己的技术能力。

一开始如果可以选,最好能跟着组里的技术大牛做项目。我工作刚开始学java,看了教程之后,就问组里的一个大牛是否能shadow他写code。我看他写,时不时问他点问题,这样一个session下来我能学到很多java的实际应用,耳濡目染best engineering practice,学习熟练使用git、IDE、和公司的一些工具。最重要的是,大牛选的项目或者大牛被安排做的项目,一般都是优先级非常高且目的明确的好项目。新人一开始工作在好项目上加上自己的名字,建立自己的reputation,非常重要。很多时候,大牛之所以是大牛,是因为他们活好手快。有时候跟大牛在一个项目上,大牛可能干了90%的活,作为新人的你只干了10%。只要大牛不在意就行,毕竟大牛手把手教你可能还不如他自己干得快。工作中,手把手教的情况基本不可能,师傅领进门,能从大牛那里学到多少还是得看你自己。大牛愿意分给新人一点缝缝补补的小活,我能干好不出错就是最大的贡献。. 1point3acres

如果没有大牛带呢?可以找个小牛,比如组里靠谱的同事。如果新人勤劳自学、积极发问、人善嘴甜,同事一般都会愿意帮带。如果新人自视甚高、不coachable、不善用google/stackoverflow,那估计就很难找到人带了。除了组里的老人,还可以跟老板说想找资深的人做自己的mentor。mentor可以选择的范围就不只限于本组了,有些公司有全公司的mentorship项目,匹配不同经验的员工。主动寻求职业规划、业务、专业上的帮助和指导,是新人能够快速成熟的好品质。

有的new grad一进组就想单挑新项目,我如果是他们的mentor会建议他们先做已有的项目,过段时间再搞新项目,但如果我不是他们的mentor或者他们不过问我的意见,我就只能祝福。有些项目一看就不靠谱,要么就是过于ambitious,要么就是大饼,要么就是research属性太重,上线可能太小。产品组不是科研组,做的项目最终还是要上线的。之前有一个“线下模拟模型评估”的项目,我一开始就觉得项目太复杂,很难做出有效的结果,就算做出来了结果,也未必跟线上的情况一致,还得做线上-线下的相关性分析。这一套下来,没个一两年,基本难有实质的产品进展。项目期间虽然可以做各种research性质的分享交流、demo,但没上线就没impact。我跟老板说我觉得这个项目过于强调线下分析,上线时间不明,但老板想做,新人有激情,我也不能拦着,这项目就给了新人,我主动去了另一个偏向infra的项目。最后那个项目无疾而终,我的项目顺利交付,眼光还可以。

有些项目是老板出于私心想探索的方向,老人觉得是坑不想做,新人容易被忽悠。我刚开始工作的时候,老板跟我1on1的时候问我想不想搞“知识图谱”,研究一下有没有可能把公司的table变成graph数据库。我一腔鸡血,觉得我要有自己的ownership,开拓新业务,吭哧吭哧地搞了几个月,期间还拉组里的一个senior帮我参谋,搞了好几个demo和prototype,甚至联系了知识图谱和数据库的相关从业人员,最后我的结论是,知识图谱对于我们公司业务没什么帮助,各种graph数据库没有现有的sql有用,但老板不认同我的结论,愣是让我接着做,还怀疑我的研究不够深入,对我的能力表示质疑。后来,在senior的帮助和公司其他更高优先级的业务压力下,知识图谱的项目被中断,我去做了另一个更成熟的项目。

不是说产品组不能做research项目,也不是说不能挑战新项目。但新人,特别是new grad,缺乏业务直觉,对项目的难度和所需时间很难有合理的估计,难以预估项目的impact,甚至还没摸清公司和组里的政治氛围,很可能事倍功半。新人在短时间内站稳脚的一个方法,就是出活,而跟着大牛做项目,能够高效地出活,还能从大牛那里学到很多技术之外的软技能,这个以后再聊。

评分

参与人数 24大米 +80 收起 理由
mambahang + 1 谢谢分享!
4055 + 1 赞一个
Ting- + 1 赞一个
lyuhao + 1 赞一个
微信用户_55eb132 + 1 赞一个

查看全部评分


上一篇:跳槽的时间?
下一篇:Amazon的兄弟们,role guideline更新了

本帖被以下淘专辑推荐:

  • · JOB|主题: 271, 订阅: 12
 楼主| ikazu 2022-9-21 11:44:57 | 显示全部楼层
本楼: 👍   100% (6)
 
 
0% (0)   👎
全局: 👍   98% (551)
 
 
1% (6)    👎
Alecia 发表于 2022-9-20 23:23
进去一个月onboard第二个月就开始独立写ticket了……我倒是想shadow但是感觉活已经干不完了(整个组)再不 ...
. Waral dи,
不同公司不同组的节奏不一样,如果是new grad或者对business logic不熟悉的junior engineer,第二个月就独立写ticket我会觉得过早,组里的onboard process不健全,甚至是老板的失职,但如果对业务熟悉或者是senior engineer,第二月就开始做ticket也不算特别早。我看我们组的new grad,一般可能要一个季度之后才开始独立写,senior的话大概也要onboard至少一个月。

活永远都干不完,特别是如果还understaff,一个人干两个人的活,更是干不完,不然怎么会有那么多996,都是活给逼的。作为新来的人,很难改变组里的工作分配和强度,如果你直接说觉得活太多,也容易给老板和同事留下抱怨和能力不行的印象。如果组里的氛围就是埋头赶进度,而不给你提供足够的支持和教学,可能从culture上来讲,并不适合长待。

我觉得你可以跟你老板提,或者自己找个mentor或者组里靠谱的senior进行每周30分钟到一小时的1on1,可以聊这些关于工作强度的问题,也可以把自己关于技术上的问题列出来,作为pairing session。你说的senior没有bandwidth我很能理解。毕竟senior是出活主力。但mentorship和knowledge sharing也是senior及其以上的IC必要的工作内容。我个人认为一个senior IC,拿出10%-20%的时间mentorship和knowledge sharing,不管是正式的mentorship,pairing,ad hoc Q&A,code walkthrough,帮新人review PR,指导新人提高code quality,还是各种知识分享,开会报告等等,而不是只干自己的ticket。 ..

如果一个senior IC的日常只是干活,没有时间做mentorship和knowledge sharing,我还是会觉得是老板的失职。
..
补充内容 (2022-09-21 11:54 +8:00):
补充一点吧,我看到你说“很多时候我都不好意思问组里的senior问题,除非实在自己查不出”。这个我一般会这样做。在入职前几个月,我会用“我刚加入我们组,还不了解XYZ,我的问题可能很silly/basic/naive/trivial”作为借口开场,主动摆明自己的无知和好学,随便问问题。后来发现,有些问题真的不是每个老人都知道,大家要么就take it for granted,要么就一知半解,不懂装懂的也大有人在,反而是打破砂锅问到底的新人很少见,不用不好意思。

当然,问问题也不能挤牙膏,最好是积攒了好几个问题,一次问完,每天都问别人10分钟问题,不如一周问一个小时的问题。

自己查,我一般给自己1-2天的时限,第一天如果没查出来,第二天我会在standup上说我有blocker,说会接着查,但是如果有人have any clue, please let me know。如果第二天还是没查出来,第三天我会在standup上说,i need help. i have done XYZ, but still not sure how to fix this。这个时候,靠谱的老板会问有没有人能帮你,你也可以私下问组里的senior,毕竟你的blocker现在老板已经知道了,也知道你尽力了。

补充内容 (2022-09-21 12:02 +8:00):. Waral dи,
说起这个“当时第一次要写infra的ticket实在是不会”,我想起我第一次写spark streaming job的一个ticket,基本就是copy paste另一个streaming job的code, 最后写是写出来了,但是不怎么理解这一步一步的transform都是干啥的。我读了tutorial,看了spark的documentation,还是觉得自己不懂,我跟大牛说,我code是写好了,但是感觉还是not comfortable with spark,大牛说,自己也不是understand every single line,他也是按照tutorial一边学一边写一边debug的,他可能还没有我懂这些transform,毕竟他的code是一年前写的,我是刚看完tutorial的。
.--
我后来逐渐意识到,不会不懂才是常态,适应自己经常不会不懂这个事实,但相信自己什么都能学会,都能搞懂,不管是看现有的code,还是看tutorial,还是看stackoverflow。实际工作中,没有什么技术问题是无解的,什么都能做出来,只看怎么trade off和prioritize

评分

参与人数 3大米 +68 收起 理由
charlesz_ + 1 赞一个
小民 + 1 给你点个赞!
admin + 66 很有用的信息!

查看全部评分

回复

使用道具 举报

 楼主| ikazu 2022-9-19 10:12:18 | 显示全部楼层
本楼: 👍   100% (3)
 
 
0% (0)   👎
全局: 👍   98% (551)
 
 
1% (6)    👎
xqfq 发表于 2022-9-18 22:01
谢谢楼主分享,超级有用!想问下你一开始shadow大牛写码的时候,是怎样平衡shadow和自己的delivery的呢?还 ...

循序渐进吧,最开始onboard期间没有自己的ticket只是shadow,也不需要deliver什么。之后可以一边shadow大牛一边逐渐自己own一个小的ticket,有问题去问大牛或者跟大牛pair,毕竟是在一个项目上,大牛一般都会帮忙。等自己觉得可以独立完成ticket,就不用shadow了。这个循序渐进的过程要时刻跟老板sync,如果你觉得需要更多时间ramp up,要跟老板说,如果老板觉得你该出活了但还没有ticket,就不好了。
回复

使用道具 举报

 楼主| ikazu 2022-9-26 21:32:15 | 显示全部楼层
本楼: 👍   100% (2)
 
 
0% (0)   👎
全局: 👍   98% (551)
 
 
1% (6)    👎
Alecia 发表于 2022-9-21 21:02
非常感谢这么详细的回复!尤其事听到你从senior engineer的角度说的想法给我很有用的参考。我是转码ng, ...

我有个朋友前几天跟我说了几句话我觉得很有帮助,就是,自己怎么舒服怎么来,做让自己最开心的选择和事情,不用太顾及别人。当然前提是不违法犯罪等等。很多时候,我们的顾忌和焦虑,都是因为外部因素的不确定。比如你问的"觉得不懂的太多反而不知道问什么,怎么问,从哪里开始。想问一下有没有什么general的建议,或者如果我从对方的cr问起的话可以接受吗?"。那我general的建议就是什么都别多想,先按照自己舒服的节奏问,在实践中逐渐摸清什么是自己和对方都舒服的节奏和方法,再进行调整,没有必要觉得自己一定要一开始就做对做好。人际交往中,就是得实践实际上手操作,跟别人对线,解决冲突,互相compromise。每次遇到新的人,这些步骤都得来一遍,社交大牛也不可能一天之内跟所有人相处得好。

评分

参与人数 1大米 +1 收起 理由
diana19951004 + 1 赞一个

查看全部评分

回复

使用道具 举报

xqfq 2022-9-19 10:01:55 来自APP | 显示全部楼层
本楼: 👍   0% (0)
 
 
0% (0)   👎
全局: 👍   91% (3605)
 
 
8% (316)    👎
谢谢楼主分享,超级有用!想问下你一开始shadow大牛写码的时候,是怎样平衡shadow和自己的delivery的呢?还是说刚开始一段时间只是shadow?
回复

使用道具 举报

地里匿名用户
匿名用户-0FA  | 添加认证 | 2022-9-20 09:13:25
本楼: 👍   0% (0)
 
 
100% (1)   👎
没有大牛没事,可以买小牛 (狗头)
回复

使用道具 举报

Alecia 2022-9-21 11:23:41 | 显示全部楼层
本楼: 👍   100% (2)
 
 
0% (0)   👎
全局: 👍   84% (55)
 
 
15% (10)    👎
本帖最后由 Alecia 于 2022-9-20 23:25 编辑

进去一个月onboard第二个月就开始独立写ticket了……我倒是想shadow但是感觉活已经干不完了(整个组)再不会也得硬着头皮上。很多时候我都不好意思问组里的senior问题,除非实在自己查不出。唯一一次最接近shadow的也是当时第一次要写infra的ticket实在是不会,然后让senior给我指点了一下关键的地方(结构什么的)。
有点迷茫,我觉得有的时候我只是make it work但你要问我它为什么这么写我也不是很明白道理。
补充一下,人家也确实会解答,只是一来我会觉得有点抱歉不敢问太细二来大家真的都没有bandwidth了尤其他们senior任务又更多。
回复

使用道具 举报

Alecia 2022-9-22 09:02:51 | 显示全部楼层
本楼: 👍   100% (1)
 
 
0% (0)   👎
全局: 👍   84% (55)
 
 
15% (10)    👎
ikazu 发表于 2022-9-20 23:44
不同公司不同组的节奏不一样,如果是new grad或者对business logic不熟悉的junior engineer,第二个月就 ...

非常感谢这么详细的回复!尤其事听到你从senior engineer的角度说的想法给我很有用的参考。我是转码ng,进组没到半年,感觉就是直接一脚给我踹下水自己扑腾,时不时被拉一下。还是有产出的(速度和senior是比不上),只是感觉特别累,尤其是精神上。不知道你所在的team是否也是如此,我们估算ticket比如做两天,可能senior做两天能做完,我在要是不熟的东西,五天可能都做不完;一个是本身可能有一些之前没预料的情况,二来对code base不熟。然后被manager问两天的task怎么还没做完,那是真的压力爆表。.--

ad hoc q&a 是有的,我虽然不好意思但要真卡住了(比如看ticket不理解我到底要干什么,或者就是写不出不会实现),我会心理建设“我不出活耽误整个组还是问吧”。不过你说的让我想到是不是应该和manager申请一个block的时间,一周一次问技术问题。这样想主要是觉得这样senior engineer花了时间也有recognition,可能会更能接受一点。不过怎么问问题也是一个学问:太宽泛(直接问请问这个business logic是什么)则容易得不到想要的答案,觉得不懂的太多反而不知道问什么,怎么问,从哪里开始。想问一下有没有什么general的建议,或者如果我从对方的cr问起的话可以接受吗?就是一周约一个时间集中问一下对方cr为什么这么写之类的。说来惭愧,很多时候senior写的cr我都看不明白(语法不熟,tech stack不熟,etc),看不出所以然也不好意思approve。
回复

使用道具 举报

Palizza2 2022-9-30 03:57:34 | 显示全部楼层
本楼: 👍   0% (0)
 
 
0% (0)   👎
全局: 👍   93% (15)
 
 
6% (1)    👎
太感谢楼主了 马住慢慢看
回复

使用道具 举报

小民 2022-9-30 10:54:53 | 显示全部楼层
本楼: 👍   0% (0)
 
 
0% (0)   👎
全局: 👍   93% (129)
 
 
6% (9)    👎
ikazu 发表于 2022-9-21 11:44. 1point 3 acres
不同公司不同组的节奏不一样,如果是new grad或者对business logic不熟悉的junior engineer,第二个月就 ...

case by case actionable items. very practical. 赞
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号
职场达人
  • ↑ 本版用于讨论职场各种干货话题,闲聊请去🔗聊聊或者🔗匿名版
  • ❌ 本版严禁水贴,引战,发布广告,拉群,贴个人联系方式,扣分无警告
  • ☑ 求职、面经等去 🔗北美求职和 🔗回国求职大区,刷题和学习请去 🔗终身学习大区
  • ☑ 请去专版发布 🔗内推, 🔗招聘信息,和讨论 🔗创业内容
  • ☑ PIP / DevList/ Need Support 等话题也已开设 🔗专版

本版积分规则

>
快速回复 返回顶部 返回列表