从junior混到staff的这些年，聊聊我踩过的坑和一些心得[顺带求米]
晋升
楼主在tech行业摸爬滚打也有些年头了，从junior一路升到现在的staff level。看到地里很多人问晋升的事儿，想着分享一下自己的经历，希望对大家有点帮助。先说明，我不在大厂，就是个普通中型公司，经验未必适用所有人。
Junior到Mid
刚开始工作的时候其实挺迷茫的，不知道该干啥。当时mentor跟我说，junior阶段就是打基础，把分配给你的任务保质保量完成就行。我那时候就是老老实实写代码，遇到不懂的就问，每次code review被指出问题就记下来下次别再犯。
这个阶段最大的误区就是以为写得快就是牛逼。其实不是的，写得对、写得maintainable才重要。我记得当时有个项目deadline很紧，我为了赶进度直接hardcode了一堆magic numbers，结果后面改需求的时候自己都看不懂了。senior看了直接让我重写，说这种代码merge进去就是给未来埋雷。那次教训挺深刻的。
从junior升到mid其实不难，只要你不是天天摸鱼，技术上过得去，基本熬个时间就能升。我当时大概用了一年多？主要就是把团队的codebase摸透了，能独立handle feature了。
Mid到Senior:
这一步才是真正的分水岭。很多人卡在mid好多年就是因为没搞清楚senior到底要什么。
技术好已经不够了，得开始有bigger picture。我当时犯的最大错误就是一直埋头写代码，manager跟我说你技术是够了，但是你得让别人看到你的影响力。什么意思呢？就是不能只做自己手上的活儿，得开始think beyond your own tasks。
给个具体例子吧。我们当时有个legacy payment system，已经run了好多年了，代码写得跟屎一样，但一直能work所以没人想碰。我那时候刚做mid，接手了一个在这个系统上加新feature的任务。我本来可以就照着原来的风格写，反正能跑就行。但我花了点时间研究了一下整个系统的架构，发现如果继续这么堆下去，迟早会出大问题。
我就写了个proposal，建议重构一部分核心逻辑，把新feature作为第一个用新架构的模块。manager一开始不太愿意，觉得时间紧。我就列了个清单，说现在tech debt已经到什么程度了，每次改动要花多少时间debug，如果现在不改以后cost只会更高。最后说服了他，我带着两个junior用了大概一个半月完成了重构和新feature。
这个项目之后，team里其他人开始慢慢把payment相关的问题都来问我，因为我对那块最熟。这就是我说的影响力，不是title给的，是你做出来别人自然就认可。
communication也很重要。你得让team知道你在干什么，为什么这么干。我以前就是闷头干活，结果升职的时候manager都不知道我做了啥。后来学会了定期update，写好design doc，在meeting上多发言，慢慢visibility就上来了。
从mid升到senior我花了快三年，主要是因为前两年方向不对，走了不少弯路。
Senior到Staff:
这一步真的难。很多人senior干得挺好就觉得staff是自然而然的事儿，其实完全不是。
Staff level要的是strategic thinking和cross-team influence。你不能只关心自己team的事儿了，得开始think about the whole organization。我一开始完全搞不懂这是啥意思，后来慢慢悟出来了。
举个例子。我们公司当时要做microservices migration，这是个multi-team的大项目，涉及backend、frontend、infra好几个team。我那时候刚升senior不久，主要负责backend这边。
一开始我只关心自己team怎么把service拆出来，后来发现根本行不通。因为frontend那边有他们的concerns，infra那边有他们的timeline，大家各说各的，根本协调不起来。我就主动站出来，说我来organize一个cross-team的working group，定期sync进度，discuss blockers。
这个过程里我学到最多的是怎么balance different stakeholders的需求。比如frontend想要某个API design，但infra说这样实现起来performance会有问题。我得去understand双方的constraints，然后propose一个compromise solution。有时候真的很frustrating，因为你说服了这边那边又有意见，但这就是staff level要做的事情。
项目最后是成功了，但过程中我basically成了这个initiative的technical lead，虽然我title还只是senior。这个experience后来成为我升staff最重要的evidence。
还有一个点是你得能influence without authority。说白了就是你得让别人心甘情愿听你的，而不是靠title压人。我记得有次跟另一个team的tech lead有disagreement，关于某个shared library应该怎么设计。他是principal，按理说应该他说了算。但我觉得他的方案有scalability问题，就约了个coffee chat，摆数据给他看，讨论了好几个alternatives。最后他接受了我的建议，还主动在all-hands上credit我。
这种soft skills真的需要时间积累。关键是要build trust，让大家觉得你说的make sense，你是genuinely care about做对的事情而不是搞政治。
这一步我用了三年多，其实还算快的，因为公司刚好有个opening，timing比较好。
一些零碎的心得
别太care title。我见过很多人为了升职搞得心态都崩了，天天盯着别人啥时候升的。其实你做到了那个level，title早晚会来的。反过来，光有title没有能力，迟早会exposed。
找对mentor很重要。我每个阶段基本都有个比我高一两级的人带着，他们的perspective真的很有帮助。不一定是公司assign的mentor，可以是别的team的，甚至别的公司的。
主动要feedback。别等performance review才知道自己哪里不行。我现在基本每个月都会问manager我哪里可以做得更好，early feedback比year-end surprise强太多了。
写好brag doc。这个是我后来才学会的，就是定期记录自己做了啥，impact是什么。升职的时候你得有concrete examples，不能光说我很努力。我一般会记录：做了什么project，解决了什么问题，impact是什么（比如reduce了多少latency，save了多少cost），谁可以作证。最后就是patience吧。晋升这事儿急不来的，与其焦虑不如踏实提升自己，该来的总会来。
差不多就这些，欢迎大家讨论交流。最近在考虑换工作，想看看别的公司staff面试都问啥，求大米解锁面经！
Junior到Mid
刚开始工作的时候其实挺迷茫的，不知道该干啥。当时mentor跟我说，junior阶段就是打基础，把分配给你的任务保质保量完成就行。我那时候就是老老实实写代码，遇到不懂的就问，每次code review被指出问题就记下来下次别再犯。
这个阶段最大的误区就是以为写得快就是牛逼。其实不是的，写得对、写得maintainable才重要。我记得当时有个项目deadline很紧，我为了赶进度直接hardcode了一堆magic numbers，结果后面改需求的时候自己都看不懂了。senior看了直接让我重写，说这种代码merge进去就是给未来埋雷。那次教训挺深刻的。
从junior升到mid其实不难，只要你不是天天摸鱼，技术上过得去，基本熬个时间就能升。我当时大概用了一年多？主要就是把团队的codebase摸透了，能独立handle feature了。
Mid到Senior:
这一步才是真正的分水岭。很多人卡在mid好多年就是因为没搞清楚senior到底要什么。
技术好已经不够了，得开始有bigger picture。我当时犯的最大错误就是一直埋头写代码，manager跟我说你技术是够了，但是你得让别人看到你的影响力。什么意思呢？就是不能只做自己手上的活儿，得开始think beyond your own tasks。
给个具体例子吧。我们当时有个legacy payment system，已经run了好多年了，代码写得跟屎一样，但一直能work所以没人想碰。我那时候刚做mid，接手了一个在这个系统上加新feature的任务。我本来可以就照着原来的风格写，反正能跑就行。但我花了点时间研究了一下整个系统的架构，发现如果继续这么堆下去，迟早会出大问题。
我就写了个proposal，建议重构一部分核心逻辑，把新feature作为第一个用新架构的模块。manager一开始不太愿意，觉得时间紧。我就列了个清单，说现在tech debt已经到什么程度了，每次改动要花多少时间debug，如果现在不改以后cost只会更高。最后说服了他，我带着两个junior用了大概一个半月完成了重构和新feature。
这个项目之后，team里其他人开始慢慢把payment相关的问题都来问我，因为我对那块最熟。这就是我说的影响力，不是title给的，是你做出来别人自然就认可。
communication也很重要。你得让team知道你在干什么，为什么这么干。我以前就是闷头干活，结果升职的时候manager都不知道我做了啥。后来学会了定期update，写好design doc，在meeting上多发言，慢慢visibility就上来了。
从mid升到senior我花了快三年，主要是因为前两年方向不对，走了不少弯路。
Senior到Staff:
这一步真的难。很多人senior干得挺好就觉得staff是自然而然的事儿，其实完全不是。
Staff level要的是strategic thinking和cross-team influence。你不能只关心自己team的事儿了，得开始think about the whole organization。我一开始完全搞不懂这是啥意思，后来慢慢悟出来了。
举个例子。我们公司当时要做microservices migration，这是个multi-team的大项目，涉及backend、frontend、infra好几个team。我那时候刚升senior不久，主要负责backend这边。
一开始我只关心自己team怎么把service拆出来，后来发现根本行不通。因为frontend那边有他们的concerns，infra那边有他们的timeline，大家各说各的，根本协调不起来。我就主动站出来，说我来organize一个cross-team的working group，定期sync进度，discuss blockers。
这个过程里我学到最多的是怎么balance different stakeholders的需求。比如frontend想要某个API design，但infra说这样实现起来performance会有问题。我得去understand双方的constraints，然后propose一个compromise solution。有时候真的很frustrating，因为你说服了这边那边又有意见，但这就是staff level要做的事情。
项目最后是成功了，但过程中我basically成了这个initiative的technical lead，虽然我title还只是senior。这个experience后来成为我升staff最重要的evidence。
还有一个点是你得能influence without authority。说白了就是你得让别人心甘情愿听你的，而不是靠title压人。我记得有次跟另一个team的tech lead有disagreement，关于某个shared library应该怎么设计。他是principal，按理说应该他说了算。但我觉得他的方案有scalability问题，就约了个coffee chat，摆数据给他看，讨论了好几个alternatives。最后他接受了我的建议，还主动在all-hands上credit我。
这种soft skills真的需要时间积累。关键是要build trust，让大家觉得你说的make sense，你是genuinely care about做对的事情而不是搞政治。
这一步我用了三年多，其实还算快的，因为公司刚好有个opening，timing比较好。
一些零碎的心得
别太care title。我见过很多人为了升职搞得心态都崩了，天天盯着别人啥时候升的。其实你做到了那个level，title早晚会来的。反过来，光有title没有能力，迟早会exposed。
找对mentor很重要。我每个阶段基本都有个比我高一两级的人带着，他们的perspective真的很有帮助。不一定是公司assign的mentor，可以是别的team的，甚至别的公司的。
主动要feedback。别等performance review才知道自己哪里不行。我现在基本每个月都会问manager我哪里可以做得更好，early feedback比year-end surprise强太多了。
写好brag doc。这个是我后来才学会的，就是定期记录自己做了啥，impact是什么。升职的时候你得有concrete examples，不能光说我很努力。我一般会记录：做了什么project，解决了什么问题，impact是什么（比如reduce了多少latency，save了多少cost），谁可以作证。最后就是patience吧。晋升这事儿急不来的，与其焦虑不如踏实提升自己，该来的总会来。
差不多就这些，欢迎大家讨论交流。最近在考虑换工作，想看看别的公司staff面试都问啥，求大米解锁面经！
已获得 211 大米
+2
共33条回复
✨ 您正在体验新版论坛UI
