我是如何被亚马逊录用的

所以我被亚马逊录用了......

我之所以想写这篇文章，是因为：1）我之前的帖子可能给人留下了我对大型科技公司抱有某种私人恩怨的印象；2）我知道很多人真的想知道：“我怎么才能进入这些大公司？”所以，这就是我的故事。（顺便说一句，如果你想了解我之前被Facebook拒绝的经历，可以在这里阅读：https://dev.to/bytebodger/rejected-by-facebook-1o3j）

买家当心

首先，我想澄清一下，这不是一篇“如何做”的文章。我写这篇文章的目的并非简单地罗列“我被问到的问题和正确答案”。 我的流程可能与你申请时/申请后的过程有所不同。但我确实学到了一些经验，如果你正在尝试加入 FAANG 公司，这些经验或许对你有所帮助。

其次，这篇文章并非某种“谦虚自夸”。你不会因为在大型科技公司工作就成为“更优秀”的开发者。我见过的一些最优秀的开发者从未在 FAANG 公司工作过。话虽如此，大型科技公司通常薪水很高。即使钱不是问题，很多开发者也希望在简历上写明自己曾在 FAANG 公司工作过。所以我只想分享我在这个过程中学到的经验教训。你的情况可能会有所不同……

教训一：大型科技公司并非铁板一块

我这是什么意思呢？嗯……仅仅因为大公司的一个职位空缺不适合你，并不一定意味着同一家公司没有更多更适合你的职位空缺。

过去几年，亚马逊的招聘人员断断续续地联系我。在几次沟通中，我清楚地了解到，潜在的职位要么是在亚马逊的办公地点，要么只能在疫情结束前远程办公。对于所有这些“机会”，我都礼貌地拒绝了。

许多不同的机会

但像亚马逊这样的公司，拥有数百个团队，员工人数超过一百万。因此，仅仅因为这个机会是仅限现场办公（或任何其他限制性条件……）并不意味着他们的所有机会都有相同的限制。

此外，每个职位或每个团队的招聘流程并不完全相同。当然，像亚马逊这样的老牌公司会有一些“人力资源指南”，可能需要在每次面试中遵循，但这并不意味着在西雅图团队中招聘数据库工程师所需的流程与在凤凰城团队中招聘前端开发人员所需的流程完全相同。

评估

具体来说，在我最初几次与亚马逊招聘人员的互动中，他们指示我先完成一项在线评估。虽然我并不一定反对进行在线评估，但我曾广泛撰文探讨过这些评估所带来的种种弊端（在我看来）。（事实上，我为 Dev.to 写的第一篇文章就是关于编码测试的愚蠢之处。你可以在这里阅读：https://dev.to/bytebodger/your-coding-tests-are-probably-eliminating-some-of-your-best-candidates-de7）

在之前的交流中，我当时工作太忙，根本没时间考虑参加这些评估。我去了评估现场，甚至做了一些模拟测试。但我很快意识到，他们会问我一大堆……深奥的概念，我根本懒得在考试前去研究。所以我干脆就没参加考试——就这样白白浪费了这些“机会”。

从我的角度来看，这次经历略有不同。首先，我基本上处于“待业状态”，所以我更能接受可能需要费力地完成他们的评估。其次，我还发现（这让我非常高兴），这次的工作机会根本不需要我提前进行在线评估。

如果一开始你没有成功……

你还应该记住，即使你面试彻底失败，你也可以在未来某个时间点再次申请。（顺便说一句，我相信亚马逊的政策允许你每六个月重新申请一次。）当然，我确信你过去的成绩仍然会记录在他们的系统中。如果你的技能不够好，你可能不会想随意申请，因为你肯定不想让那些惨败的记录留在你的“永久记录”里，等到你下次申请的时候被亚马逊的招聘经理翻出来。但是，重新申请亚马逊这样的大公司和重新申请你当地小镇的某个小型开发公司是不一样的。

一旦你被一家小型本地公司淘汰，你或许可以理所当然地认为短期内你不需要再申请这家公司了——尤其是如果去年拒绝你的招聘经理今年还在任的话。但像亚马逊这样的公司规模如此之大，即使今年面试你的团队认为你不合格，明年也可能会有另一个完全不同的团队喜欢你。

第二课：做笔记

亚马逊的面试流程非常漫长。这听起来可能有点吓人。但所有这些面试都有一线希望。具体来说，你可能会发现，之前面试中学到的一些知识，可能会帮助你在之后的面试中表现得更好。

注意

