我做过两次这个面试（不同 team，不同年份），也在上一份工作里以面试官身份参与过几次类似形式的面试。下面是关于 Amazon senior L5 system design 这一轮的真实情况。
他们给你的是什么 通常是这种题：设计 URL shortener、设计 notification service、设计 ride-matching system。都不新颖。这些经典题之所以经典，是因为重点不是考你有没有背答案，而是看你怎么做事。
前 5 分钟的重要性被放大了 先澄清范围。问 scale。问是 read-heavy 还是 write-heavy。问 SLA。Amazon 的面试官跟我说过，他们会在前 10 分钟就开始形成倾向，主要看你是在问对的问题，还是只会画框图。
他们实际在打分什么 Amazon 的 L5 system design 不只是技术。他们也在听 ownership 和 dive deep 的 LP 信号。你解释 trade-off 的时候，他们想看到你在被 pushback 时能 defend 一个选择，而不是马上摇摆。「It depends」作为铺垫可以。「It depends」作为结论就是红旗。
我见过的典型失败模式： 没建立 scale 要求就直接跳进实现细节 不聊 failure modes、retries 或 idempotency 把 data model 当成事后补的 说不清为什么针对这个用例选 SQL vs. NoSQL
关于深度 vs. 广度 他们会打断你，然后在某个组件上往深处钻。这是故意的。挑一个组件（通常是核心写路径或最容易出故障的部分），准备好往下讲三层。缓存策略、淘汰策略、一致性取舍。
对 L5 来说不需要样样完美。你需要展示 senior 级别的判断力。也就是知道哪些点值得花时间，哪些地方可以适当 handwave。