Amazon 软件工程师面试实录 2026：真实面经完整复盘

公司：Amazon 岗位：软件工程师 (SDE) 面试形式：Virtual Onsite 结果：Pass → Offer

1. Timeline（时间线）

3 月初申请的 Amazon SDE New Grad 岗位，提交简历两周后收到了 OA 邀请。OA 难度大约在 LeetCode 中等偏上，时间控制得当基本能做完。

完成 OA 后大概一周，HR 发来邮件邀请我参加 VO，安排了三轮技术面试，全部集中在同一天进行。每轮时长一小时，由3个三哥分别主持。每轮前 30 分钟是 BQ，考察Amazon Leadership Principles，后 30 分钟是 coding，语法错误不计较，思路清晰、代码结构和时间复杂度是重点考察内容。VO 通过 Amazon Chime 远程进行。

2. VO 面经（Virtual Onsite）

第一轮面试开始五分钟是自我介绍，接着面试官进入 BQ 部分。他第一个问题是让我讲一个 “你曾经 ownership 非常强的经历”。我讲了我在实习期间主动接手一个遗留数据清洗脚本的例子，从接手、理解到重构优化，最后还写了自动化测试并迁移到了 CI/CD 流程中。面试官的follow up关于是否遇到过困难，如何处理团队资源不足的情况。第二个问题是 “有没有一个项目你不得不在极短时间内 deliver？你是如何行动的？”我用了一个 hackathon 项目举例，重点讲了如何合理分配任务、降低 scope、用 MVP 方式快速迭代。整个 BQ 部分非常注重在压力中如何决策、行动。

接下来的 coding 是一道中等偏难的 sliding window 题：“给定一个字符串 s 和一组关键词数组 words，找出所有起始索引，使得从该索引起长度为 len(words)len(word) 的子串是所有关键词的串联（顺序不限）。” 这是一道典型的 LeetCode Hard：Substring with Concatenation of All Words。我从暴力法开始讲解时间复杂度，然后优化到用 hashmap 记录每个词出现次数，并用两个指针 sliding window 加速匹配过程。面试官全程在听我怎么 debug、怎么考虑边界条件，最后成功拿下。

第二轮面试的 BQ 部分一开始问的是 conflict handling。第一个问题是 “讲一个你和队友意见不一致的时候是怎么处理的。”我分享了在组队项目中关于数据库 schema 设计方向的分歧经历，我是如何先听对方的意见，再提出备选方案，并最终说服对方采用 hybrid schema 的过程。接着他又问 “有没有一个时候你做得不够好？你是怎么意识到并改进的？”我谈了某次在 code review 被指出设计耦合过高后，我主动查资料重构，并在下一轮开发中用设计模式优化结构的经验。

这一轮的算法题是图的遍历（高频原题），具体问题是：“给定一个二维字符网格和一个单词列表，找出所有可以由网格中字符拼出的单词。单词必须按顺序连接，并且只能上下左右相邻。”这是一道典型的 LeetCode Word Search II。我的做法是构建一个 Trie 树以存储所有目标单词，然后在 grid 上使用 DFS 搜索路径，并在访问过程中动态剪枝来提高效率。虽然最后只写完了主要逻辑，没完全处理完 trie 节点删除的优化部分，但面试官认可了解题思路和剪枝逻辑，给了积极反馈。

第三轮面试的 BQ 更深入。第一个问题是 “你有没有做过一件别人觉得不可能完成的事？你是怎么做到的？”我讲了我在大四的时候独立从零开始开发一个科研辅助工具，并坚持写文档和测试代码，最终顺利交付导师并获奖学金的事。面试官明显关注我在缺乏指导、资源不足下是否还能 exhibit bias for action。第二个问题是 “你有没有 mentor 过别人，或者帮助组里的人提升？”我谈到了自己作为ta带学生写期末项目的经历，鼓励他们把重点放在代码可维护性和逻辑清晰上。

