亚马逊SDE II面试完整经历：从在线评估到拿offer的全流程复盘

背景介绍

先说一下我的基本情况：本科和硕士都在国内读的计算机，毕业后在一家中型互联网公司做了4年后端开发，技术栈主要是Java和Go，日常涉及微服务架构、分布式系统、消息队列这些。说实话，在原公司干得还行，但总觉得天花板明显，加上一直有去海外工作的想法，就开始看Amazon的机会。

2025年9月，我在LinkedIn上看到Amazon上海office的SDE II岗位在招人，同时Seattle也有对应的headcount。犹豫了一下，最后两个都投了——想着如果上海能成也不错，Seattle的话更是梦寐以求。投完简历大概两周后收到 recruiter 的邮件，说通过了简历筛选，让我先做OA（Online Assessment）。

说实话，准备Amazon面试的过程比我想象中要长得多。算法要刷，系统设计要练，但最让我意外的是Amazon Leadership Principles（LP）行为面试的权重——几乎每一轮都穿插着LP问题，这在国内公司的面试里几乎不会遇到。我花了大概6周时间准备，下面按时间顺序把整个面试流程完整复盘一下。

在线评估（OA，2道题，120分钟）

收到OA链接后，系统给的时间是120分钟内完成2道算法题。OA是在HackerRank平台上做的，可以选语言，我选了Java。

第一题：日志聚合与分析

题目大致是：给定一个服务器日志文件，每条日志包含timestamp、serverId、responseTime、statusCode四个字段。要求实现一个函数，统计每个server在指定时间窗口内的平均响应时间，并按平均响应时间从高到低排序返回。如果平均响应时间相同，按serverId升序排列。

这题不算难，本质上是分组聚合+排序的问题。我用HashMap按serverId分组，计算每个server的平均响应时间，然后自定义Comparator排序。大概15分钟写完，跑了一下test cases全部通过。

第二题：任务调度器

题目是经典的LeetCode 621变体：给定一个任务列表和冷却时间n，求完成所有任务所需的最短时间。不过这题加了一个额外条件——部分任务之间有依赖关系，必须在某个任务完成后才能执行另一个。

这个依赖关系的处理让我卡了一会儿。我先用拓扑排序处理依赖，确定了任务的执行顺序约束，然后再用贪心策略安排执行时间。说实话这个思路我一开始没想清楚，在纸上画了好几分钟才理顺。最后写出来的代码比较长，大概40多行，test cases过了80%——有两个edge case没处理好，时间不够了就没继续调。

OA结果：3天后收到recruiter邮件，说OA通过了，约了后续的virtual onsite面试时间。一共4轮，安排在两天内完成。

第1轮 LP行为面+算法（约55分钟）

面试官是一位在Amazon工作了5年的SDE III，印度裔，口音比较重但语速适中，沟通还算顺畅。

LP部分（约20分钟）

他先问了两个LP问题：

问题1：Tell me about a time when you went above and beyond for a customer.（对应LP：Customer Obsession）

我准备过这个，讲的是之前公司做ToB项目时，客户提了一个紧急的数据迁移需求，原本不在sprint scope里，但我主动加了班，周末两天把迁移脚本写好并测试通过，周一就交付了。客户非常满意，后来还续约了。我用STAR方法回答，重点强调了为什么客户需要这个以及我的行动如何直接影响了客户满意度。

问题2：Tell me about a time when you had to make a decision without having all the information you needed.（对应LP：Bias for Action）

这个我讲的是一次线上故障——凌晨2点收到告警，数据库连接池耗尽，但当时没有完整的日志能定位根因。我根据经验判断是慢查询导致连接泄漏，果断先做了限流降级，然后再排查。结果判断是对的，15分钟恢复服务。面试官追问了"如果判断错了怎么办"，我说会先确保降级方案本身是安全的、可回滚的，然后快速验证假设。

算法部分（约30分钟）

题目：设计一个数据结构支持insert、delete和getRandom，三个操作都要求O(1)时间复杂度。

这是LeetCode 380原题，我之前刷过。HashMap + ArrayList的方案，insert时把元素加到list末尾并在map中记录索引；delete时把要删的元素和list末尾元素交换，然后删除末尾，同时更新map中的索引。写完代码后面试官让我走了几个test case，又问了并发安全的问题——如果多线程同时操作怎么办。我说可以加ReentrantLock或者用CopyOnWriteArrayList，面试官点了点头，没继续深追。

这一轮整体感觉不错，LP回答流畅，算法也没卡壳。

第2轮 系统设计（约55分钟）

面试官是一位Senior SDE，华人，在Amazon AWS部门工作。这轮纯系统设计，没有LP。

题目：Design a URL Shortener（类似bit.ly）

这题算是系统设计的经典题了，但面试官的要求比我想象中更深入。我按照标准的系统设计框架展开：

