在过去几年，我面了 Amazon NG 岗位不少次（主要是为了帮客户提前探探路），每次流程大致类似，但体验和考察的重点却在不断演进。这次分享的是我在 2025 年 7 月底刚完成的一轮 Amazon SDE NG 面试，总共三轮：一轮纯 coding、一轮纯 behavioral、一轮混合（coding + behavioral）。这一次整体感受是：题目不算特别偏难，但对 candidate 的表达能力、系统性思考，以及 Leadership Principles 的理解，要求得越来越具体了。

第一轮：纯 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后，发现他们的题型其实变化不大，但对细节的深挖、思路的完整性表达、以及 LP 的内化程度，要求越来越高。很多 candidate 以为BQ 就是讲故事，但其实 Amazon 真正在乎的是你能不能用 structured thinking 去解释自己的选择、行为和判断。这种 structured storytelling 能力（比如 STAR 模型 + metric support），比你讲多牛的项目更重要。

Coding 部分则相对标准化，大量题目出自 high-frequency LeetCode list，但你要准备好在写完之后讲逻辑、改进点、复杂度和 test case。能提前 cover 到 edge cases，绝对是加分项。