这轮算法题是一道结合 hashmap 和 heap 的经典题目：“给定一个整数数组 nums 和一个整数 k，返回出现频率前 k 高的元素。” 题目是 Top K Frequent Elements，我很快提出使用 hashmap 统计频率，然后用 min-heap 来维护前 k 个频率最大的元素。面试官让我进一步讨论如果输入数组很大、无法一次性加载进内存怎么办，我补充了用 external sorting 和 stream processing 的思路。

3. 注意事项

Amazon 的 New Grad 面试流程虽然标准化，但每一轮都非常紧凑且有深度，尤其是对BQ的重视远高于我原先预期。Leadership Principles 不是表面说说，需要通过具体、真实、结构化的 STAR 案例来支撑，面试官会深挖细节和你的思维方式。准备时不要只关注 coding，还要认真回顾自己过往的项目、团队协作、冲突处理、抗压的经历，准备 10+ 个能灵活组合的 BQ 案例库。

技术题方面，LeetCode 的中等题必须滚瓜烂熟，Hard 题至少熟悉常见类型的解题思路。尤其注意高频题如 sliding window、top K、图遍历、trie、heap 等等。同时也要练习如何用清晰的语言实时表达自己的思路，这一点在 VO 中比结果更重要。最后，不要忽视面试当天的状态管理——提前检查网络和麦克风、环境安静，给面试官留下可靠、专业的印象。

1. 面试流程

写在最前面：这是25 summer intern的经验分享。亚马逊的 SDE intern 面试流程非常高效。从投递简历到最终面试，只经历了一次正式的virtual onsite，没有多轮筛选。整个时间线大约为一个多月：我在10月底提交了简历，11月10日收到了 Online Assessment，有两周的时间完成，最终选择在11月21日完成提交。之后，11月25日收到了 VO 的面试邀请。整个面试通过 Amazon 自家的视频会议工具 Chime 进行，形式为远程视频面试，需要提前下载安装和测试软件功能。最终这一轮面试就是决胜负的一轮，不再有后续技术或 HR 面，因此重要性非常高。

2. 面试内容

这轮 VO 面试总共持续约 45 分钟，分为两个部分：behavioral和 technical。面试一开始，面试官先简单寒暄，然后让我做自我介绍，然后开始提问BQ。总共问了两道题，都是围绕 Amazon 的 16 条Leadership Principles展开的。

第一题是 “Tell me about a time when you had a conflict with a teammate and how you resolved it”。这道题主要考察candidate处理人际关系和冲突管理的能力。我讲述了一次在团队合作中因为分工不清导致责任重叠的情况，我主动提出与对方沟通澄清任务边界，并引导团队一起重新梳理项目计划，最终顺利推进任务并提升了彼此之间的协作效率。第二题是 “Tell me about a time when you had to learn something very quickly to complete a task”。这题想要评估是否具备快速学习和适应新知识的能力，特别是在压力之下。我分享了一个项目中临时被要求使用一门我不熟悉的框架进行开发的经历，我在短时间内查阅文档、阅读开源项目，并在两天内完成了关键功能模块，得到了导师的认可。这两道题我都使用 STAR 结构组织答案，整个 behavioral 部分持续了大约 20 分钟。

接下来进入 coding 部分。Amazon 的 coding 面试比较特别，没有在线题目展示，由面试官口述题目要求，你需要自己理解、clarify模糊点，然后解释思路、写代码，并在没有运行环境的情况下讲解测试过程。面试环境极简，只有一个基本的代码编辑器，没有 test case 提示、没有代码运行按钮，甚至语法提示也非常有限。这意味着你的代码逻辑必须正确且清晰，而且你还要能够在脑中模拟代码运行，准确描述输出和边界条件。

我被问到一道题。是关于区间合并：给定一组区间，可能存在重叠，要求将所有重叠的区间合并并返回合并后的结果。这个题目考察的是对排序和扫描线思维的掌握。我先按每个区间的起点排序，然后依次遍历，判断当前区间是否与前一个区间重叠，如有重叠则合并，否则加入结果列表。需要解释清楚为什么排序是必须的，以及合并逻辑中的边界情况，整体时间复杂度为 O(n log n)。

结束后，面试官问我是否有问题，我随便了两个问题。他耐心地回答了，并表示面试结果会在五个工作日内通过邮件通知。

