面经 | SDE | 🔥🔥🔥 | Amazon
2026 Amazon SDE OA - HackerRank | 新版 OA
这次 Amazon OA 和以前不太一样。
整个流程是三部分：
100 min Coding Challenge → 45 min Work Simulation → 15 min Work Style Survey
Coding 现在不是两道纯 LC 了，一道正常 DSA，另外一道是在一个已有 repo 里面修 feature，而且 HackerRank 里面直接带 AI assistant。
我一开始还以为第二题也是类似 Copilot 写代码，实际更像是给你一个小 codebase，让你自己先搞清楚代码在哪里、bug 在哪，然后可以用 AI 帮你 inspect repo / 找 method / 看 test。
Coding Q1 — DSA
第一题是 DP。
题目大概是有两个 branch string，分别代表 primary / secondary branch。
现在要把两个 string merge 到一起，但是每个 string 自己原来的 character order 不能改变。
如果一个字母序比较大的 character 出现在更小的 character 前面，就算一个 conflict，要求找到所有合法 merge 里面最少的 conflict 数。
比如：
primary = "zc"
secondary = "d"
可以 merge 成 zcd / zdc / dzc，求 minimum conflicts。
我刚开始想的是 two pointers / greedy，但是写了几个 example 以后发现 local choice 不太好决定，因为你现在选 primary 还是 secondary 会影响后面所有 cross conflicts。
后面改成 DP。
这题我觉得不算标准 LC 模板，难点主要是怎么把两个 string 内部本来就存在的 conflict 和 merge 产生的 cross conflict 分开想。
写完以后还有 hidden tests，边界 case 比较多。
近期也有候选人报过基本同一道 branch merge / minimum conflicts 的 Amazon OA 题。(Reddit)
Coding Q2 — AI-assisted Repository
第二题完全不是传统算法。
给了一个 Movie DB 的 repo，要求修 movie notification feature。
大概需求是：
admin add / launch 一个 movie 以后，只要某个 user follow 了这个 movie 里面任意一个 star，就应该收到 notification。
另外 unread count 也有 bug，现在算出来的不是当前用户自己的 unread notification。
这一题 HackerRank 右边直接有 AI assistant。
Instructions 里面还明确说可以用 AI inspect existing code、找正确的 file / method、改完跑 predefined tests，但是不要乱 rewrite unrelated code。
我一开始先让 AI 帮我找：
- movie save 在哪里做
- notification 相关 service 在哪里
- follow relationship 怎么存
- unread count 是从哪里算出来的
repo 本身不算特别大，很快能找到 AdminMovieController。
add movie 和 launch movie 两条 path 最后都会 save movie。
这里核心 fix 就是在 movie 保存成功以后触发 notification。
大概就是给 controller 注入 NotificationService，然后在 movieRepository.save(movie) 之后，用 saved movie 调 notificationService.notifyFollowers(savedMovie)。
两个 path 都要改，不能只修 add 漏掉 launch。
我一开始只改了其中一个，跑 test 的时候还有 case fail，才发现 launch 也有一套 path。
另外 unread count 的 bug 更直接。
原来的逻辑相当于在算整个 notification table 里面 unread 的数量，但 UI 需要的是 current user 的 unread count。
所以这里要把 user identity 带进 query / service，只 count 当前用户 read = false 的 notification。
这一题我觉得真正难的不是 code。
code change 本身可能就几行。
难的是 60 分钟里面你要先把陌生 repo 看明白：
controller → service → repository → model → test
而且 AI 不一定第一次就告诉你正确答案。
我有一次问得太泛，它给我建议改 notification model，其实完全没必要。后面我直接把 failing test 和相关 method 给它，让它帮忙 trace call path，效率高很多。
全部改完以后跑 predefined tests，主要就是看：
- admin add movie 会不会通知 followers
- launch movie 会不会通知
- 一个 user follow 多个 stars 会不会重复通知
- unread count 会不会串到别的 user
最近也有 Amazon OA 候选人提到同一个 movie notification repo，反馈就是 “new movie of an actor → followers get notification” 这类 bug。
Work Simulation
Coding 做完以后是 45 分钟 Work Simulation。
这一部分不是写代码，就是给很多比较真实的 SDE 工作场景。
比如一个 feature 快上线了但 test coverage 不够、同事的方案可能会引入 risk、线上出了 issue 但是 root cause 还没完全确认、多个 task priority 冲突之类。
每个场景会给几个可能的 action，让你判断哪种 response 更好。
这个部分感觉就是 Amazon LP 换了一种方式考。
不是让你背：
“Customer Obsession / Ownership / Dive Deep”
而是给一个情况看你到底会怎么做。
我做的时候比较注意前后 consistency。
有些题其实场景换了一下，本质问的是同一个东西，比如 deadline 和 quality 冲突的时候到底怎么判断。
Work Style Survey
最后 15 分钟 Work Style。
这个就更直接了。
基本都是：
“我通常会怎样……”
“面对不确定情况我更倾向于……”
“我是否会主动承担不属于自己 scope 的问题……”
很多 statement 会换个 wording 重复出现。
这一部分我没有想太久，基本按第一反应选，不然越想越容易前后矛盾。
整体感受
新版 OA 最大变化其实就是第二道 coding。
以前准备 Amazon OA 很容易变成纯刷题，现在感觉还需要补一点 读陌生 codebase + debugging + 用 AI 做 repository navigation 的能力。
AI-assisted 那题并不是让 AI 替你做完。
我感觉更像在看：
你会不会把 AI 当成一个 coding tool，但最后自己能判断应该改哪里，而且只做最小必要修改。
第一道 DSA 还是正常准备 medium / hard。
第二道反而建议平时随便找一个 Spring / Django / Express 小项目，练一下：
看 failing test → 找 controller/service/repository → 用 AI trace code → 做小改动 → rerun tests。
这种准备应该比继续多刷 20 道 LC 更有针对性。