比如，我第二次面试的时候就被告知，在之后的面试中，他们可能会问我关于“亚马逊领导力原则”的问题，让我做好准备回答。结果我怎么办呢？我表现得像个十足的傻瓜。

你看，他们花了好长时间（3周多）才安排好所有面试。一开始，我通读了亚马逊的“领导力原则”，也准备好了谈论它。但等到他们安排好我后面的面试时，我已经花了好几个星期死记硬背各种技术细节，完全忘了重新学习“领导力原则”。

因此，在我最后一次面试中，面试官问我：“亚马逊的哪项领导原则对您来说最重要？为什么？” 当然，当她向我抛出这个问题时，我心想：“噢……糟糕。”

诚实面对你不知道的事情

我怎么掩饰自己的失礼行为呢？我没有。我只是直截了当地告诉她，我几周前确实读过这些原则，甚至很久以前就对这个问题有了答案，但这次面试前我忘了重读一遍，现在我手边没有这些原则，也想不起来了。

这算是最顺利的流程吗？可能不是。但我确信我绝对诚实的回答总比临时编造的要好。谢天谢地，这并没有阻止他们给我发offer。

课程 #3：关注核心 JavaScript

显然，这条经验最适用于那些申请前端（或者……以Node为中心）职位的人。表面上看，这听起来似乎显而易见。毕竟，无论你是 jQuery、Angular、React、Vue、Svelte、Node 还是其他任何流行框架的专家，它们都只是…… JavaScript。所以，如果你声称自己了解这些，那么你对普通的 JavaScript 应该非常熟悉，对吧？？？

但我将其列为核心“教训”的原因如下：

1. 事实上，我有点惊讶，很多编程任务都只关注普通的 JavaScript，尽管我面试的职位很可能与 React 有关。在一些面试中，我确实谈到了 React 的概念。但交给我的每个编程任务都必须用普通的 JavaScript 编写。

2. 这给我带来了一个小“问题”。在一次面试中（后来发现，面试我的是我未来的经理），我被要求编写一些基本的 DOM 操作功能。坦白说，我完成了任务。但说实话，当我最初思考如何编写解决方案时，我有点不知所措，因为在过去的六年多时间里，我编写了太多React特有的代码，以至于我不得不停下来思考一下，如何在不使用那些 React 特有功能（或者任何其他通用框架的功能）的情况下，找到解决这个问题的最佳方法。

这里还有一点需要补充：我其实并不确定我的答案是否能用React写出来。当然，提交给我的编码窗口只是简单地标注了“JavaScript”。面试官的默认预期当然是我会用纯 JavaScript 写答案。但我们本来也不会在他们的平台上运行代码（下一课会详细介绍……），而且我的很多面试官都非常熟悉 React。所以，事后看来，我其实并不确定如果我一开始就用 React 写代码会不会有问题。

经验 #4：面试期间保持本地终端（或浏览器）打开

当你参加亚马逊的面试时，他们会邀请你使用他们自己的共享内部工具来编写代码。这个工具与你见过的许多其他在线门户网站（例如 StackBlitz、JSFiddle 或 CodeSandbox）类似，你可以在浏览器窗口中编写一些测试 JavaScript。

然而，他们的工具有一个方面让我有点困惑：你无法在他们的在线面试/编码门户中运行你的 JavaScript。以下是为什么这对我来说只是一个小“问题”：

只需运行代码

有一次，一位面试官让我编写一个 JavaScript 函数，该函数会根据句点分隔的字符串递归地构建一个对象。我着手写下我的解决方案，甚至在写的过程中逐一讲解了每个细节。写完后，面试官指出我的解决方案非常接近，但有一个小瑕疵。

有趣的是：他一指出我的错误，我立刻就明白他是对的。我很清楚，我必须做出一些改变才能完成任务。但我脑子里却有点儿问题，根本没法思考如何调整代码来解决这个问题。

这让我愣了一下，因为在我以前的工作中，虽然要处理成千上万行代码，但指望有人能在脑子里完整地运行一遍代码通常是不切实际的。当然，我通常可以通过阅读代码（我自己的代码，或者别人的代码）来发现问题，但当我非常确定存在问题时，我会把代码拉到本地主机上，然后继续调试，直到问题解决。

尽可能地运行代码

通常情况下，这只需要很少的时间。一旦我能运行有问题的代码，我通常就能非常有效地缩小问题范围。这是因为我不用盯着代码思考为什么它不正确，而是直接运行代码。运行代码时，我只需在代码中设置断点（或console.log()）。然后，一旦我运行了有问题的代码（并实时检查变量），通常就能一目了然地知道需要进行哪些调整才能使其符合规范。