3. Lesson Learned

Lesson Learned 这次面试经历让我学到了很多，最突出的体会就是，Amazon 的BQ题几乎百分之百地围绕 Leadership Principles 来设计。如果平时没有认真研究过这些原则，没有准备针对性的 STAR 故事，在面试中会非常被动。因此，建议每位准备 Amazon 面试的同学都要提前写好多个 STAR 案例，最好覆盖不同维度的 leadership，比如“Ownership”、“Bias for Action”、“Customer Obsession”等。

其次，表达能力比我预想的还要重要。由于 coding 部分不提供运行功能，没有自动检查syntax的工具，这就要求你不仅要写出正确的代码，还要能通过语言将其逻辑完整地传达给面试官。这种情况下，清晰有条理地解释代码思路、边界条件以及自定义 test case，几乎和代码本身一样重要。

还有一点非常关键的是时间管理。在 45 分钟内需要完成自我介绍、两个BQ题、一个 coding 题，还有和面试官互动提问，这对节奏感要求非常高。如果在 behavior 部分讲得太细，后面 coding 部分就会时间紧张。所以平时练习时也要模拟整个面试流程的节奏，而不是单独准备每一块。

General Hiring 模式带来了机会窗口

Amazon 的岗位大多属于 General Hiring 模式。这意味着你在面试时并不会接触未来的直属同事或团队，而是面对一位或多位来自其他部门的面试官，他们更关注的是候选人的通用能力是否达标，而非你是否匹配某个特定职位。

这为专业化、标准化的面试服务提供了完美的切入点。Alpha工作室深度还原了Amazon的面试流程与标准，可以安排真正的技术专家替你出镜，参与Coding、System Design、Behavioral等所有面试环节。这不仅大大提高了通过率，更显著缩短了周期。

我们的团队，来自一线科技公司

Alpha 的技术导师团队来自 Meta、Amazon、ByteDance、Google 等一线大厂，所有 mentor 均具备真实的大厂senior在职经历，熟悉面试节奏，理解面试官心理，并能够根据现场情况进行策略性应对。

更重要的是，我们有大量真实案例沉淀，掌握了 Amazon 最常考察的技术点、系统设计模块以及行为问题类型。我们不是代答问题，而是提供一整套成熟的交付逻辑，从“能答对”到“让人信服”，这是两回事，我们专注于后者。

第一轮：纯 Coding（2 道题，45 分钟）

这一轮节奏紧凑，一上来面试官就让我直接进入 livecode，没有任何寒暄（very Amazon-style efficiency）。第一题是经典的变种 palindrome 问题，题目要求判断一个字符串是否可以通过删除最多一个字符变成回文（valid palindrome II）。我之前刷题刷到这个变种不少次，于是直接上双指针写法，同时补了一个 helper function 来处理边界条件。题目不难，但面试官在我写完以后反问了我两个 corner case，比如空字符串、以及只有一个字符的时候是否符合题意。我提前写了 test case，正好都覆盖到了。

第二题稍微 trickier，是 insert interval 的变种。输入是一组 non-overlapping、sorted 的区间（intervals），再给一个新区间（new interval），你需要把它插入后 merge 成新的 interval list。实现思路是线性遍历 intervals，先把所有在 new interval 之前的区间加入结果，再 merge 所有 overlap 的，最后把剩下的 append 上去。这题我很熟悉原题，所以 coding 没有卡壳，面试官也比较满意，追问的重点放在我对 time complexity 的分析上（O(n)）以及“为什么不用 binary search”（我解释说虽然理论可用，但线性 scan 更直观且一次 pass 解决更稳健）

第二轮：Behavioral（3 个问题，40 分钟）

这一轮完全是 Leadership Principles（LP）导向的 BQ 轮，由一位EM主导。全程对我的项目经验非常感兴趣，同时也对细节追问得非常深入。这轮我准备比较充分，所以整个 session 相对顺畅。

