三年AWS工作职场总结

刚才在版上发了一个贴（https://www.1point3acres.com/bbs/thread-834705-2-1.html），得到了很多大佬的指点，其中不少肺腑之言，让我感激之余有了更多的感动。所以我想也在这里发一个分享贴，分享一下在亚麻三年的经历，希望可以抛砖引玉，在帮助一些朋友的同时也鼓励更多的人来分享。

背景
我本人不是学CS出身，这也是这几年一直有一些自己看不起自己的原因。好在自己学习能力不差，本科又有一些编程的短暂经历，平时用点点滴滴的时间准备了一下，所以也顺利地在2018年底，进入了亚麻当SDE L5。值得一提的是，亚麻的面试对于我这样提起自己的工作总是有很多话讲的人来说，真是不难，每个LP都可以瞬间想起很多个工作的经历来support。当时拿到offer的时候根本就没有好好negotiate， 随随便便就接了。进了组后同组的一个L5说，我是近16个月以来招来的第一个L5，我当时就暗暗叫苦，肯定是被low ball了。但是自己选的工作，流着泪也要干出声色才跳，不是吗?

下马威
亚麻给我的第一个下马威就是，进组两个礼拜，顶头上司，就是当时的HM，一个跟我聊得很好很好的白人L6 manager转组当IC去了。组织上从别的组调来一个南亚裔L5的manager来接手。我当时差点就骂娘了，这是什么世道，这个HM是我决定来这个组的一个很重要的原因之一，结果我自己还没onboard好，他就跑了。这从一个侧面也说明了当时的组里的情况有多糟糕。

