刚在 2026 年 3 月面完 Amazon 的 TPM 全流程。总共六轮：先跟 recruiter phone screen，然后一轮 hiring manager 对话，接着 onsite 四轮，面试官组合是 TPM、一个 SDE、以及一个 senior PM。没有传统 SWE 意义上的 system design，但有一轮明确叫「technical depth」，他们想让我把我搭建或管理过的某个系统讲到很深。
behavioral 部分全是 LP（Leadership Principles），不意外。让我惊讶的是：他们不满足于那种结尾很漂亮的 STAR 故事。每个面试官都会追问「你会怎么做得不一样」或者「你怎么知道这是正确的 tradeoff」。我被问懵的都是那些我讲得太像收尾总结的故事。
technical depth 那轮，我讲了我 owner 过的一次跨团队平台迁移。他们想听：scope、dependencies、我怎么排 schedule、怎么处理延期、我用什么数据做 tradeoff 决策。房间里的 SDE 会问架构上的澄清问题。不是 coding 面试，但如果你没法用 L5-SDE 的水位讨论系统的 tradeoffs，你会很快失去可信度。
一些特别加分的点： 每个故事里都要有具体数字。不是「我们降低了 latency」，而是「8 周内把 p99 从 800ms 降到 140ms」。 清楚讲出你具体 drive 了什么，哪些是你在推动结果，哪些是你在 facilitation。Amazon 的 TPM 是对结果负责，不只是协调。 「Working backwards」的框架在这里真的重要。我被直接问「你怎么启动一个新项目」，他们想要的答案是：从客户或 stakeholder 目标出发，而不是从工程约束出发。
我看到 pass 和 borderline 的分界：处理 ambiguity 的能力。他们问了类似「product team 想 6 周上线，engineering 说至少 14 周，而且你对两边都没 authority」的问题。答案不是「升级给 manager」。他们想听你怎么收集数据、跑一套结构化 tradeoff、然后自下而上做 alignment。
从 loop 到 offer 大概 3 周。recruiter 沟通还行，但不算特别好。有具体问题欢迎在回复里问。