第一个问题是经典的 “Tell me about a time you disagreed with a teammate or manager”，我讲了一个关于上线时间争议的故事。我选择的是一个我们当时争取推迟上线窗口的例子（delayed launch due to missing dependency），我陈述了如何基于数据支持我的建议、以及后续即使被 override 我还是 how I committed to the decision。面试官特别在意我在过程中是否真正听取了对方意见、有没有 collaborative behavior。

第二题问的是 “Ownership”，具体是讲一次你跳出来解决本不在你职责范围内的问题。我讲了一个 incident 相关的例子，当时一个 pipeline 出问题，很多人都在推责任，我主动排查 log，修了数据，还补了监控。他问了我一句话让我印象特别深：“Did you ask for permission, or did you just take initiative?” 我回答的是 “I communicated the issue clearly, then proceeded to take ownership once everyone was informed”，他点了点头，应该是符合预期。

第三题是关于 failure 的，“Tell me about a time you failed and what you learned from it.” 我选了一个关于负载预估错误导致系统崩溃的例子。这个问题几乎每轮 Amazon 都会问（it’s almost a ritual），我提前准备了复盘过程（retrospective + action items），也讲清楚了之后怎么避免同类问题再次发生。建议大家这个问题千万不要避重就轻，Amazon 更看重你怎么面对问题，而不是你能不能把它包装成不算失败。

第三轮：Mixed（2 BQ + 1 Coding）

这一轮是 hybrid round，前半部分是 BQ，后半部分是 coding。面试官是一个比较年轻的 engineer，讲话速度快、逻辑清晰。前面两个 BQ 问题是 LP 里的 “Earn Trust” 和 “Invent and Simplify”。

Earn Trust 的问题是问我有没有遇到需要获取一个怀疑我技术判断的人信任的情况（when your technical plan was challenged by others）。我讲了一个前端项目中主动引入类型系统的故事，起初被质疑是 overengineering，后来通过增加可维护性和上线效率证明了方案是有效的。他问我 “What would you do if they still disagreed?” 我说 “I would ask what success looks like to them and try to align on the outcome instead of implementation”，这个回答他挺满意的。

Invent and Simplify 的问题是讲一次你设计了什么系统或流程，提升了团队效率。我讲了之前写的一个自动化注册工具，帮我们把 API 文档和代码生成连接了起来。他重点问我 “How did you measure the effectiveness?” 我提供了手动流程所需时间 vs 自动工具所节省时间的对比数据。

Coding 部分题目是一个括号展开问题，类似 LeetCode 上的 “a2(bc)3(d)” → “abcbcddda”。我一看就决定用栈来做（stack-based parsing）。每遇到 ( 就 push context，遇到 ) 就 pop 并展开重复。中间还得处理 multi-digit 数字（比如 10(ab)）和空字符的 edge case。我写了两个栈：一个存当前字符构成的片段，另一个存 multiplier，处理起来比较清晰。面试官对我主动写 test case 的部分印象不错，最后问了我 time complexity 和空间复杂度的 trade-off。

时间线

这次拿到 Amazon NG 的 offer，整个流程从一月初到四月底，跨度差不多三个半月。最早是在 2025 年 1 月 8 日完成了 OA，当时题目都是常见类型，做完之后心里比较踏实。接下来在二月份收到了 VO survey，本来系统给我的时间是在三月份，但因为别的事，我申请 reschedule，最后把面试时间改到了四月。正式的 VO 是在 4 月 12 日进行的，当天包含了 BQ、Algo 和 OOD 三个部分，持续了三个小时。面试之后大概等了两个星期，在 4 月 28 日收到了正式的 Offer。整个流程没有出现太多意外，但时间上还是比我预想的要长一些，从 OA 到 VO 中间隔了整整三个月。

Virtual Onsite流程

Amazon 的 Virtual Onsite 一般会安排在同一天完成，通常是三轮或者四轮，具体取决于职位级别。每一轮的时间是一小时，基本结构是前半小时行为问题（Behavioral Questions），后半小时算法编程。

