从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面试都问啥，求大米解锁面经！

英勇的麦克斯 发表于 2025-11-22 22:19:53
感谢分享，尤其是senior到staff那一段感觉总结的真的很好，观察工作中接触到的跨过这一步的，除了一位技术真的非常强以至于不可或缺的之外，其他人都是能够很好

这是一个很好的问题。我只在刚开始intern的时候紧张过一小段时间，后来很快就好了。
转折点是好几次开会，几个director level的人也在。我发现他们提的很多问题其实我心里也在想。那一刻突然意识到，技术出身的高level的人想的问题也很接地气，没有想象中那么高不可攀，这个发现挺帮助我建立自信的。
另外就是，每次交流其实都是围绕一个具体的project。当你在这个project上投入了足够多的时间，你就是那个最懂的人。面对自己熟悉的东西，自然就不会怎么胆怯了。
最后一点是我不怕被问倒。如果某个细节我没考虑到，我会直接说”这个我确实没想到，让我回去研究一下”，然后offline认真想办法。大部分人其实都appreciate这种诚实的态度。
说到底，大家都是来解决问题的，不是来比谁更牛逼的。想通这点就没什么好紧张的了。

楼主说的挺好的，不过我觉得staff的地方还是弱了一点，cross team driving 是staff的一个很重要的部分，但是不是核心要求，楼主说的是Junior staff，或者更接近 senior senior。staff跟senior最重要的区别是own metrics，这个是senior及以下一般都不需要的。own metrics是什么意思呢？就是对某个metrics负责，如果年底达不到目标，会有penalty。至于为什么达不到目标，不重要，除非是整个经济环境变差，如果是因为别的组block你，那么对不起，倒霉的还是你自己。而且这个metrics要有一定的难度和impact，要跟staff的scope match，一般都需要挖新坑，需要Drive multiple team collaborate，需要leads buy in，需要其他team buy in，然后才是execution。每一步都很难。所以我理解为什么空降staff很难生存，不熟悉context，不熟悉sister team的人，没有合作关系和trust，怎么能在几个月时间内ramp up 并且perform as staff呢？想想就可怕。

个人经验感觉：其实还是看老板。和老板能臭味相投，就会比较顺。和老板看不上眼，努力都是徒劳。

感谢分享，尤其是senior到staff那一段感觉总结的真的很好，观察工作中接触到的跨过这一步的，除了一位技术真的非常强以至于不可或缺的之外，其他人都是能够很好的有cross-team vision。已加米~

顺便也想问一个切身的问题：想请教一下LZ有没有遇到过对于跟+2以上级别的人聊天的时候的紧张感，以及解决类似问题的心得呢？感觉跟+2以上的人聊天的时候就会莫名的有些紧张，回想一下又没有什么明确的紧张的理由。

感谢分享！
不过title太谦虚，你肯定不是 “混”到staff的。

我感觉staff的活真的很累，不喜欢处理人际关系，是不是就得永远停在senior了

微信用户_0bdd7f5 发表于 2025-11-22 22:49:36
感谢分享！
不过title太谦虚，你肯定不是 “混”到staff的。
我感觉staff的活真的很累，不喜欢处理人际关系，是不是就得永远停在senior了

确实啊我感觉做士大夫折寿🥲🥲

感谢分享，也庆幸楼主遇到了好的组和通情达理的老板。

看到mid的经历我想起我曾经在狗家呆过的一个组。当时组里的一些测试框架library里面也有很多tech debt，代码质量差，严重影响了一个项目的进度。于是我就在群组里提出来说一定要重构这些library。当时群里有个组员也同意这点，我在和老板1:1也提过这点，可惜老板不以为然，还一直觉得我做的太慢，严重拖累了项目进度。后来实在忍不下去了我就换组了，但因为换组时间已经很接近评绩效时间了，所以当年的绩效还是旧老板负责，于是就顺理成章的成了low performancer 也就是MI，而且我还是Junior level。现在到了新组一年，目前还没看到迹象要被pip之类的。

那个时候如果能沟通更清楚点，或者准备一个 one pager阐述遇到的问题，也许情况会有些好转，当然老板的态度也很重要。如果老板不同意那似乎也没太多办法。

我就主动站出来，说我来organize一个cross-team的working group

请问怎么才让别人听你，假设我senior拉一群senior来一个working group，到最后meeting没人说话，email/msg不回，一问三不知。很多事绕过你找你老板。
最近在做类似的事，感觉就大伙儿各干各的，累死人了，真的是写代码更舒服。

感谢楼主分享。看得出来楼主能力强，比如代码基本功、表达能力、vision、头脑灵活，这些都是非常重要并且可以在职场上被人赏识的能力。大家都喜欢你。
另外其实升职还有一个非常非常重要的点就是你的项目。junior到mid不说了，基本上呆一两年不出大问题，老板想给你升且公司有headcount，给个由头可以升。但后面senior和staff挺看重项目的。有没有visibility、能不能有机会和多方人员的合作、项目受不受“上面”重视都是关键点。

匿名用户 发表于 2025-11-22 23:23:26
感谢分享，也庆幸楼主遇到了好的组和通情达理的老板。

看到mid的经历我想起我曾经在狗家呆过的一个组。当时组里的一些测试框架library里面也有很多tec

不用太反省自己。其实可能不是你的沟通问题，而是环境/老板/上级的问题。有些tech debt大家知道很重要，但与单位上级priority不符且需要一级一级沟通（他们很多人什么都不懂，需要educate，有些即使讲过很多遍也不get或者忘了）。
之所以这么说是因为我见过太多了。上级每三年换一次，完全没有consistent vision。这样的initiative我们之前提过很多次，同样的一个问题每次都因为上级其他的要求被打断从来没有完成超过一半。有一次终于获得一级一级的支持到cto，但每两年整个leadership全换，现在组里的priority早就变了，不能说面目全非，但已严重偏离主线

感谢分享！想问问每个阶段的mentor 是怎么寻找的呢？
我现在的公司没有mentoring 的氛围，至少是我没有感觉到，所以起步有点困难。尝试过约隔壁组manager coffee chat, 那一次是成功的，但是基于几个考虑没有继续：
1.隔壁组跟我组日常合作不少，利益相关，我担心我老板有顾虑；
2.对方完全是花时间为我解忧，而作为mentee我没有对应提供给他的价值，我找不到对方愿意长期 mentor我的动机。
3.换人再来的话，陌生manager 我不认识，认识的manager 又多少有组间合作，利益相关。在人选这一命题上很犯难。

想问问楼主是怎么看待这些问题的？