亚麻五年，从SDE到SDM的一些随笔

作者@地里匿名用户C2MAH发布在一亩三分地

欢迎大家点击左下角“阅读原文”到原帖与作者交流讨论哦！

楼主毕业后第一份工作就是亚麻，在Payments下面的某个组。后来因为种种原因一直没有换组或者跳槽，机缘巧合一直在一个组里干了五年。幸运的是这个组的culture还不错，manager也很supportive，算是亚麻里的一股清流了吧。按规矩，先报一下timeline吧。

2019/07-2020/12: SDEI
2020/12-2022/12: SDEII
2022/01-now: SDEIII转SDM

简单介绍下，Payments工作，最大的特点就是累。因为Payments的特殊性，oncall load很大，sev-2很多，所以ops以及ops improvement是平时工作中不小的一个部分。当然亚麻payments在过去几年也一直有一些新项目在开发，所以development的部分也不少。

在这几年中，我也见过了来来往往的很多SDE和SDM，从中总结了一些个人和职场发展的经验，回馈给地里，抛砖引玉。

沟通和表达能力很重要

很多人喜欢以技术论成败，总是从技术角度考虑职业发展以及个人发展的进程。我的经验是，技术很重要，但不是充分必要条件。以我看来，技术能力决定了职业的下限，但沟通和表达能力决定了职业的上限。我个人感觉，这是我们很多华人容易忽视的一点。我观察了很多升职很快或者级别很高的人，他们的技术有强有弱，但沟通能力都很优秀。很多时候，项目有没有manager支持，方案能不能说服全组采用，往往不是因为技术问题，而是因为沟通问题。很多时候，如果能精简到位，快速的描述清楚一个问题的不同solution，pros/cons，会更能earn trust。因为leadership往往很忙，时间有限。所以要想获得support，必须要很快地沟通好问题和解决方案。在这个过程中，就会能得到越来越多的信任，获得越来越大的scope。这里我推荐大家除了面试之外，平时的工作中也可以多用STAR format，来培养自己表达技术问题和方案的能力。

职场新人要多提问，多记录，多反馈

很多时候，对于职场新人来说，最大的red flag不是不会，也不是问题太多，而是没有独立钻研同时快速反馈问题的能力。对于leader来说，在ddl之前交付commitment是最重要的。很多职场新人倾向于认为问问题会显得自己无知，因此害怕问问题，浪费了很多时间。但其实，对于新人来说，迅速证明自己的方法，是能够完成自己给出的timeline和commitment。在这个过程中，如果有blocker，迅速反馈是最好的方法。有些公司内部的工具，技术，流程之类的，职场新人很难快速上手，这种时候，向mentor或者manager及时提问就是很好的方法。但提问也需要注意方法，那就是请大家分享相关的文档或资料为主，这样会给人留下一种你是有independent工作和研究能力的人。自己offline研究完如果有具体的问题，再针对提问。尽量不要提出很模糊的问题，譬如“这段代码跑不了，你能帮我看看吗？”或者“这个工具我不太会用，你能给我讲讲吗？”这一类的。正确的例子可以是”这个tool我试过了，出现了XXX error，我在文档里找到要用YYY方法解决，但我试过之后出现了ZZZ error。请问你可以给我一些next step guidance或者相关的文档，代码，例子吗？“。需要注意的是，问过一次的问题，要尽量记住，做笔记或者offline多看。反复问同一种问题才是一个red flag。

要抓住visibility的机会

由于国人谦虚的性格，不少时候会觉得visibilty是一种负担，最后成为了职场老黄牛，干了很多活但manager不重视。在职场中恰恰相反，干活很重要，但visibility更重要。这一点上印度人做的就很好。负责了重要的design，有高层manager参与的demo或者presentation，一定要敢于争取这样的机会，为自己争取reputation。刚开始的时候肯定会很难受，因为会干很多在SDE看来没有生产力的活动，比如写文档，写report，做ppt或者demo video。但这些工作能够为你将来争取更大的scope和reputation，从而助力职场发展。慢慢的熟悉了这个过程之后，就容易多了。同时在这些presentation中，要敢于show off你的impact，比如降低了多少latency，减少了多少manual effort，覆盖了百分之多少的traffic之类的。可以适当夸大，比如根据潜在有多少用户，平均每个用户有多少优化来估算一个总的impact，而不必等到真的全部实现再去report。

要在组里至少一个方面dive deep，成为SME

在一个组待很久的优点之一，是能够有机会在这个组的技术和业务里dive deep。标志之一就是你成为了关于这个方面的go-to person。manager或者同事有相关的问题或者design，都会请你review。这是一种很重要的earn trust的方式，能够极大证明你的学习和技术能力。而有了这个reputation，也会让manager相信你是能够放心委托重要task的人。

以上都是想到哪里写到哪里，可能逻辑比较零散。回头想到了，再慢慢更新。

发帖后，针对大家的提问，楼主又进行了针对性解答：‍‍

wlb怎么样？