在 BQ 部分，面试官的问题几乎全部围绕 Amazon 的 Leadership Principles 展开，例如 Ownership、Bias for Action、Invent and Simplify 等。候选人需要用 STAR 框架来回答，也就是清楚交代 Situation、Task、Action 和 Result。在回答时，面试官会不断追问细节，比如 “你具体是怎么说服团队的？”、“当时遇到的最大困难是什么？”、“如果时间再次倒回去你会怎么改进？” 这样的深挖很常见。所以准备 BQ 时必须有充足的真实案例，并且每个案例要能灵活地映射到不同的 leadership principle 上。

Coding 部分的难度大致在 LeetCode Medium 到 Hard 之间，常见题型包括 sliding window、DFS/BFS、Trie、heap、hashmap 等。Amazon 面试时并不太在意你是否在代码里有语法错误，而是重点看你是否能解释思路、考虑边界条件、分析复杂度并主动优化。如果能在写完解法后主动讨论大数据量下的处理方式或者分布式的场景，就会加分不少，因为这体现了候选人系统化思维的广度。

Mid-level（SDE II / L5）的额外环节

如果申请的是 SDE II，也就是 L5，除了三轮常规的 BQ + Coding，还会多出一轮系统设计（System Design）面试。这一轮同样是一个小时，前半小时依然是 BQ，但问题会更聚焦在中高级工程师的责任，比如如何在不确定性中推动项目落地，如何权衡长期和短期的优先级，以及如何 mentor 团队中的新人。

后半小时的系统设计部分则是 L5 与 New Grad 最大的区别。题目不会到 Senior 那样的规模（比如设计整个 YouTube），但也不是单纯的数据结构题，而是偏中小型系统的架构设计。例如，设计一个 URL Shortener、设计一个 Rate Limiter、设计一个在线聊天服务，或者实现一个高效的计数服务。面试官期待你先澄清需求，识别核心目标，再画出高层架构图，包括 API 层、数据库、缓存和消息队列等核心组件。你需要解释为什么选择某种存储（SQL vs NoSQL）、什么时候用缓存、如何保证扩展性和容错性。即使不能写到非常详细的实现，也要能从工程 trade-off 的角度进行清晰解释。

Amazon热门题型？

首先，Amazon 特别喜欢考字符串和数组问题，尤其是那种边走边处理的场景。像是 Subarray Sum、Sliding Window 相关的题目出现频率很高。除此之外，二分查找也常常登场，因为 Amazon 很喜欢考搜索类的题，最典型的就是旋转数组、找峰值这类。动态规划肯定也有，不过他们不会像 Meta 一样追着问各种花里胡哨的 DP，更多是爬楼梯、零钱兑换这种偏基础但考思路的题。

另外一个明显的热点是设计类问题，比如 LRU Cache 或者最近最少使用栈/队列的变形题。这类题一方面看你对数据结构的掌握，另一方面其实也是在考察你写代码的整洁度。Amazon 面试官特别在意能不能读懂你写的东西，所以变量名乱七八糟或者逻辑太绕可能会吃亏。

考点风格怎么样

Amazon 的风格可以用三个词来总结：清晰、鲁棒、易懂。比如同样是一道区间合并题，Meta 可能会追问你能不能把算法优化到 O(n log n)，还能不能在分布式场景下做；而 Amazon 更可能关注的是，你有没有把边界条件写对，测试用例考虑齐全，代码有没有一眼就能看懂。他们非常喜欢 candidates 在讲解时边画思路边举例子，所以如果你能在白板上快速画出两个 interval 的交集，马上就会加分。

高频题举例！

在具体题目层面，Amazon 的经典题库大家应该都听过几遍了。比如 Subarray Sum Equals K、Maximum Subarray 这种考 prefix sum 的题，几率也很高。旋转数组查找最小值、找峰值、或者是 Search in Rotated Sorted Array 这种二分查找变形题，也算是 Amazon 的保留节目。滑动窗口方面，Minimum Window Substring 和 Longest Substring Without Repeating Characters 都经常出现。链表相关题目里，反转链表、检测环、合并两个有序链表这些都是 Amazon 的最爱。还有一个很典型的就是“交易管理”类题目，比如 Best Time to Buy and Sell Stock，这道题各种变形版本都会考。最后不能忘了 LRU Cache，几乎是 Amazon 高频设计题，碰到它完全不奇怪。