1. 需求澄清：我问了读写比例（面试官说10:1读多写少）、是否需要自定义短链、是否需要分析统计、QPS预估等。面试官给了明确回答后我开始设计。

2. API设计：定义了createShortUrl(longUrl, customAlias?)和getLongUrl(shortUrl)两个接口。

3. 核心方案：短链生成我提了两种——base62编码和MD5哈希截取。面试官让我比较优劣，我分析了base62可读性好但需要全局计数器（分布式环境下有瓶颈），MD5哈希不需要协调但有冲突风险。最后我选了预生成batch ID的方案：用DynamoDB的原子计数器批量获取ID段，本地分配后再base62编码。

4. 存储层：用DynamoDB存储映射关系，shortUrl做partition key。面试官追问了缓存策略，我说用ElastiCache (Redis)做热点短链的缓存，LRU淘汰。

5. 可扩展性：讨论了如何通过增加partition和read replica来水平扩展。

卡壳的地方：面试官问了一个我没准备过的问题——"如果某个短链突然变成热点（比如某个大V分享了短链），如何防止缓存击穿？"我想了一会儿，说可以用请求合并（request coalescing），即多个并发请求只放一个去DB查，其余等待结果。面试官追问具体实现，我提到可以用一个并发标记（比如AtomicBoolean），但说实话讲得不太清楚，感觉这部分回答得比较勉强。

整体来说这轮还行，但热点缓存那块确实暴露了我的准备不足。

第3轮 LP行为面+算法（约55分钟）

面试官是一位在Amazon工作了3年的SDE II，美国白人，非常友善，这轮的氛围比较轻松。

LP部分（约20分钟）

问题1：Tell me about a time when you disagreed with a colleague's technical approach. How did you handle it?（对应LP：Have Backbone; Disagree and Commit）

我讲的是之前和同事在技术选型上的分歧——他想用RabbitMQ，我主张用Kafka。我列举了Kafka在我们场景下的优势（高吞吐、持久化、回溯消费），同时也承认RabbitMQ在低延迟场景的优势。最后我们做了一次benchmark对比，数据支持了我的方案，团队决定用Kafka。面试官追问"如果最终决定不是你的方案呢"，我说"Disagree and Commit——我会全力执行团队的决定，不会消极怠工"。

问题2：Tell me about a time when you delivered a result under a tight deadline.（对应LP：Deliver Results）

讲的是去年双11期间，我们组负责的订单服务需要在3天内上线一个新功能。我拆解了任务，把非核心逻辑做成feature toggle先关掉，核心路径先上线，然后逐步开放。最终提前半天完成，线上零故障。

算法部分（约30分钟）

题目：给定一个二叉树，找到从根节点到叶子节点的所有路径，使得路径上节点值之和等于给定targetSum。返回所有符合条件的路径。

LeetCode 113原题，DFS回溯。我很快写完了递归解法，面试官让我解释时间复杂度——我说最坏情况O(N * H)，N是节点数，H是树高（因为每条路径需要拷贝）。面试官又问如果树非常大、递归栈溢出怎么办，我说可以改成迭代版本用显式栈，或者限制最大深度。这轮整体顺利。

第4轮 LP行为面+算法（约55分钟）

面试官是一位Principal Engineer，在Amazon干了8年，气场很强。这轮是我压力最大的一轮。

LP部分（约25分钟，这轮LP问得特别深）

问题1：Tell me about a time when you took ownership of a problem that wasn't technically your responsibility.（对应LP：Ownership）

我讲的是一次跨组协作的故障——前端团队反馈接口超时，但问题出在我们组的数据库查询上。虽然前端先找到我，我完全可以让他们去提ticket给DBA，但我选择自己先排查，发现是一条缺少索引的慢查询。我直接加了索引并优化了SQL，30分钟解决。面试官追问"你觉得这算是你的responsibility吗"，我说"在Amazon的语境下，Ownership意味着看到问题就解决，而不是推给别人"。

问题2：Tell me about a time when you had to learn something new quickly to solve a problem.（对应LP：Learn and Be Curious）

讲的是之前项目需要用gRPC，但我完全没经验。我花了一个周末看官方文档和示例代码，周一就能写出proto定义和server/client端代码了。面试官追问"你觉得学习新技术最大的挑战是什么"，我说"不是语法，而是理解它背后的设计哲学和适用场景"。

追问（这轮最难的LP问题）：面试官说"You mentioned you added an index to solve the slow query. What if that index caused other problems, like slower writes or increased storage? How would you handle that?"

这个问题让我愣了几秒。我说我会先在staging环境评估索引的影响，包括写入延迟和存储增长的监控数据，然后和DBA一起review。如果影响可接受就上线，如果不可接受就考虑其他优化方案（比如查询改写、分库分表）。面试官似乎对这个回答还算满意，但表情不太容易读。

算法部分（约25分钟）

题目：设计一个LRU Cache，支持get和put操作，都要求O(1)时间复杂度。