回想起来，事情本不应该这样。需要说明的是，他们甚至从未暗示过我在面试过程中不能打开其他窗口。事实上，在几次面试中，我都跟他们说过，我只是想用一些我已有的代码来解释一个概念。而他们对此从未抱怨过。所以我现在意识到，如果我只是把有问题的代码复制粘贴到另一个窗口（我可以在那里运行它），检查一些变量，进行必要的调整，然后将改进的解决方案复制粘贴回亚马逊的代码共享工具中，可能就不会出现任何问题。

经验＃5：不要害怕将任何“重要”的内容粘贴到他们的编码工具中

首先，要明白你在亚马逊的编码/面试工具中写的任何内容都会被保存。换句话说，所有其他面试官都能看到你在与这位面试官交谈时编写的任何代码。他们很可能会在提出推荐时考虑到所有这些因素。

直到我最后一次面试时，我才完全明白这一点。当时我们讨论了 API/异步调用的概念，我花了大量时间，基本上是尝试重新编写那些我很久以前在其他应用中“解决”过的问题。我这样做是因为我假设我必须在亚马逊的编码窗口中从头开始输入所有内容。

将“支持证据”放入编码窗口

我完成了任务，我的解决方案也“有效”了，但它绝对比我通常投入生产环境的方案要“简陋”得多。所以我告诉面试官：“我通常都是这样处理这个任务的。” 然后，我把我的“标准”解决方案从我的一个 GitHub 仓库里复制粘贴到代码窗口中。

当我这样做时，面试官特意在我复制粘贴的代码上方直接添加了注释，基本上向其他面试官表明这是我的“更完整”的解决方案，从我的另一个应用程序粘贴而来，他们应该花时间审查它。

坦白说，如果不是我之前就给自己设定了先入为主的观念，即必须在他们面前，从头开始在他们的自定义门户网站上输入所有内容，我本可以提供更全面的解决方案。所以，如果你已经有一些扎实的代码来阐述他们要求你编写的概念，那么在面试过程中，不要羞于快速复制粘贴。

经验#6：做好在这个过程中花费大量时间的准备

这或许不言而喻，但大型科技公司确实有能力进行漫长的面试流程。而且他们可能会在空闲时间安排面试。

总而言之，我参加了亚马逊的七次面试（！！！）。第一次是他们内部招聘人员的粗略筛选电话。第二次是技术电话，但基本上是为了确保我有资格参加“完整”的面试流程。通过技术筛选后，他们才安排剩下的五次面试。

他们会尽量把这五场最终面试安排在同一天。但由于与评估员的时间安排冲突，我的最后五场面试最终分两天进行。他们也花了将近三周的时间才安排并确认了这五场面试。

总的来说，我的面试官担任以下角色：

1. 亚马逊内部招聘人员
2. 一名技术筛选员，本身资历相当深厚（知识渊博），但实际上已经没有机会“接触”代码了
3. 后端（Node/API）工程师
4. 高级前端工程师
5. 负责招聘的团队的开发经理
6. BA/PM型
7. 一名高级建筑师

我预计在第2、3、4、5和7次面试中都要写代码。在招聘人员的初步筛选之后，接下来的每次面试都安排在一个小时左右。值得称赞的是，他们非常严格地遵守了时间限制。

经验 #7：沟通，以及编码，但不要争论。

我在七次面试中被要求现场编程五次。所以，如果你在有人（虚拟地）看着你的情况下写代码有任何问题，你肯定需要克服这一点。坦白说，我确信这是无法避免的。你必须在实时环境中编程，而且必须在面试官注视下进行。

我最好的建议是讨论一下你的解决方案。他们并没有要求我这样做。但我从大量的经验（无论是招聘还是应聘）中了解到，如果你只是盯着屏幕，默默地试图在脑子里构思所有代码，即使是很小的编程挑战也会开始侵蚀你的心智。

用你的语言来展示你的知识

至少对我来说，讲解整个过程不仅能帮助我在完成练习时理清思路（以及代码），还能让面试官看到我并非只是在拼命敲击键盘试图找到解决方案。换句话说，你所说的内容和你输入的内容对于展现你的知识水平同样重要。

详细阐述你的解决方案还有额外的好处。当你详细阐述问题，甚至在屏幕上演示你正在编写的代码时，你可能会惊讶地发现面试官会多么积极地引导你。