第一轮：算法

第一轮是位国人老哥，气氛轻松。题目两道，都是常规题型。第一题是经典的 Longest Substring Without Repeating Characters，滑动窗口模板题。用两个指针维护窗口边界，同时用 HashSet 追踪窗口内字符是否重复即可。第二题稍有新意：给定一个字符串和若干长度相同的单词，要判断能否从每一列取一个字符组成目标串。解法是先预处理每列每个字符的频次，再用动态规划计算前 i 个字符能否由前 j 列组成，逻辑比较工整。最后几分钟他突然问了我简历上和他们组 stack 重合的部分，比如 AWS 服务、分布式任务调度框架等，看得出他们非常在意能否即刻上手的匹配度。这一轮技术氛围不错，但暗含一个信号：不仅考算法，更考项目落地相关度。

第二轮：Manager 向的 BQ

第二轮是位俄罗斯籍的 SDE Manager，全程非常友好。他的小孩还在镜头前打了个招呼，气氛一下就放松了许多。BQ 题都很常规，比如 “disagree with a teammate”、“tight deadline”、“deliver with limited resources”。我回答时都结合了具体技术情境，比如系统瓶颈、deadline tradeoff 等细节。他没有深挖 follow-up，而是主动帮我总结答案亮点，补充他想要听到的点。能感觉到他关注的是思考框架与合作态度，而非技术细节的刁钻追问。这一轮整体体验最好，也可能是最能体现团队文化的一轮。

第三轮：Coding + BQ 混合

第三轮是位印度女 senior SDE，表情全程严肃但沟通客观。她的 BQ 问得非常 textbook：“a time when you failed”、“constructive feedback from others”。我在回答中提到了一个分布式锁相关的项目失误，正好击中她的兴趣点，后续的 follow-up 聊得很顺。Coding 部分出了个老题——LRU Cache。手写双向链表 + HashMap 的解法即可，但她会追问时间复杂度、edge case、并发情境等，显然是想看实现细节的严谨性。整体气氛略紧张，但交流专业且高效。

近期最常见的OOD题目

第二轮面试中，看到 “Pizza Price Calculator” 的第一眼，我就知道这不是算法题，而是一道考察代码设计和可扩展性的经典面试题。题目看起来很直白：不同的 pizza base、不同的 topping 各自有价格，不同 size 对应一个倍率系数，比如 crust base 是 3 美元、cheese topping 是 2 美元、medium size 要乘以 1.5 倍，最终价格公式是 (base + toppings) × multiplier。顾客下单时必须指定 size、选择一个 base，并可添加 0 个或多个 topping。光从功能角度实现一个计算器非常容易，但要写出一份能在面试中拿高分的代码，就得体现出我对对象建模、扩展性和设计模式的理解。

设计思路：分离结构与逻辑

我首先想到的，是不能让 Pizza 类同时负责存储属性和计算价格。那样虽然短期内可行，但职责太重，后续如果要加入折扣、会员价、节日优惠，就得改核心类逻辑，这显然违反开闭原则。更好的方式是让 Pizza 类只承担“描述性”的角色，它只表示这个 pizza 有什么 base、多大尺寸、包含哪些 toppings，而不直接计算价格。价格计算应该交给一个独立的模块，比如一个价格计算器（PriceCalculator）。这样一来，Pizza 类不会关心价格规则，而 PriceCalculator 可以灵活扩展。比如我可以创建一个基础计算器、一个带优惠的计算器、一个促销计算器，它们都基于同一接口实现不同逻辑，而不需要修改核心结构。这种“逻辑与数据分离”的设计体现了策略模式（Strategy Pattern）的思想，也是很多面试官非常看重的架构意识。

扩展思考：当订单包含多种商品

