Amazon 面试有多难？
作者 Aaron Cao · 更新于
难度来自结构,而不是题目本身。每一轮都会同时考核你的 Leadership Principles 表现与专业能力,回答会被记录下来并在面试官之间比对,而团队之外的 Bar Raiser 可以否决团队想要的候选人。
真正的难点是什么?
如果你一直在刷算法题,却还是觉得没准备好,这种直觉是对的。本节要说明额外的难度究竟来自哪里——因为它不在题目本身,多刷题也解决不了这个问题。
Amazon 采用结构化面试流程。每位面试官会被分配特定的 Leadership Principles 去考察,在对话过程中详细记录,事后再把笔记拿来比对。由此产生两个后果:一个在现场听起来还不错的故事,如果没有决策、没有结果,写在纸面上就会显得单薄;同一个故事在两轮里讲出不同细节,笔记一比对就会立刻暴露。
另一个难点在于,行为面试的门槛在技术轮里同样适用。一位候选人即便干净利落地解出了编程题,却说不出一次与经理意见不合的经历,也算是没通过一个纯技术面试根本不会考核的环节。
Bar Raiser 到底在做什么?
Bar Raiser 是一位来自招聘团队之外、经过专门培训的面试官,任务是判断你能否拉高该层级现有员工的平均水平。他们不考虑团队这个季度是否缺人手,也可以否决招聘经理想要的候选人。
这在实际中意味着,决定你结果的人在这个职位是否招满上没有任何利益关系。招聘的紧迫性帮不了你,和经理的私交也帮不了你。真正有用的,是那些即便被写下来、被一个从未见过你的人读到,依然站得住脚的证据。
你通常无法分辨哪位是 Bar Raiser,其实也无所谓。把每一轮都当作日后会被一个陌生人读到来作答,因为事实正是如此。
合理的准备量应该是多少?
把准备工作拆开来看。技术那一半是大家熟悉的部分:数据结构、算法,中级及以上职位还要加上系统设计。大多数失败的候选人,并不是败在这一半。
行为面试那一半,需要准备八到十二个覆盖各项 Leadership Principles 的故事,每个都要讲清楚情境、你本人做出的决定,以及可衡量的结果。一个项目往往能从不同角度讲出两到三个故事。只要有数字结果就写下来,因为追问环节通常正是在要这个数字。
接着要大声演练。一位有九年经验的后端工程师,笔记写得很出色,第一次实战演练却还是卡壳,因为读懂一个故事和在追问下讲出来是两种不同的能力。在 /mock-interview 上进行两周的口头演练,带来的提升比再多读一个月笔记要大得多。整个流程逐轮拆解的全景图在 /answers/topic/company-interviews。
候选人通常在哪里丢掉 offer?
大多数情况可以归结为四种模式,而这些都与智力无关。
- 故事里没有决策。讲的是团队做了什么,而不是你自己选择了什么。笔记里最终没有留下任何能归到你名下的证据。
- 没有结果。故事讲到项目上线就结束了,却没说清楚它是否真的奏效。
- 素材用尽。同一个项目在四轮里反复使用,即便每位面试官单独看不出来,汇总讨论时也会一目了然。
- 闷头解题。做编程题时不把思路说出来,让面试官没有任何东西可以记录。
同样值得说清楚的是,有能力的工程师在这里被拒,原因常常与能力毫无关系,包括团队匹配度、当天面试小组的构成等因素。准备工作能改变胜算,却无法决定结果,被拒并不是对你能力的定论。