wlb这个问题，大家见仁见智。我觉得取决于各自的追求。有的人觉得一天八到十小时一周五天是可以接受的wlb。有的人觉得只有微软那样才叫有wlb，所以还是要看个人的preference。Payments的话，只能说wlb堪堪可以接受。这个需要自己主动把握项目的节奏，提前预估好可以接受的ETA，不要自己给自己再加压。

在oncall上花了大把时间要怎么stand out，感觉提升职的时候主要还是看平时的项目，除非真的是救火很多次？

在oncall上花太多时间，我觉得主要说明组里的oncall机制有问题。我观察整个部门里的oncall大概是每两个月左右轮到一次。所以oncall带来的randomization还可以接受。另外一方面，对于manager来说，oncall太多其实也不是什么好事，会影响manager在自己的skip面前的reputation，manager也是想保住自己位置的。所以如果你和manager关系尚可，可以寻找机会提出自己的看法和改进的建议。

另外如果oncall牵扯了你太多的精力，在一个culture正常的组里应该可以和manager 1on1沟通表达自己的想法。当然表达想法也要注意方式，就是首先表达对这个工作的肯定和对oncall重要性的肯定，比如I definitely think it's very important to keep opsEx of the team, which makes my work of solving XXX issue critical to the team success. However, I would also like to look for opportunities of growing my skill in YYY. I was wondering if I could start exploring some new areas after I deliver current XXX task for the team. 这个时候如果你有对于改进oncall的建议，也可以趁机提出：During my work on XXX, I noticed that there are some gaps in the process, which I think would be beneficial for the team to fix. I would like to take this job and define XXX process, YYY SOP for the team to follow and improve the experience.

但有一点很关键，职场新人千万不要急于提出意见。至少要在组里观察几个月，摸清各种业务流程逻辑，earn trust之后再说。不然很容易让manager觉得你不靠谱。

升职标准方面，我觉得除了company level guidance，每个组的leadership可能也有自己的喜好。所以oncall是否重要，或者什么样的项目是很重要的，只能靠平时多观察，比如其他人升职有什么data point之类的（promotion email里应该会有）。当然最好的情况还是，既有dev work/design，又有opsEx。

「要抓住visibility的机会」这句话的前提是，组里有这种机会。如何知道哪些有visibility，为什么manager会给你visibility？.

这一点确实正确。正如大家熟知的”能力之外，资本为零“的段子，升职的关键，还是在于组里能提供什么样的平台。lz很幸运在一个有项目的组里。所以如果整个组都没有visibility，那确实只能考虑转组跳槽了。

那么如何知道哪些有visibility呢？就看平时各种high level review meeting的主题是什么，看看平时组里的senior在讨论什么，主动旁听一些重要的review meeting，或者多留意组里或者部门里的launch email，重要邮件thread，来了解组里的最新进展。如果有机会的话，问问manager自己组的3Y/5Y vision是什么，具体有什么milestone。如果manager自己都不知道，那确实说明没有好机会了。如果有具体的plan和milestone的话，就可以和manager沟通逐渐从小到大take一些task来慢慢进入核心项目。

你作为入职的SDE I，当时组里不可能没有SDE2和SDE3吧？那么，别人为什么没抓住机会，为什么manager会让你有机会接触visibility呢？更关键的是，如果组里已经有SDE3了，manager如何愿意再升一个SDE3？

这也是一个好问题。同时也是earn trust的延伸。组里可能有老的SDE2，SDE3。但其实对于一个有抱负的manager来说，想往上走，就必须找到新的人promote。所以manager本身是有这个需求的。既然有需求，那么我们要做的就是成为让manager能最简单满足这个需求的人。所以从新人开始，逐渐就要通过在manager面前展现能帮助解决urgent task，能够提出关键建议这样的能力。刚开始，可以是很小的建议，然后慢慢成为越来越多方向的SME，慢慢扩展你能帮manager解忧的scope。这样就形成了一个正反馈，trust越多，能接到的task越重要，task越重要，deliver之后能获得的trust就更多。

我们的 org culture 是 no individual heroes，所以会让所有人轮着做所有事。manager 会有意给人换 ownership。这样就没有机会来 deep dive 某一个方面。遇到这种情况如何破？

这种情况下，我觉得个人可能需要付出更多一些的努力。就是说，你在每一次遇到新的task，可以多花一些功夫，dive deep这个方向的service，techology，争取每干一个活，都对这个方面有深入的理解，而不仅仅只是deliver之后就不管了。这样的话，轮到几次不同的task之后，你可能会对你们org方方面面的技术也业务都有很深的理解，反而成为了你的优势，能够很容易在遇到major feature的时候think big。manager固然可以有no individual hero的culture，但是总有有task有需要hero的时候。而且需要有能think big且dive deep的hero救场的时候，就是你可以获得trust和reputation的机会了。而且基于你之前积累的对于多方面的业务和技术的理解，你也可以在review meeting或者team discussion有机会多发表一些比较深入而且有big picture的comment，这样慢慢积累下来，你会在manager面前树立很靠谱的形象，也就能为你争取更大的scope了。

总而言之，不管怎么样，只要这个组有需要做high impact task的需求，那么就一定需要一个对本组甚至upstream/downstream system都有广泛深入理解的SDE来把控项目方向。你要做的就是争取成为这个人选。