在 follow-up 阶段，题目会进一步要求支持顾客下多个订单，并且订单中可能包含 pizza、饮料（drink）、甜点（dessert）等不同类型的商品。这时如果系统仍然只围绕 pizza 设计，就会非常僵化。于是我换了个角度去看：pizza、drink、dessert 本质上都是“可以计算价格的商品”。既然如此，那我就不该让系统依赖某个具体商品，而该抽象出一个更通用的概念——订单项（OrderItem）。所有商品都可以实现同样的接口，比如都有 getPrice() 的行为。这样，订单（Order）只需聚合若干个 OrderItem，然后计算总价即可。它不关心每个商品的内部细节，只要知道它们都能自己报出价格就行。这种结构正是组合模式（Composite Pattern）的体现：每个订单项既可以是独立对象，也可以是组合结构。未来要扩展新的商品类别，只需新增类实现相同接口，原有系统完全不用改。

形式内容有什么不同？

亚麻的系统设计面试一般安排在 30 分钟左右，因为还要留出约 30 分钟给 BQ。标准的系统设计流程包括 Requirement Clarification → API Design → Architecture → Database Schema → Control Flow → Deep Dive。不过在亚麻的时间限制下，想完整走完整个流程几乎是不可能的。因此面试的重心通常会放在架构设计（Architecture）和 Deep Dive 。对于 Mid-level，只要能够把功能性需求设计得合理、可行、可扩展，基本就能达标；但对于 Senior 及以上级别，则需要在回答中展现对 Non-functional Requirements 的理解与tradeoff，比如可扩展性、高可用性、一致性、延迟优化等。

另外，要牢记一点：在系统设计面试中，做出面试官想要的设计，比做出“最优”的设计更重要。亚麻的面试官非常看重沟通与协作，因此每一步都应与面试官确认方向，比如说：“我接下来准备从data flow 的角度画一个high level architecture，可以吗？” 或者 “你希望我接下来重点讲解哪个 component？比如 cache 层还是 message queue？” 亚麻内部使用的画图工具是自家平台，功能不如 Excalidraw 流畅，建议提前熟悉基本的框图绘制方式，比如如何画 service box、arrows、load balancer、cache 层、以及数据库分区图等。面试时可以快速画出「核心组件 + 数据流」的结构，而不是追求完美布局。

最后一点，亚麻的系统设计题目范围非常宽。面试官拥有极高的出题自由度。很多题目与亚麻业务无关，属于经典老题；但也有面试官会选择与自己所在团队相关的业务场景。比如：来自 Payment 团队的面试官可能会让你设计一个 Payment Gateway；DynamoDB 团队可能会让你设计一个 Distributed Key-Value Store；Logistics 团队可能会问 Order Tracking / Delivery System；Alexa 团队可能会问 Event-driven or Real-time Pipeline。

Q1：Warehouse Routing Optimization

这一题主要模拟的是 Amazon 物流仓储中心里最典型的规划问题。题目给出的就是一个这样简化后的仓库环境——一个由 0 和 1 组成的二维网格。0 表示可以通行的道路，1 表示障碍物或不可通行的区域。同时会给出机器人起点和目标包裹位置，要求你返回从起点移动到目标位置的最短路径长度。如果根本到不了目标，就返回 -1。本质上，这道题就是典型的 BFS 最短路径问题。因为网格中的每一步路径代价一致，只要用 BFS，从起点开始层层扩展，当你第一次抵达目标位置时，那条路径就一定是最短的。代码实现时重点是维护一个队列，把下一步可能到达的位置不断压进队列，同时用 visited 去记录已经访问过的格子，避免重复计算，否则会导致时间复杂度飙升。写得够规范的话，BFS 的整体复杂度大约是 O(m·n)，完全能满足 OA 的要求。虽然从真实业务角度来看，路径规划更常使用 A* 这种带启发式函数的算法，但 OA 通常不会搞太复杂，按照 BFS 来实现就足够了。不过 test case 会专门设计那种绕远路的情形和边界条件，一定要注意比如越界判断、障碍处理、起点等于终点这些小点，否则很容易挂掉。

Q2：Content Delivery Load Balancing