我是如何搬砖的
我认为Onboard结束后到第一次performance review是一个蜜月期，要动用所有的good will来得到所有有用的信息来达到自己建立威信的目的。我就是这么做的。从第二个月开始接手一个项目开始，有问题就找当时的L5, L6问，等到第三第四个月的时候我已经成为这个项目里最懂的人了。在第六个月的时候等我做的非常大的refactoring和upgrade上线的时候，项目整体性能提高50%，资源使用降低了60% (一个月大概能省半个million的钱），sev2基本降低了80%。从这一刻开始，我在组里面说话开始比较有分量，各种会议里manager主动要我发表意见，其实有些问题我也不是很懂，但是从组里得到的反馈里我也发现其实别人也没懂到哪里去。算是矮子里拔高子吧。
我觉得这个过程中我有几点做得比较好：
- 充分发挥自己自学能力强的优势，看代码看design不懂的时候就问，问懂了就写wiki。最后这个项目的所有最新的 wiki基本都是我写的。
- 充分发挥蜜月期非常多的空闲时间（别人基本不会也问你问题，因为你是新人嘛）把一个项目里里外外的代码都看明白了，以后谁在组里问关于这个项目的问题时，你回答得又快又好，久而久之，你就是公认的expert，基本上说话的分量就上来了。
- 在会议上要敢讲敢问，但是要注意自己说话的分量和质量，切记不能讲车轱辘话，绕来绕去。不确定的时候用疑问句，别人回答你了，就要礼貌地感谢； 非常确定的时候要用assertive的陈述句，不用 i think, i guess, I am thinking之类的，直接就说 This is something I have done before and here is how we should do it。当然这些就是小技巧了，慢慢就都有体会了。


（我是刚注册几天的新人，一点大米都没有，都回贴都有限制，更别说看别人的包裹之类的。如果您觉得这些东西对您有一些些帮助，就打赏一个吧，谢谢！）

接下来我会写下面几个章节，慢慢补充

与各个类型的同事、上级打交道

扩大自己的影响力

如何满足SDE L6 升职的各个条件

补充内容 (2021-12-31 10:08 +08:00):
事与愿违，我的那个旧项目成功了，顶住了接下来半年的流量，因此新项目搁浅了半年，半年之内那个L6见升L7无望走了，L5见升L6无望也走了。然后半年之后，我和另一个L5一起说服上面，旧的项目能撑一年半载，但也不是长久之际，所以还是要一起做新项目，所以我和另一个L5合作开始做新的项目。在这个过程中，我积攒到了一些之前都没有意识到的如各位同事打交道的经验

- 组里任何冲突，归根到底就是power struggle。我的这位合作者经常用他L5的头衔压其它的L4的SDE，揪着鸡毛蒜皮的小事堵着code review就是不merge。这种时间我经常会走一个balanced approach，帮助双方找到一个都可以接受，也都有台阶下的方式。
- 不懂技术的manager尤其好面子。如果一个SDE不给manager面子，直接在全组员面前怼他，那即使你也同意你的同事，也千万不能火上烧油，一定要给大家都留些面子，找机会和台阶私下找到一个可以合作的点。久而久之，manager对你的信任就会更多。
- 一定要给能力强的人解决问题的时候多给一些credit，good job, very impressive之类的话挂在嘴边，同时鼓励他们speak up，engage到组里和各种讨论中来，帮助他们树立自己的creditibility。以后你要找他们帮助的时候他们会两肋插刀。没有人都能独立解决所有的挑战，比如一个很烦的问题，你调来调去调不出来，需要a pair of fresh eyes，你一叫他们，他们就来了，一起看，因为他知道最后问题解决了你会在会议里大大的夸他们。
- 我非常赞同amazon LP里面的好几条，今天我就谈谈ownership & bias for action这两条。我在这三年里有很多很多次，skip manager有急事找到我，要我对一个新的问题迅速找到解决方案，然后上线跑出来。这里面每一次我都快速解决了问题又快又好，让skip manager非常满意，也让很多sister team的L6了解到了我雷厉风行的做事风格。
- 跟比自己高一级以上的人汇报，沟通能力非常重要。简明扼要，每句话都不是废句而且都有另外三句话等着可以解决扩展；如果他们问起来，你也可以把问题解释得非常透彻。这个我也在实践中慢慢（也是偷偷地）学习各种native spearker是如何说的，特别是有一个L7的TPM，他跟L7, L8 L10说话真的是如沐春风。

补充内容 (2022-01-01 05:11 +8:00):
在亚麻逆行
亚麻的风评版上的朋友都是清楚的，那如何在这样的环境中逆行，make the most out of it 呢？我觉得有这么几个点：

- 针对亚麻最强的几点，你在业务上跟着几个大佬学习，争取学到精髓。上面提到了Metrics, Dashboard， Alarm，都是亚麻在云业务上面成绩不俗的法宝之一，另外亚麻对分布式计算，对各个region 的support的追求是raise the bar的一个体现，项目上线前的ORR，对出了问题后的COE总结都是非常强大的方法论。有些流程看起来很麻烦，但是做过了之后才会发现，这些对项目的成功，个人的成长真的是助推器。我在其中学到了很多东西。
- 公司文化。亚麻的Leadership Principles除了几条自相矛盾的（特别是frugal，对员工真的是非常frugal），是职场精髓。是与同事讨论问题，分析问题，解决两难的选择，做重大决择时非常有用的方法论。你运用得好了，小到能让你赢得组内的争论，成为某个initiative的带头人，大到让你在大组里面用各种LP力排众议，让各位领导认为你是真正的Amazonian。当然，你也要用批判的眼光去看这些LP，不要被洗脑。
- 坚决抵制不利于自己发展的文化。周末非oncall加了班，要在下周找机会补休，让大家觉得你是一个有原则的人，不会被PUA。重大问题上做了贡献，如果有人过来摘桃子，一定要写一个doc，名义上是把incident/problem solving的timeline写出来，实际上是把credit理清楚，下次做review的时候有依据。
- 写作能力。亚麻内部，特别是有Asian Amazonian 组织的一些writing kitchen，可以加入学习各位L7+的人是如何写一篇没有废话，深入浅出的technical paper的。这个写作能力是体现自己对某一个话题深入理解，解决口舌之争的法宝，运用的好了，你的每一篇narrative都会成为你的Manager, Skip Manager甚至再往上的领导跟其它组进行negotiation，争取资源的依据。写作能力在亚麻真的是重中之重。
- 定量能力。任何discussion, narrative都需要用数据来说话，把定性的论据用定量的metrics说出来，是一种能力。这些在亚麻尤其重要。平时在看代码的时候，不仅要关注业务代码，也要看很多Metrics是如何设计的，学习一些这种抽象能力。
- 从各种能力强的L6, L7身上学到给别人的项目做有价值的Critique的能力。这个我也一直在默默学习的过程中，我只能说这个能力真的是日积月累中沉淀下来的，我还没有资料给出太好的建议，只是提醒大家要注意这方面的学习。

补充内容 (2022-01-02 20:51 +8:00):
内部升L6各种drama

在我升L6的过程中，我被告知，亚麻内部升SDE L6需要有这么几条硬性要求。不知道这是普遍适用于所有org，还是就我被要求每条都符合。
- 解决难度大的问题。我的第一个项目成功上线算是符合这一点。
- 解决复杂度大的问题。我后来跟另一个L5一起带着两三个人开始重新做新的项目，最后发展成7个人的团队，成功productionize这个项目，deploy到所有的region。这算是符合了。
- 有设计一个项目到成功上线的完整的经历。由于第二条的这一个新的项目的design doc不是我写的（上面提到，是后来跑路了的L6, L5写的），即使最后上线的设计跟当时他们设计的样子比，我做了重大的改进， 这不被认为是一个完整的经验。我在这一点上被卡了整整一年。其实2020年底我的新的项目就成功上线了，但是一直到2021年年底我从头设计的另一个项目上线之后，我的设计能力才被promotion committee 认可。
- 有帮助别的 org 的团队解决问题的经验。也就是increased scope and influence。我这点上也是非常吃亏，我经常需要主动向别人的组毛遂自荐说我，谁谁谁，有做什么的经验，欢迎咨询。有的时候会直接跟skip manager说，我现在急需这样的经验，你帮我打打广告。然后终于在我skip的帮助下，得到某个非常大的一个external service组的邀请，帮他们做了一个新项目的review。所以这一点也终于满足了
- 需要有三个L6或L6+以上的推荐，并且不能是自己的直接上司或者skip manager。这点就比较蛋疼了。之前说过的L6跑了，我们组就我和另一个L5撑着，其他和我工作比较紧密的好多L6都离职去别的大厂拿大包了，等我要推荐的时候，好多L6+的人要么是我的直属上司，要么就是刚加入的对我的情况还不是特别了解的。所以我最后勉强找到了几个之前共事过但是没有深入了解的L6，把我的情况重新介绍了一下让他们写了推荐。

以上的几条虽然是亚麻的要求，但是各位在提升自己职场影响力的时候也可以用这个标准来要求自己，一步一步往上走。

和不同的同事上级打交道

.--(上头补充的时候少copy paste了一段，重发一次吧)

上面写到我的第一个项目就是组里更繁杂、最垃圾、sev2最多的项目，在我半夜啃代码 （ruby，简直就是天书，我发誓再也不写ruby了）修bug，各种调试的时候，你肯定会好奇我的那些L5, L6的同事都哪去了呢？原来他们正在讨论写一个新项目的设计文档，来replace这个项目。其实我后知后觉才知道他们当时谁也不碰这个屎山屎海的项目，把我招进来后就扔给了我，谁也不期望我能干出点啥来，就是想拖延时间，等他们把新项目做出来的时候他们L6升L7, L5升L6，皆大欢喜了。



事与愿违，我的那个旧项目成功了，顶住了接下来半年的流量，因此新项目搁浅了半年，半年之内那个L6见升L7无望走了，L5见升L6无望也走了。然后半年之后，我和另一个L5一起说服上面，旧的项目能撑一年半载，但也不是长久之际，所以还是要一起做新项目，所以我和另一个L5合作开始做新的项目。在这个过程中，我积攒到了一些之前都没有意识到的如各位同事打交道的经验

- 组里任何冲突，归根到底就是power struggle。我的这位合作者经常用他L5的头衔压其它的L4的SDE，揪着鸡毛蒜皮的小事堵着code review就是不merge。这种时间我经常会走一个balanced approach，帮助双方找到一个都可以接受，也都有台阶下的方式。
- 不懂技术的manager尤其好面子。如果一个SDE不给manager面子，直接在全组员面前怼他，那即使你也同意你的同事，也千万不能火上烧油，一定要给大家都留些面子，找机会和台阶私下找到一个可以合作的点。久而久之，manager对你的信任就会更多。
- 一定要给能力强的人解决问题的时候多给一些credit，good job, very impressive之类的话挂在嘴边，同时鼓励他们speak up，engage到组里和各种讨论中来，帮助他们树立自己的creditibility。以后你要找他们帮助的时候他们会两肋插刀。没有人都能独立解决所有的挑战，比如一个很烦的问题，你调来调去调不出来，需要a pair of fresh eyes，你一叫他们，他们就来了，一起看，因为他知道最后问题解决了你会在会议里大大的夸他们。
- 我非常赞同amazon LP里面的好几条，今天我就谈谈ownership & bias for action这两条。我在这三年里有很多很多次，skip manager有急事找到我，要我对一个新的问题迅速找到解决方案，然后上线跑出来。这里面每一次我都快速解决了问题又快又好，让skip manager非常满意，也让很多sister team的L6了解到了我雷厉风行的做事风格。
- 跟比自己高一级以上的人汇报，沟通能力非常重要。简明扼要，每句话都不是废句而且都有另外三句话等着可以解决扩展；如果他们问起来，你也可以把问题解释得非常透彻。这个我也在实践中慢慢（也是偷偷地）学习各种native spearker是如何说的，特别是有一个L7的TPM，他跟L7, L8 L10说话真的是如沐春风。

(收到了好多朋友的大米，大受鼓励，那我继续发）

在亚麻逆行
亚麻的风评版上的朋友都是清楚的，那如何在这样的环境中逆行，make the most out of it 呢？我觉得有这么几个点：

• 针对亚麻最强的几点，你在业务上跟着几个大佬学习，争取学到精髓。上面提到了Metrics, Dashboard, Alarm，都是亚麻在云业务上面成绩不俗的法宝之一，另外亚麻对分布式计算，对各个region 的support的追求是raise the bar的一个体现，项目上线前的ORR，对出了问题后的COE总结都是非常强大的方法论。这些网上具体的资料应该都有，我就不再多说了。我想说的是，有些流程看起来很麻烦，但是做过了之后才会发现，这些对项目的成功，个人的成长真的是助推器。我在其中学到了很多东西。
  

• 公司文化。亚麻的Leadership Principles除了几条自相矛盾的（特别是frugal，对员工真的是非常frugal），是职场精髓。是与同事讨论问题，分析问题，解决两难的选择，做重大决择时非常有用的方法论。你运用得好了，小到能让你赢得组内的争论，成为某个initiative的带头人，大到让你在大组里面用各种LP力排众议，让各位领导认为你是真正的Amazonian。当然，你也要用批评的眼光去看这些LP，不要被洗脑。
• 坚决抵制不利于自己发展的文化。有哪些呢？周末非oncall加了班，一般就要在下周找机会补休，让大家觉得你是一个有原则的人，不会被PUA。重大问题上做了贡献，如果有人过来摘桃子，一定要写一个documentation，名义上是把incident/problem solving的timeline写出来，实际上是把各个credit理清楚，下次做performance review的时候有依据。
  . From 1point 3acres bbs

• 写作能力。这个能力包含了，意识到什么时候要写一个one pager, three pager，以及真正写一篇高质量的narrative的能力。亚麻内部，特别是有Asian Amazonian 组织的一些writing kitchen，可以加入学习各位L7+的人是如何写一篇没有废话，深入浅出的technical paper的。这个写作能力是体现自己对某一个话题深入理解，解决口舌之争的法宝，运用的好了，你的每一篇narrative都会成为你的Manager, Skip Manager甚至再往上的领导跟其它组进行negotiation，争取资源的依据。写作能力在亚麻真的是重中之重。
• 定量能力。任何discussion, narrative都需要用数据来说话，把定性的论据用定量的metrics说出来，是一种能力。这些在亚麻尤其重要。平时在看代码的时候，不仅要关注业务代码，也要看很多Metrics是如何设计的，学习一些这种抽象能力。
  

• 从各种能力强的L6, L7身上学到给别人的项目做有价值的Critique的能力。这个我也一直在默默学习的过程中，我只能说这个能力真的是日积月累中沉淀下来的，我还没有资料给出太好的建议，只是提醒大家要注意这方面的学习。
  

kate123321 发表于 2021-12-30 17:37:37
什么service一个月运行需要消耗半个million？

补充内容 (2021-12-31 09:38 +08:00):

AWS 这种体量，重要的service 一个月随随便便就是1 million +

感谢分享，期待续集！

什么service一个月运行需要消耗半个million？

补充内容 (2021-12-31 09:38 +08:00):
.google  и这个service每个月能赚半个million吗？

哇感谢大佬分享，已加米，想认识一下大佬有什么联系方式可以分享吗

赞一个！期待后续。

刚才补充了跟同事们打交道的一些心得

另外说起AWS的体量，其实版上对亚麻的风评不好是方面，但是在体量方面，真的可以学到很多很多东西。这个我下回找机会聊聊

在第六个月的时候等我做的非常大的refactoring和upgrade上线的时候，项目整体性能提高50%，资源使用降低了60% (一个月大概能省半个million的钱），sev2基本降低了80%

这些 metrics 真的是给leadership 看非常重要，不然很多东西真的就是没法 quantify. 想问一下整体性能提高 50% 是怎么 measure 的呀？还有没有哪些其他给 leadership 看的 metrics 楼主推荐 IC 们平时多留心

LittleFishBall 发表于 2021-12-30 18:37:46
这些 metrics 真的是给leadership 看非常重要，不然很多东西真的就是没法 quantify. 想问一下整体性能提高 50% 是怎么 measure 的呀？还有没有哪些其他给 leade

亚麻非常看重metrics, dashboard，这些东西是项目上线必须要有的，所以新版本上线跑了十天半个月基本就一目了然了。其他的常用metrics, latency, availability, processing success rate我们都用