如果你坐在那里一声不吭，一边慢慢地敲出几行代码，一边苦苦思索答案，面试官很快就会觉得你可能力不从心。但当你详细讲解解决方案时，面试官（希望如此）就能意识到你基本上知道如何解决这个问题，任何持续的拖延都只是因为你在寻找确切的解决方案。一旦面试官确信你确实理解了问题，并且知道如何编写解决方案，他们通常就能更有效地指导你完成练习所需的确切代码行。

我还惊讶地发现，每次面试都花了这么多时间在说话上。在五次编程面试中，每位面试官几乎都用了一半的时间问我编程问题。事实上，我记得有一次面试官甚至直到面试时间只剩下15分钟才开始提问编程问题。

讨论——但不要争论

我唯一要提醒的是，虽然你应该准备好讨论许多技术概念，但绝对不应该卷入任何争论。（当然，这句至理名言可能适用于任何面试，任何公司。）

在我的第三次技术面试中，我和一位前端工程师交谈。我很快就发现，我和他有很多相同的编程“哲学”。具体来说，我提到了我不太喜欢 TypeScript 或 Redux。他一边笑着，一边点头。你可以想象，那次面试进行得相当顺利。

上次面试的时候，我和一位高级架构师聊过。他绝对是TypeScript 和 Redux 的铁杆支持者。这对我来说真的有什么问题吗？没有。事实上，我们就这两种技术进行了很好的讨论，我很清楚地表达了我对它们的欣赏，认为它们都是“工具”，只有在“合适”的时候才应该使用。诚然，我认为我和他对 TypeScript 和 Redux 的某些具体用途存在分歧，但我绝对不认为我对 TypeScript 和 Redux 的矛盾看法会阻碍我收到 offer。

第 8 课：别问！

好吧，也许这条“教训”并不适用于所有大型科技公司的面试，甚至可能不适用于所有亚马逊的面试。但当整个面试过程结束后，我惊讶地发现，面试官竟然没有问我一个我认为“ Gotcha! ”的问题。

谷歌以其“思维实验”问题而闻名。Facebook 已经提前告知我一些“ Gotcha!”（疑似Gotcha！）问题。但在亚马逊的七次面试中，我从未被问到过任何我认为难以理解或深奥的问题。

坦白说，这让我很震惊。

事实上，我觉得很多问题/任务都相当……基础。需要明确的是，仅仅因为一个问题有一个基础答案，并不意味着你不能利用这个机会来阐述答案，展示更深层次的知识。但我没有遇到那种连高级开发人员都会被激怒的问题。你知道我在说什么。他们把答案搞砸了，然后在面试结束后，打电话给他们所有的开发伙伴，说：“你能相信他们真的问了我…… [此处插入一个很少使用的深奥概念]吗？？？”

令我惊讶的是，谈话中很少有冗长地谈论“学术”概念。在我的第二次面试——技术筛选——中，我们简短地谈了谈大O（Big-O），但从未深入探讨。而且他似乎并不在意我无法凭记忆背诵希尔排序的大O复杂度。没有人要求我编写二叉树搜索的代码。没有人指望我能立即记住正则表达式的所有奇特之处。也没有人问我第五个参数的默认值是多少Array.prototype.reduceRight()。

在亚马逊的第一天

我在亚马逊上班第一天就发布了这篇文章。（不，我不会在物流线上工作。但我觉得上面的照片看起来更像是“亚马逊员工”，而不是像我这样的书呆子坐在电脑屏幕前。）

在亚马逊（或其他任何大型科技公司）找一份编程工作“容易”吗？不，我绝对不这么认为。但如果你重读我在第一课中写的内容，你会发现过去几年里，我基本上已经自我淘汰了好几次。坦白说，这个过程感觉很繁琐，我真的不想经历。但现在我已经经历了这个过程，感觉它远没有我想象的那么繁琐。

当然，我绝对不能保证你的面试经历会和我的完全一样。几乎每家公司都有面试官，他们会用试金石和“Gotcha!”之类的问题来刁难你。每家大公司都至少会有一些A级的混蛋，他们觉得问你某种编程语言的神秘细节很聪明。或许亚马逊就是其中之一，只是我这次运气好而已？谁知道呢？

或许你还不明白，我并不是说大型科技公司的工作对其他人来说就是“正确”的职业道路。在科技巨头公司工作确实会面临一些……独特的挑战。说真的，我甚至都不知道它是否适合我。但说实话，我很兴奋地探索这条新的大型科技公司之路，无论它值多少钱。如果结果不好，我会把它写成 Dev.to 上的新内容！😆