第二题就更偏向 Amazon Prime Video 背后的内容分发逻辑。题目里会给出 N 个服务器的当前负载，然后告诉你系统一次会新增 K 个请求，希望你能模拟系统是如何把这些请求一步一步分配出去的。每次都要把新的请求派给负载最低的那台服务器，分配完后更新它的负载，再继续进行下一轮分配。最终做完 M 次这样的分配后，要求你输出所有服务器的最终负载，并按从小到大排序。解决思路其实就是 min-heap。把所有服务器的负载丢进堆里，每次从堆顶取出负载最小的服务器，让它承担 K 个新请求，然后把更新后的负载重新放回堆。堆结构能保证你在每次选择最小负载时只要 O(log N) 的操作复杂度，而整个过程要重复 M 次，所以总复杂度大概是 O(M log N)，正好符合 OA 对时间性能的要求。这题比较容易踩坑的是边界情况，比如 K 为 0、服务器数量为 1、或者 M 特别大导致需要非常严格的堆操作效率。还有一些 test case 会故意构造负载相同的服务器，并测试你是否会把它们都正确放回堆中，而不是只更新一部分。另外最终输出前要记得把堆里的所有内容完整弹出，并保证排序正确。

二、OA 阶段：Coding + Work Style

OA 的形式和往年基本一致，总时长 70 分钟，其中包含两道 coding 题，以及一组不限时的 work style 选择题。

两道 coding 题基本都是 LeetCode 风格的算法题，难度通常在 medium 左右，偶尔会有一题偏向 medium-hard，但很少出现纯 hard。题型比较稳定，常见的是数组、字符串、哈希表、双指针、简单 DP 或图的基础遍历。对时间的要求比较紧，如果第一题没有快速通过，第二题的完成度很容易受到影响。

Work style 部分不计时，但非常重要，内容基本围绕 Amazon Leadership Principles 展开。题目形式是给出一个场景描述，让你在多个选项中选择最符合你行为习惯的答案。这里并不是考正确答案，而是考一致性，所以建议在做之前对 LP 有一个整体认知，避免前后选择逻辑冲突。

五、VO 结构变化：两小时但题型不变

虽然 VO 时长变成了两小时，但考察的题型并没有发生本质变化，仍然是 coding + BQ 的组合。区别在于题量和深度都有所扩展。

BQ 依然是围绕 Amazon Leadership Principles 展开，面试官会从你简历或者过往经历中挑选几个点深挖。和之前相比，follow-up 会明显更多，而且有时会顺着你的回答进入 technical deep dive，比如让你解释当时的技术选型、系统瓶颈、trade-off，甚至让你反思如果重来一次会怎么改。

六、Coding 部分：Algo 为主，OOD 为辅

Coding 部分大概率仍然是常规的算法题，也就是标准的 LeetCode 风格。考察重点并不在于你会不会某一个冷门技巧，而是在于你是否具备清晰的思路表达能力、边界条件意识，以及写出可维护代码的能力。

算法题的重点通常包括如何拆解问题、如何在面试过程中逐步优化解法、以及是否能在写代码时同步解释自己的思考过程。时间复杂度和空间复杂度基本都会被问到，尤其是在你给出第一个可行解之后，面试官往往会追问是否有更优解。

小概率情况下会出现 OOD（Object-Oriented Design）相关的问题，通常不是完整的大系统设计，而是偏向于设计一个类结构、接口，或者在已有代码基础上进行扩展。这里更看重你对封装、职责划分、可扩展性的理解，而不是设计模式的名词堆砌。

面试总结

成功经验

充分准备高频题：Amazon 的面试题目集中在经典算法和数据结构上，提前准备 LeetCode 高频题非常有必要。
Behavioral 故事要准备充分：使用 STAR 框架准备 5-8 个核心故事，覆盖 Leadership、Conflict、Innovation 等场景。
沟通表达要清晰：解题过程中要主动与面试官沟通思路，不要闷头写代码。
边界条件要主动讨论：面试官很看重候选人对 edge cases 的考虑。

面试注意事项

时间管理：每轮 45-60 分钟，需要合理分配时间给题目、讨论和 follow-up 问题。

技术深度：Amazon 的面试官对技术细节要求很高，边界条件、性能优化、系统设计能力都是考察重点。

💡 需要面试辅导？

如果你对准备技术面试感到迷茫，或者想要个性化的面试指导和简历优化，欢迎联系 Interview Coach Pro 获取一对一辅导服务。