Amazon 面试问题
作者 Aaron Cao · 更新于
Amazon 面试围绕其16条领导力准则展开。几乎每个问题都是行为类问题，以“讲一件你……的经历”这样的形式提出，并要求以STAR结构、结合具体数字来回答。技术类岗位还会加入编码和系统设计环节，这些环节同样会在考察代码能力的同时考察领导力准则。
16条领导力准则到底在考察什么？
你已经读过领导力准则的清单，它听起来大概像挂在墙上的标语。这一节要说明面试官实际是怎么用它们的，这比措辞本身要具体得多。你面试环节里的每位面试官都会被分配一个准则子集，并且必须带着能证明你展现过这些准则的书面证据离开房间。
正是这种分配方式，让同一轮面试可能显得重复。一位面试官在挖掘Customer Obsession和Ownership，另一位在挖掘Dive Deep和Bias for Action，于是你会被要求就大致相似的领域讲不同的故事。准备六到八个各不相同的故事，而不是只准备一个你最喜欢的，并且清楚每个故事能对应哪些准则。
- Customer Obsession。一个从客户出发、而不是从路线图出发做出的决定。
- Ownership。一件不在你职责范围内、但因为它出了问题而被你主动接手的事。
- Dive Deep。一个你深入原始数据、并发现了摘要信息所掩盖内容的问题。
- Have Backbone; Disagree and Commit。一次你据理力争、最终没有说服对方，却仍然全力执行的经历。
最常出现的行为面试问题有哪些？
措辞会因面试官而异，但题型在不同轮次和级别之间会反复出现。
- 讲一件你承担了职责范围之外的重要事情的经历。
- 说说一次你与经理或同事意见不合的经历。你当时是怎么做的？
- 讲一件你处理过的最复杂的问题。你是如何找到根本原因的？
- 举一个你必须在数据不完整的情况下做决定的例子。
- 讲一件你失败或错过截止日期的经历。之后发生了什么改变？
- 说说一次你在不损害质量的前提下简化流程或削减成本的经历。
比起问题本身，更要为追问做好准备。讲完故事后，面试官会问你具体贡献了什么、前后的数字分别是多少、如果重来你会怎么做，以及你的同事会怎么评价这件事。一个经不起四轮追问的故事，听起来就像是借来的。
怎样构建一个经得起深挖的回答？
使用STAR结构，但要按 Amazon 的权重来分配：简短的情境、一句话的任务，大部分时间用第一人称讲行动，再加上带数字的结果。“我们改善了延迟”这种说法会失败。“我通过加入读穿透缓存，把p99延迟从800ms降到210ms，并在Prime流量高峰期依然保持住了这个水平”这种说法才能过关。
设想一位正在面试高级职位的供应链分析师。她讲了一个预测修复的故事，随后被依次追问：她自己具体改动了模型的哪部分、为什么在两种替代方案中选择了这种方法、之前的错误率是多少，以及流量翻三倍时最先出问题的是什么。她掌握这些数字，所以这个故事站住了。她的第二个故事没有数字，面试官在一分钟之内就转向了别处。
把这些大声练习出来，是大多数候选人会跳过的一步。你可以在/mock-interview页面上，针对AI面试官练习应对追问的压力，这正是书面故事和口头讲述之间差异显现出来的地方。
实时助手在Amazon面试环节中扮演什么角色？
在口头视频面试环节中，SubcueAI会转写面试官的问题，并在你这一侧呈现一个建议的结构——既可以是macOS和Windows上的桌面悬浮窗，也可以是Chromium浏览器扩展的侧边栏。没有任何会议机器人加入通话，也没有任何内容被注入到会议页面中。对于行为面试环节，真正有用的输出是提醒你哪一个自己的故事适合当前被追问的准则，而不是一份现成的脚本；数字仍然必须是你自己的。
有两条诚实的限制。如果技术面试环节转到了有屏幕监控或监考的编码平台上，实时协助就不在适用范围内，你应该把那一轮当作只靠自己的能力应对。如果你被要求共享屏幕，那么屏幕上的一切都会被看到。关于各大雇主如何组织面试环节的更多内容，见公司面试专题，各岗位专属的问题集则收录在题库专题下。