最近复盘了几场 Amazon NG 四轮面经 ，发现一个现象挺明显：不少候选人最后反馈都是“感觉没什么问题”。
Coding 两轮都写出来了，时间也控制住了；复杂度分析能讲， Design 也能设计出基本结构；BQ 提前准备过，STAR 故事也背得比较熟。
但结果出来以后，还是会收到 Reject。很多人第一反应会觉得是不是面试官卡得太严，或者当天状态不好。但从复盘情况来看，更多时候问题出在一些细节上。
Amazon 面试并不是只看最后代码对不对。面试过程中，interviewer 会关注你是不是自己推动出解法，遇到新的限制条件能不能继续分析，以及你在 Leadership Principles 故事里到底承担了什么责任。
所以有些人表面上“四轮都答完了”，但每一轮留下的信号可能并没有想象中那么强。
第一轮 Coding：写出来了，但过程并不顺
这轮 Coding 是一道 Top K 高频词题：给定一组搜索关键词日志，返回出现次数最多的 K 个词；频率相同时，按字典序升序排列。
思路是先用 HashMap 统计词频，再维护一个大小为 K 的最小堆。堆顶放当前候选中优先级最低的词，也就是频率更低、同频时字典序更大的词。遍历完后，将堆里的结果按要求排序输出。设日志总数为 N、不同关键词数量为 M，整体时间复杂度为 O(N + M log K)，额外空间为 O(M + K)。
Follow-up 问到亿级数据怎么处理。可以按关键词的哈希值分片，让同一个词进入同一分片，各分片独立统计并选出局部 Top K，最后归并得到全局结果。如果单个分片仍然放不进内存，可以继续分片，或者通过外部排序把相同关键词聚在一起，逐组统计。流式场景则需要先确认统计的是全部历史还是滑动窗口，两者的更新和过期处理不同。
回答建议
题目本身通常不算特别难，确认输入输出之后很快能给出一个可行方案，随后开始写代码。主体逻辑最后成功完成，简单 Test Case 也能跑通。如果只看结果，这轮似乎没什么问题。
但过程中有几个容易被忽略的细节：一开始没有主动讨论 Edge Case，而是准备边写边补；面试官问有没有更优方案时，停顿时间比较长；后来在 interviewer 的提示下，才想到可以换一种数据结构进一步优化。
最终答案确实写出来了，但“独立完成”和“在提示下完成”，在面试评价里并不完全是一回事。这也是很多 NG 容易产生的误区：最后屏幕上出现正确代码，就默认这一轮是 Strong Hire。实际上，面试官看到的是整个 Problem Solving Process。
第二轮 Coding：题过了，Follow-up 却答浅了
这轮 Coding 是把用户和 Alexa 的对话记录按时间划分成会话：相邻两条记录间隔不超过 60 秒，就属于同一段会话；超过 60 秒，则开始新会话。
基础解法是先按时间排序，再从前往后扫描。每条记录与上一条比较时间差，决定继续追加还是新建会话，最后保存剩余的那一组。排序加扫描的时间复杂度为 O(N log N)，存储结果需要 O(N) 空间。这里要注意，判断依据是相邻记录的间隔，所以一段会话的总时长可以远超 60 秒。
Follow-up 改成了乱序插入：新记录可能落在已有数据中间，该怎么更新会话？这时只比较各会话的最后一条记录并不够，还要考虑新记录把两段会话连接起来的情况。比如已有记录在第 0 秒和第 100 秒，原本属于两段会话，插入第 50 秒的记录后，两边间隔都不超过 60 秒，就应该合并。
可以用有序结构维护会话的起止时间，插入时找到对应位置，检查是否落在某段会话内部，或与左右会话相距不超过 60 秒。根据结果，新建会话、扩展边界，或者合并左右两段。普通 HashMap 不方便查找时间上的前驱和后继，有序映射更适合这类需求。
回答建议
这一轮比第一轮顺一些。先讲了基础方案，再讨论优化，代码也完成了。但后面的追问逐渐暴露出准备不足：数据量扩大十倍怎么办，内存放不下怎么办，为什么选这种数据结构，替换以后又有什么代价？
数据放不下时，可以考虑分块排序后做多路归并，在归并过程中完成会话划分。如果是持续到来的乱序数据，还需要明确允许多晚的数据插入，以及已经输出的会话能否修改。这些条件会直接影响需要保留多少状态。
复盘下来，这轮的问题主要在方案解释上。第一层追问还能接住，条件继续变化后，就容易只说“换个结构”“再优化一下”，却没有把理由讲完整。代码跑通之后，仍然需要说清楚当前方案适用于什么输入、瓶颈在哪里，以及改动后增加了哪些成本。
这些 Follow-up 单独看都不算特别难，真正考验的是能不能基于已经写出的解法继续往下推。问题也出在这里。面对第一层追问还能回答，但条件一变，思路就开始变得零散。能说出“可以优化”“可以换一种数据结构”，却解释不清为什么要这样改，以及这样改之后带来了什么新的 Trade-off。
这也是 Coding 面试里很容易被忽略的一点：把题做出来，只说明基础解法过关；面试官继续追问，往往是在判断候选人到底理解了多少。对于 New Grad，不一定要求给出很复杂的系统级方案，但至少要能解释清楚当前方案的限制，以及需求发生变化后应该从哪里调整。所以这一轮表面上是 Solved，实际留下的 Signal 可能并没有想象中那么强。
第三轮：Design 能实现，但扩展性不够
第三轮出现轻量 OOD / Design。比如设计一个 Notification Service，支持 Email 和 SMS，未来还可能增加 Push Notification。最直接的写法并不难：根据 notification type 做判断，再调用不同发送逻辑。功能当然能实现。
但面试官继续问：如果下个月再增加 WhatsApp 呢？每加一种渠道都修改原来的逻辑吗？不同 Notification 是否应该有统一 Interface？失败重试放在哪里？
这时如果回答一直停留在“再加一个 if/else”，问题就出现了。New Grad 的设计题通常不需要上来就画几十个微服务，也未必需要讨论百万 QPS。面试官更可能关注的是：代码结构是否清楚，以及需求发生变化时，设计能不能自然扩展。所以这类题的关键不是“写完”，而是“为什么这么设计”。
第四轮：BQ 都回答了，却可能是风险最大的一轮
最后是 LP / Behavioral。准备过 Amazon 面试的人通常都有一套 STAR Story：一次 Conflict、一次 Failure、一次 Ownership、一次 Deadline、一次 Customer Obsession……因此表面上并不难答。
真正难的是 Follow-up。当时为什么选择这个方案？团队里谁不同意？具体做了什么，而不是团队做了什么？结果如何衡量？如果重新做一次，会改变什么？有没有数据证明这个决定有效？
一个故事连续被追问五六层后，提前背好的 STAR 模板很容易开始失效。常见问题是 Result 只有“项目最终顺利上线”，却没有更具体的影响；讲了很多“we”，但很难说明个人贡献；同一个故事被重复用于多个 LP；被问到失败时，又不自觉地把故事包装成“其实最后还是成功了”。
Amazon 的 BQ 并不是把故事完整讲完就算通过。Follow-up 才是验证故事深度的地方。
Coding 全写出来，为什么仍然可能挂？
把四轮放在一起看，答案就比较清楚了。Coding 结果可能是：Solved。但面试反馈可能是：需要提示后才能完成优化；Edge Case 主要由面试官指出；Follow-up 深度不足；OOD 能实现功能，但扩展性一般；LP 有故事，但个人贡献和结果不够具体。
单独看任何一点，都不像“致命失误”。叠加在一起，却可能无法形成足够强的 Hire Signal。这也是 Amazon NG 面试最容易被低估的一点：“没有答错很多”不等于“给出了足够多的录用信号”。
面试结束后，与其只记录第一题 AC、第二题 AC、Design 写完、BQ 都答了，不如多问几个问题：Coding 有没有主动 Clarify Requirement？有没有自己覆盖 Edge Case？优化是独立想到的，还是 interviewer 提示之后才想到？Follow-up 能不能解释 Why？OOD 面对新需求时，原来的结构要不要大改？LP Story 里的个人 Action 和 Result 是否足够具体？
如果这些问题里有很多答案都不确定，那么即使所有 Coding 最后都写出来了，结果仍然可能存在很大悬念。对于 Amazon NG 来说，LeetCode 决定的是能不能进入讨论，而沟通、Follow-up、设计思路和 Leadership Principles，才共同决定四轮结束后留下了什么样的 Signal。
所以真正值得复盘的，从来不只是“这道题做出来了吗？”，而是“这一个小时里，有没有让面试官看到足够多值得 Hire 的证据？”
备考建议
目前已经帮助了很多北美留子上岸，身边几个同学也找过他们准备 Amazon和其他大厂的面试。
另外注意一下，像 Amazon这种公司， 本人有收集好的 Amazon面经 题库， 有需要的可以 联系InterviewShow 。
如果你也在准备 Amazon的OA/VO、NG 或其他大厂的OA，感觉复习效率低、方向模糊，欢迎联系 CSVOPrep。我们会根据你的具体水平和欠缺的内容，提供专业的 VO 辅助服务和一对一指导。