Amazon软件工程师面试怎么准备
一句话总结
Amazon的面试不是考你代码写得多快，而是考你在压力下能否结构化地暴露思考过程。面试官手里的bar raiser checklist不是形式，而是决定hire/no-hire的硬门槛。准备的核心不是刷题量，而是把Leadership Principles内化成每一句回答的底层逻辑。
适合谁看
正在准备Amazon SDE面试、但发现LeetCode刷到300题仍然心里没底的人。包括从中小厂跳槽的senior engineer、new grad中对"behavioral到底要准备到什么程度"感到困惑的候选人，以及拿过其他大厂offer、却在Amazon loop上意外挂掉的人。
如果你以为Amazon面试和Google Facebook差不多，只是题简单点，这篇文章是写给你看的。如果你已经知道LP很重要，但不知道"customer obsession"在system design里怎么体现，这篇文章也是写给你的。
不是背题，是把题讲成故事
Amazon的coding interview有一个很反直觉的点：最优解往往不是最佳答案。
我见过一个debrief会议的真实场景。一个候选人在两道题里都用最快时间给出了最优解，time complexity和space complexity分析得干净利落。hiring manager在会上说"技术很强"，bar raiser却标了no-hire。
原因是：候选人解题过程中没有任何exploration，没有讨论trade-off，没有"如果数据量扩大100倍怎么办"的延伸思考。bar raiser的原话是："他在给我表演一个已经排练好的答案，不是在解决一个我们一起面对的问题。"
这不是个例。Amazon的coding rubric里，"problem solving approach"和"code quality"是分开打分的。你能在20分钟写出完美代码，只能证明你做过这道题。但面试官要判断的是：给你一道没见过的题，你能不能结构化地拆解。
正确的打开方式不是"我先想个最优解然后直接写"，而是"我先确认约束条件，列出naive解法分析瓶颈，再逐步优化，同时 verbalize 每一步的思考"。一个具体的对话版本：面试官说"设计一个URL shortener"，错误回应是"用base62编码，hash collision用counter解决"然后直接写代码。
正确版本是："我先确认scale，如果日活百万和日活十亿设计完全不同。
假设百万级别，naive方案是用hash map，但persistent storage和cache layer需要分开考虑。另外short URL如果可预测会有security issue，所以不能用simple counter..." 然后边讨论边写。
不是会做题就能过，而是把做题过程变成协作式的问题拆解。
> 📖 延伸阅读：Amazon PMM岗位职责和面试准备指南
LP不是附赠题，是主菜
14条Leadership Principles在2021年简化前是16条，现在官网上虽然显示16条（加了两条new hire-specific的），但面试评估核心仍是那14条。大多数候选人花在LP上的准备时间是coding的十分之一，结果却是在behavioral轮被一票否决。
一个真实的hiring committee场景：一个L5候选人的四轮技术面全过，bar raiser在HC上提出concern——"deliver results"这条LP的体现不足。具体细节是：候选人在讲项目时，提到"我们team延期了两个月，但最后上线了"。当追问"你怎么确保不再次延期"时，候选人说"我之后更努力工作了"。
bar raiser的note是："没有show出systematic improvement，没有measurement，没有process层面的反思。" 最终这个候选人被defer，要求六个月后再面。
Amazon的LP回答有一个结构叫STAR，但比结构更重要的是"what would you do differently"的层度。不是讲完故事就结束，而是主动暴露失败、反思、迭代。一个BAD版本："我lead了一个项目，按时交付了，客户很满意。
" GOOD版本："我lead的项目最初scope过大导致延期，我学到的教训是在planning phase必须设置milestone checkpoint，现在我会用week-long sprint来验证assumption。具体数字是：之前三个月的project我们设了零个checkpoint，现在同样规模的project我设了六个，early failure detection提升了40%。
" 注意这里的40%不是捏造的百分比，而是候选人在原公司实际记录的数据。
不是准备几个故事就够了，而是每个故事都要能撑住三层追问。
System Design不是架构炫技，是权衡的艺术
Amazon的system design轮，L4可能不考或只考simplified version，L5必考，L6以上会考跨service的架构设计。但不管是什么level，考察的核心不是"你知道多少种database"，而是"你在约束条件下做trade-off的能力"。
一个具体的面试官视角：两个人都设计了Twitter-like的feed system。A候选人用了Kafka + Cassandra + Redis，技术栈听起来很solid，但说不清为什么不用更简单的方法。
B候选人用了单个RDS instance加application-level cache，然后主动说"这个设计在百万用户以下够用，超过这个量级我会分sharding，原因是write-heavy vs read-heavy的pattern不同"。B的得分更高。
不是技术选得越多越高级，而是每选一个组件都能说出放弃什么、牺牲什么。
Amazon的系统设计常考题目包括：设计一个key-value store、设计一个rate limiter、设计一个distributed job scheduler。准备时有一个误区是背"标准答案"。实际上，同一个题目在不同团队面试时考察重点不同。
AWS团队的面试官更关注fault tolerance和multi-region deployment，Retail团队可能更关注inventory consistency和peak traffic handling。不是准备通用模板，而是准备"根据团队调整重点"的敏感度。
一个实用的准备方法：找Amazon的open source project或AWS architecture patterns，理解他们为什么这样设计。比如DynamoDB的paper里讲gossip protocol和consistent hashing，不是让你背下来，而是理解"在AP vs CP之间Dynamo选择了什么、放弃了什么、代价是什么"。
这种思维方式才是system design轮要考察的。
> 📖 延伸阅读：Amazon TPM系统设计面试准备攻略
Bar Raiser不是面试官，是流程的守门人
很多人以为bar raiser是"更难的一轮技术面"，这是对Amazon面试流程的根本误解。Bar raiser不是来考你更难的题，而是来确保整个loop的评估标准一致，防止hiring manager因为headcount压力降低标准。
一个insider场景：某次loop结束后，bar raiser召集所有面试官开debrief。前三轮都是hire，bar raiser在第四轮提出了一个其他面试官没注意到的点：候选人在回答"disagree with manager"的问题时，描述的场景是manager最终同意了候选人的方案，但没有讲"如果manager坚持不同意怎么办"。
bar raiser指出这没有体现出"have backbone, disagree and commit"的深度——不是每次你都对，而是即使你认为自己对，有时也要commit to team decision并全力执行。这个concern导致最终结果是no-hire，尽管技术能力达标。
不是通过所有轮次就能过，而是任何一轮出现principle-level的concern都会被bar raiser catch。
Bar raiser的权限很大。他们可以veto hire decision，即使hiring manager强烈想要这个人。但他们也很少见地行使veto，通常是提出concern让group讨论。对候选人来说，这意味着什么？意味着你不能有任何一轮是"勉强通过"的。每一轮都要假设这轮的面试官就是bar raiser，都要把LP融入回答。
薪资谈判：知道数字才敢开口
Amazon的SDE薪资结构是base + RSU + sign-on bonus，没有cash bonus（这是和Google/Meta最大的区别之一）。
2024年参考数字（硅谷/西雅图）：
- SDE I (new grad): base $120K-$140K, RSU $40K-$70K over 4 years, sign-on $10K-$20K. 总包第一年约$150K-$180K.
- SDE II: base $140K-$160K, RSU $80K-$120K, sign-on $20K-$40K. 总包第一年约$200K-$260K.
- SDE III: base $160K-$185K (Amazon base cap约$185K, 超过部分折到sign-on), RSU $150K-$300K, sign-on $40K-$80K. 总包第一年约$320K-$450K.
- Principal: base $185K, RSU $400K+, sign-on negotiable. 总包$500K-$700K+.
注意Amazon的RSU vesting schedule是5%-15%-40%-40%，不是平均四年。这意味着第一年拿到手的equity很少，sign-on bonus的设计就是为了compensate这个gap。不是总包数字好看就行，要算清楚year 1 cash flow。
谈判时Amazon的HR有一定flexibility，但不像Google那样可以compete任意offer。他们更看重level match。如果你手里有Google L4和Meta E4的offer，想要Amazon开出SDE III，需要证明你已经有SDE III的scope和impact，而不是单纯靠offer竞价。
不是准备时间越长越好，而是准备结构越对越好
我见过准备三个月挂掉的，也见过准备三周通过的。差别在于信息质量。
一个常见的错误准备路径是：第一周刷LeetCode easy，第二周刷medium，第三周刷hard，第四周随便看看LP。这种结构的问题是把LP当成了"附加准备"，和coding割裂开来。
正确的结构是：每天的时间按面试轮次比例分配。假设5轮loop（2 coding + 1 system design + 1 behavioral/LP + 1 bar raiser mixed），那准备时间也应该按这个比例，而不是70%给coding。
具体到每天：2小时coding（但重点是verbalize，不是silent coding），1小时LP故事打磨（用同一个故事回答不同LP问题），30分钟system design（画diagram，不是看文章），30分钟Amazon-specific研究（读Amazon tech blog，理解他们最近在做什么）。
不是刷题数量决定成败，而是每次练习都模拟真实面试场景。
准备清单
- Coding：完成50道medium以上题目，每道要求能边写边说，写完后主动分析time/space complexity并提出optimization path。不要只刷tagged Amazon题，要练习unfamiliar题目的第一反应。
- LP故事库：准备8-10个深度故事，覆盖所有14条principles。每个故事要能回答至少3个不同角度的LP问题。用STAR格式，但重点是R之后的reflection：what would you do differently。
- Systematic拆解面试结构（PM面试手册里有完整的Amazon LP实战复盘可以参考），特别是behavioral轮中如何把技术决策和customer obsession挂钩的具体话术。
- Mock interview：至少做3次full loop mock，找有Amazon经验的人做bar raiser角色。重点不是答案对不对，而是时间控制——45分钟的coding，前10分钟必须clarify完requirement。
- Amazon-specific研究：读最近6个月的Amazon tech blog和AWS re:Invent talks，准备至少两个能展示你对Amazon业务理解的问题问面试官。
- 薪资计算：用Amazon的offer calculator（内部HR用的工具，第三方有近似版本）算清楚year 1-4的cash flow，特别是RSU vesting和sign-on的structure。
- Logistics：Amazon loop通常是virtual，但有时会要求on-site。确认设备、网络、安静环境。一个小细节：Amazon的virtual interview用Amazon Chime，不是Zoom，提前测试。
常见错误
错误一：LP故事准备得太"安全"
BAD版本：候选人准备了"我加班完成了项目"作为"ownership"的例子。面试官追问"如果项目最终没成功呢"，候选人愣住，说"但它成功了"。
GOOD版本：同一个主题，"我take ownership的项目最终因为market condition失败了，但我做了post-mortem，发现了我们在user research阶段的三个盲点，这些learning直接apply到了下一个project，使adoption提升了。" 然后给出具体数字和action。
不是展示完美，而是展示从失败中systematically learning的能力。
错误二：System design讲得太high-level
BAD版本：候选人画完architecture diagram后，面试官问"如果其中一个service挂了怎么办"，候选人说"我们会monitor和alert"。这是空话。
GOOD版本："这个service我会设计circuit breaker pattern，具体用Netflix的Hystrix或Amazon自己的类似实现。fallback是serve cached content，stale data acceptable的时间是5分钟，基于业务需求。
上次我在XX场景里implement了这个，MTTR从30分钟降到2分钟。" 用具体数字、具体工具、具体经验。
不是知道概念就行，而是implementation细节和真实经验。
错误三：不问面试官问题
BAD版本：每轮结束面试官问"你有什么问题"，候选人说"没有了，谢谢"。
GOOD版本：根据面试官背景调整问题。对engineer问"你们team的on-call rotation怎么设计的，最近一次incident是什么"；
对manager问"你在这个role里最希望new hire三个月内deliver什么"；对bar raiser问"基于今天面试，你觉得我最需要提升的是什么"（这个问题有风险，但如果面试表现好，可以show出growth mindset）。
不是问不重要的礼节性问题，而是每个问题都在收集信息并展示思考。
FAQ
Q: 我没有"拯救了百万用户"的项目，LP故事会不会太弱？
不是只有大规模impact才能讲。一个new grad的BAD版本是"我没有太多经验，所以讲不出什么故事"。
但实际上，Amazon的LP可以scale到任何scope。GOOD版本：一个intern讲他在小组project里如何resolve conflict，最终如何影响了3个人的team dynamic，这个story如果structure得好，比senior engineer讲空泛的"我lead了50人项目"更有说服力。
关键是细节和reflection的深度：具体哪句话改变了dynamics，你当时怎么想的，下次会怎么做不同。bar raiser评估的是principle的体现程度，不是项目size。我见过L4的story比L6的更令人impressed，因为更raw更真实。
Q: Amazon的coding是不是比Google简单？
不是简单，是考察维度不同。Google的coding interview更偏重algorithmic complexity和edge case handling，Amazon同等重视problem solving approach和communication。
一个只会在白板上写代码、不讲话的候选人，在Google可能还能过，在Amazon几乎一定会被bar raiser标记。
另一个区别是Amazon更倾向于"practical"题目而不是纯算法题。比如设计一个log parser比实现一个red-black tree更常见。但这不是说你可以轻视准备——"practical"题目的陷阱在于你以为简单，结果忽略了requirement的clarification，直接跳到implementation。
Q: 如果我已经面挂了，多久能再面？
Amazon的cool-off period通常是6个月，但取决于你挂在哪一轮。如果是phone screen挂，有时3个月就能再申请；
如果是on-site挂，尤其是bar raiser标记了principle-level concern，通常需要6-12个月。一个具体的hiring manager视角：他们更愿意要"之前面过、有feedback、可以看到improvement"的候选人，而不是完全unknown的。
所以如果你挂了，在cool-off期间有显著成长（比如promotion、significant project delivery），在re-apply时可以在cover letter里提及。不是hide之前的failure，而是show出你如何处理feedback并成长。
Amazon的LP里"learn and be curious"不是白写的——但他们要看到evidence，不是空口承诺。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。