在亚马逊的工作
26 Jan 2026 - other
想说的事儿
其实很早就想写这么一篇关于亚马逊的工作的文章了，一直拖着，不知道怎么开头、不知道写哪些重点、一些想写的东西，不知道是不是自己体验亚马逊的文化不够深刻导致的误会等等，一直没有写。到头来，还是今天准备匆匆落笔，然后放下了。
加入到亚马逊
在加入亚马逊之前，我是在有点被前司的工作压的喘不过气了。来亚马逊之前，刚刚结束618大促，每逢大促必然出各种问题；就像是每次都是洪水来了，才现去修筑堤岸，没有防洪意识，没有注意基建的意识。一些很基础的东西，都是缺失的（举一个例子是，测试环节对接三方DSP的环境一直存在问题，没有effort去修，导致有些时候竟然用线上环境去测，测的是字段、是否报错等；很多的看板也是没有）。等等这种情况吧，我一个人实在孤木难支，遂觉得在618之后开始面试离职。后面机缘巧合之下，加入当前的亚马逊BU。
# 初到亚马逊
我刚来亚马逊的时候，和另一个组的同事一起办理入职。入职的时候，我记得那天是周三，我来的时候办公室没人，后面manager告诉我说周三的时候大家都在家办工。后面也发现大家即便工作日需要来公司的话，也是很晚才来，或者很久不会来公司的那种。
我觉得亚马逊工作挺自由的。不过我不是特别偏好在家办公，我比较喜欢到点上班，到点下班的那种工作方式。
刚来的时候，遇到一些事儿其实挺不适应的。比如问同事一些问题，基本很晚才能得到回复，或者别人已读不回这种情况也是常见的（不知道亚马逊之后会不会替换掉chime）。我当时很郁闷就是，知道与否，倒是回一个话呀。
> 后面我在亚马逊才意识到，很多人不回复，很大原因是他也不知道；或者如果是那种问时间的（比如什么时候能提供xx，什么时候能修复等等），他不敢轻易回复，他一旦回复，就是commit这个时间。commit一个时间是很危险、重大的事情。比如在某个会上，别人就会拿着这个信息去同步，然后其他人也在会上challenge你。
另外，亚马逊这边的服务，完全就和国内不一样。且不谈AWS那套组件，光是亚马逊内部很多东西，就让人摸不着头脑。之后会展开讲讲。
工作方式也是完全和国内不一样，和我同期的也有互联网来的同事。他碰了很多璧，也是因为他带来了很多互联网的工作习惯。
> 他来自于国内互联网。他有种国内互联网的江湖气、痞气。他首先错误的认为在亚马逊这里的同事，都是像国内互联网那样大家朝着一个目的行进的，大家是一荣俱荣，一损俱损。不是这样的，这边即使项目delay了，也会拆分得很细，来看到底是谁的主要责任，然后也并非互帮互助。很多人知道问题所在，知道怎么解决，可能也不会告诉你答案。（当初人家费劲千辛万苦解决的问题，凭什么你问了就要回答你？）所以这边重复踩坑的，重复探索任务的事情非常常见。所以这位同期在估计很多effort的时候会错误的考量这些事情。（其实也不能叫做错误，是在亚马逊是一个错误，可能在国内互联网公司是行之有效的。）
> 在这样的一些前提下，亚马逊内部除了AWS那一套东西之外，还有很多亚马逊内部自研的东西，pipeline、lpt、bubble bridge、cloud auth、AAA、canary test、hydra test以及其他各种。所以很多东西就需要重复去踩坑，重复去解决。但是有一些国内互联网经验在这里反而是错误的预先构想，让人会effort估计错误，在应付别人问题的时候，回答不适当。最终这位同期被pip，在亚马逊的结束的很狼狈。
# 在亚马逊
来了亚马逊一段时间，我发现我还是没有开启项目，或者负责自己的一块scope，然后开始需求迭代，我其实有点着急的。因为在国内互联网，如果你一段时间没有需求，你汇报的时候，都有问题，老板会不断的challenge你。有和朋友聊天知道，ta在阿里的时候，月提交不足1w行代码被老板提出来。
我有点紧张。（不是谁push，而是自发的紧张，感觉这是国内互联网带来的惯性）
然后我得知，我可能会做一个项目，然后我就问到对应的同事，他也说了是的，是在讨论这样的项目。我想提前进入他们讨论的大群，默默潜水，看看这边一个项目是如何运作的，但是立马被否决了。我当时有点懵，我不明白这种诉求为什么不合理，然后能够被这么决绝的否定。
> 到后面我逐渐明白，这就是亚马逊的工作方式。（我不能保证我的表述一个是准确的）。这种不让你参与，是亚马逊等级的一种体现。就是什么等级、什么role，它承担什么职责，在亚马逊是规定好的，不能僭越。不过亚马逊“明着”的文化，告诉你，无论是谁，都可以讨论一些重大决策；更不用说像是项目的规划这种了，都可以踊跃发言。但是有亚马逊这些规则在，如果你是某个低level（或者不被授予这个职责的人），你是不可能参与讨论的。
> 这里和其他公司想以此来作为信息壁垒有所不同。有些互联网公司利用这种信息差，来谋取自己的利益。亚马逊有所不同，亚马逊从一开始就定死了这样的规则。
后面，我没有做这个项目，转过去做另一个项目。
## 沟通
后面我转去做另外的项目。
其中一个项目是和美国人一起合作，然后我负责其中一个部分。在项目的过程中，有很多的对方案、以及和对方开会的过程。会上会有很多的美国人、印度人参加。在会上，他们讲的语速很快，偶尔还掺杂着一些偏僻的词，导致很多表述为听不太懂，然后回答问题自然也是磕磕绊绊了。
之后我都在反思我当初面试的时候的英语表现。也因为语言和沟通问题，我在整个亚马逊的工作生涯都很焦虑。
做这个项目我也是胆战心惊的。这个项目中的流程、数据源完全脱离了我的掌控，我不知道服务的具体流程是怎样的，谁call哪些服务，哪些服务又承担着怎样的任务，完全处于懵的状态，以往的工作经历没有这种情况。在加上语言和跨地区沟通的一些问题，我在那段时间特别焦虑。
不过好在这个项目还算完成的不错。我负责的部分，我给自己估计的effort相比其他人少的可怜，然后也是高质量完成，在测试阶段，几乎没有遇到bug。后面我也以此向manager表述为的工作成绩。
> 这里的估计effort很少，也是刚来亚马逊不太适应的地方。在国内互联网公司，总有一股无形的力量push你使用最少的时间办最多的事儿，不然你就会比其他人差。但是在亚马逊，这个似乎不是一个优点、或者说少得可怜的优势项。随着effort少带来的风险是不可控的，很多事情光是沟通，拟定方案都需要很长时间，而且不是加班能够搞定的。它需要邮件往复，某些一周一次的会议上评定等等。随后，我也因此踩坑。
在项目中结识的美国那边的senior SDE，人还是很不错的。会告诉一些她知道的亚马逊的规矩，会提醒我，防止误踩。比如她提到一点，Code Review的时候提交的版本，如果其中一个版本没有任何comment，就提交新版本，好像是在绩效评定时候的一个负反馈。
## 风波
我在做项目的过程中，我的manager告诉我一个事情，让我在一个文档整理，大致是统计当前的服务的概括、负载等等，观测在流量高峰期是否有问题等等。
这本来是一件稀松平常的事情，在前司我有负责很多大流量服务，统计和预估流量这种事情对我来说不算难事儿。
> 这里也有一个和国内互联网公司工作的不相同点：说“不”。在国内互联网公司对manager说不，其实是很难的事情，因为manager是最大权重影响你绩效的，对他交代的事情拒绝，会被认为是工作能力方面的问题。但是在亚马逊，不是这样的。亚马逊的manager也会直接评定绩效，但是他不会因为他提交的task来否定你。亚马逊的manager主要管理的resource，他有些时候不了解员工的实际工作内容，不对员工的项目结果负责（如果他drive一个项目，那他才会对项目结果负责），如果你对他说没有effort，他很可能就去找别人了。
> 另外，在亚马逊，陡然给自己增加task也是很危险的事情。做好了固然是很棒，但是因此耽搁了其他项目，导致了delay的话，是没有人为你开脱的。哪怕你是为了新增的这个高优的项目。不能自己吃掉中间的这层风险。
> 合理的方式是：向自己已在的项目leader（TPM， PM，Senior SDE等）callout这件事情，让他们了解这个多出来的effort，让他们把原来规划给你的时间，根据新增的时间延长。如果他们做不到或者评估说不能做，那就应该拒绝这个需求，哪怕是自己的manager提出来的。
我接收到了这个任务需求，manager说了xx时间需要，我也没有反驳这个时间点。然后我随机告诉了美国那个的senior SDE，我会有一周的时间去做文档这个事情。到这里，我其实已经了解到风险了。
我了解到，我的兄弟team做同样的这个事情，他们是两个人，要用两周时间，而且他们都是老练的组员。我这边只有我一个人，而且只有一周。
一周后，我把文档赶工出来。过程中，很多流程和我想象的不一样，我问了很多组员一些事情，基本很难得到答复。或者很晚的时间，才得到只言片语的回复。不过根据我的一些经验和资料翻找吧，总算得到了一个文档。我想着在组内评估的时候，大家看到自己熟悉的一块，发现了我的问题，能帮忙纠正。
会上review的时候，完全不是我预想的风格。刚开始大家还在评估和评论，然后组内有地位的人加进来之后，就开始喷我，在他的节奏一带之下，后面的场景就是变成在喷我了。以他为主导，言辞之犀利，是我工作之罕见，感觉是工作生涯之耻辱。关键这种喷，不是那种想纠正你的喷。喷完不会告诉你正确答案的。譬如我文档写xx服务的负载是xx，会说“你怎么知道是xx”，“怎么会是xx”，结束之后你仍然不知道答案，也不知道从哪儿寻找答案。
评审结束之后，我的manager也同情我的遭遇，然后说希望组内有经验的同事A，B来辅助我更改文档。然后那个组内有地位的人，反驳说，不行，这样会影响到他所在的项目，因为A，B是他所在项目的SDE。我的manager强调不会太长时间，最多一个下午的时间（在亚马逊估task都是一周、短的也是半周这样估计的）。还是被反驳不行，说那样要上报给xx，说明影响项目的进度情况。后面估计闹到了那个和我manager的共同manager那里去了，才平息，最后A，B用了大概下午从午饭结束之后到3点过的时间，帮我一起改了改文档。
我感觉太耻辱了。我工作，哪怕是在实习、刚工作的时候，捅过一些篓子，也没有被人这种喷过。我在那个周末准备好了简历，想之后辞职。后面各种原因，又忍了下来。
> 后面我想，这种突然来的task可能从一开始不应该接。接了，出现了问题的时候，其实委托给你的人（比如这次是manager提给我的），他也不会怎么帮你辩驳，最多说两句话就已经很不错了。像是这种task，刚开始一周的也是，也并非我评估的，也不应该应允这些时间。亚马逊不怕估时间，哪怕估一个月，在亚马逊也很常见。就是一个月的时间光做一个文档。但是如果你估少了时间，最后没有满足时间要求，就是一个大过。
## 适应
到了2024年，我开始逐渐适应亚马逊这边的工作。知道怎么去应付工作上的task，了解了被人问问题时候的说辞。亚马逊这边的规则玩法开始渐渐了解。
接下来的项目算是没有什么大的风浪吧，不过一般来说，都是delay告终。只不过责任不在我。
> 这里也是一个和国内很多互联网公司不一样的点。如果一个项目失败了，国内互联网公司很可能连累的一群人，这一群人都不会有好的成绩。但是亚马逊不一样，亚马逊的很多项目流程都非常的长，牵扯到的team非常的多。然后牵扯这么多team，就会涉及到各个team预告effort，有些team抱着风险最低的方式，哪怕一个接口，一个字段的修改都是一两周、三四周这样的估计。这样冗余累长的流程，导致最后delay是谁造成的，就会有很多扯皮的点。如果扯皮扯不到你，那么你就是安全的。
在2024做的项目的时候，我们和印度team一起。印度team百般不配合，很多地方难以沟通，最终项目delay。我的manager似乎因为这个以及后面的一个项目被pip，离开的亚马逊。
## 舒适圈
2025年初，发生很多变故。我被转租到另外一个team。
后来一年左右的时间内，我在这个team内工作，我觉得这才是真正的亚马逊。team member直接互相帮助，发现问题了大家一起讨论，遇到问题去请教对方的时候，也不会敷衍，是大家一起想着一个目标，让这个team变得更好的终点行进的。我觉得我在这个team的大约一年时间是非常开心的。
离开
在2026年1月份离开亚马逊，觉得在亚马逊工作三年多的时间，算是不枉此行吧。我了解到很多东西，也学到很多东西。像是预估effort，给项目做排期，规划一个项目等等，我觉得都是很难得的经历。
在亚马逊，我能够有幸与清华、北大、南加州、耶鲁、MIT等数不清名校的同事一起共事本身就是一件难得的事情。
这边很多是按照规则来做事的，比如响应一个问题需要多长时间，这个问题应该怎么处理，都是诸多的规则、SOP。
这样的规则有利有弊，如果你刚来，玩不转这些规则，以及不知道怎么应付对方的话语，不知道这边的做事流程，你会很难受，不比国内互联网轻松。但是一旦你适应了，特别是很多在亚马逊这套规则体系中成长起来的人，比如以应届生身份加入亚马逊在这边被这里的文化熏陶几年的人，很容易应付这边的事情。他们知道什么任务该长时间做，什么任务该短时间内完成，什么任务该推脱掉，什么任务该争取过来。这些不是段时间通过ramp up或者onboarding能够学会的。
一直没有换成新的工牌，磨损的很严重了。
把酒祝东风，且共从容。