LeetCode 146原题，HashMap + 双向链表。这题我太熟了，10分钟写完。但面试官加了一个follow-up：如何实现多线程安全的LRU Cache？

这个follow-up让我有点措手不及。我说了两种方案：一是整体加锁（简单但性能差），二是分段锁（类似ConcurrentHashMap的思路，把cache分成多个segment，每个segment有自己的锁）。面试官让我写分段锁的伪代码，我写了个大概框架，但细节上有些地方不太确定——比如segment数量怎么确定、resize时怎么处理。面试官没有继续追问，只是说"interesting approach"。

这轮出来后我心情比较复杂，LP追问很深入，算法的follow-up也没完全答好，感觉是四轮中最不确定的一轮。

面试真题汇总

以下是本次Amazon SDE II面试中遇到的所有题目，按轮次整理：

在线评估（OA）

题目1：日志聚合与分析
考察点：HashMap分组聚合、自定义排序
难度：Medium

题目2：带依赖的任务调度器
考察点：拓扑排序 + 贪心调度
难度：Medium-Hard

第1轮：LP行为面+算法

LP1：Customer Obsession — 超越客户期望的经历
LP2：Bias for Action — 信息不充分时做决策的经历
算法：Insert Delete GetRandom O(1)
考察点：HashMap + ArrayList组合数据结构设计
难度：Medium

第2轮：系统设计

Design a URL Shortener
考察点：分布式ID生成、DynamoDB存储设计、缓存策略、热点防击穿
难度：Medium-Hard

第3轮：LP行为面+算法

LP1：Have Backbone; Disagree and Commit — 技术分歧的处理
LP2：Deliver Results — 紧急deadline下交付成果
算法：Path Sum II（二叉树路径和）
考察点：DFS回溯
难度：Medium

第4轮：LP行为面+算法

LP1：Ownership — 承担非自身职责的问题
LP2：Learn and Be Curious — 快速学习新技术的经历
追问：Ownership的边界与权衡
算法：LRU Cache + 多线程安全follow-up
考察点：HashMap + 双向链表、并发控制（分段锁）
难度：Medium（原题）/ Hard（follow-up）

心得体会与建议

面试结束后等了大概5个工作日，recruiter打电话通知我拿到了offer，是Seattle的SDE II，总包比我预期高一些。回顾整个面试过程，有几点建议想分享给准备Amazon面试的朋友：

1. LP不是走过场，它是Amazon面试的核心
我之前以为LP行为面只是走个形式，但实际上面试官问得非常深入，而且会追问细节。建议至少准备6-8个不同场景的故事，每个故事覆盖2-3个LP原则，用STAR方法组织。特别要注意数据量化——"提升了30%的响应速度"比"提升了响应速度"有说服力得多。

2. 算法题难度在LeetCode Medium左右，但要准备follow-up
Amazon的算法题不会特别难，但面试官几乎都会加follow-up，比如并发安全、空间优化、边界条件等。刷题时不要只追求AC，要理解每种数据结构的变体和扩展。

3. 系统设计要体现Amazon的技术栈偏好
面试中提到DynamoDB、ElastiCache、CloudWatch这些AWS服务会加分。当然不是说你要硬塞，而是如果你熟悉AWS生态，在方案选择时自然地用上这些组件，面试官会觉得你更fit。

4. 面试是双向选择，保持真实
我在第4轮的LP追问中其实有些回答不够完美，但都是真实的经历和思考。Amazon的面试官很看重authenticity，编造的故事经不起追问。与其背模板，不如好好梳理自己的真实项目经历。

FAQ

Q1：Amazon SDE II面试一般有几轮？
通常是OA + 4轮virtual onsite。4轮中一般是1轮纯系统设计，3轮LP+算法。部分候选人可能会有额外一轮bar raiser，但我的面试中没有遇到。

Q2：Amazon LP行为面到底有多重要？
非常重要。Amazon有一个说法叫"LP是面试的50%"，虽然不是精确的权重，但实际感受是LP和技术的比重几乎对半。如果LP回答不好，即使算法全对也可能被拒。建议认真研究Amazon的16条Leadership Principles，每条至少准备1-2个故事。

Q3：OA没满分能过吗？
可以。我的OA第二题只过了80%的test cases，但依然通过了。Amazon更看重你的解题思路和代码质量，而不是单纯的通过率。当然，如果两题都只过了一半，那可能就比较悬了。

Q4：面试中可以用中文回答LP问题吗？
如果你投的是上海office，部分面试官可能是华人，可以用中文沟通。但Seattle office的面试官基本都是英文，建议全程用英文准备和回答。即使面试官是华人，如果他用英文提问，你也应该用英文回答。

Q5：从面试到offer一般要等多久？
我的情况是面试后5个工作日出结果。但据我了解，Amazon的debrief meeting通常在面试后1-2周内举行，之后recruiter会通知结果。如果超过两周没消息，可以主动发邮件跟进。