亚马逊面试攻略：真题解答与OA面经

Amazon Interview Prep: Questions & OA Walkthrough

亚马逊（Amazon）对软件工程师的招聘流程始于细致的简历筛选，通常会借助自动化系统来识别与职位相关的关键技能和项目经验。通过简历评估的候选人可能会被要求参加在线测试（OA），这些测试通常包含编程题和工作风格评估，旨在衡量候选人的解决问题能力和文化契合度。

成功通过 OA 后，申请人通常会经历一到两轮电话面试。这些面试主要由软件开发工程师或招聘经理进行，侧重于考察编码和解决问题的能力，问题常围绕数据结构、算法和系统设计展开。候选人可能需要在在线编辑器上实时编写代码，解释解决问题的思路，或者回顾过去的项目经历。

电话面试通过后，申请人将进入现场面试（Onsite Rounds），这通常包含四到六轮面试，全面评估候选人的技术能力和行为特质。现场面试内容多样，可能包括白板编程挑战、解决系统设计问题，以及深入考察对亚马逊 14 条领导力准则的理解和应用。整个现场面试过程旨在评估候选人解决复杂问题的能力以及是否符合公司的文化和价值观，难度较高，体现了亚马逊吸纳顶尖人才的标准。

如需面试辅导，请联系我们

技术岗类型

软件工程师

岗位职责：设计、开发和维护各种软件应用程序和系统

面试考察技术点：基本数据结构（如数组、链表、树、图、哈希表）和算法（如排序、搜索、图遍历）的理解和应用能力。熟练掌握至少一种编程语言（如 Java、Python、C++）

数据科学家

岗位职责：分析海量数据集，从中提取有价值的见解，并基于数据驱动业务决策。他们需要开发和应用机器学习模型以及各种统计技术。

面试考察技术点：统计概念（如假设检验、回归分析、概率论）的理解与各种机器学习算法（如线性回归、决策树、随机森林、神经网络）及其应用。

机器学习工程师

岗位职责：研究、构建和设计能够自动运行的软件，以实现预测模型的自动化。

面试考察技术点：深度学习框架（如 PyTorch 和 TensorFlow，模型训练、优化技术（如 GPU 利用率、内存管理）和部署策略的理解

网络工程师

岗位职责：设计、实施和管理支持亚马逊基础设施的计算机网络，并确保网络的性能、可靠性和安全性

面试考察技术点：TCP/IP 网络、IP 路由协议（如 BGP、OSPF）和网络安全概念，网络设备（如路由器、交换机、防火墙）及其配置

SDE面试核心关注领域

备战亚马逊软件工程师面试，着重于基础至关重要。其编程面试的分布与典型的编程面试没有太大差异，其中基础数据结构与算法（Basic DSA）、动态规划（Dynamic Programming）和双指针（Two Pointers）是主要的考察模式。在巩固这些领域的同时，候选人也应为一些频率较低但具有挑战性的模式做好准备，例如回溯算法（Backtracking），以确保能够全面应对各类问题。

技术考察点	面试中的占比
杂项(Misc)	17.7%
模拟(Simulation)	1.3%
双指针(Two Pointers)	13.9%
高级数据结构(Adv. Data Structure)	5.1%
回溯算法(Backtracking)	3.8%
基础数据机构与算法(Basic DSA)	19%
二分查找(Binary Search)	6.3%
堆(Heap)	8.9%
图(Graph)	2.5%
动态规划(DP)	6.3%
深度优先搜索(DFS)	7.6%
广度优先搜索(BFS)	7.6%

相比于其他一些 FAANG 公司，例如 Google 和 Apple，亚马逊的编程面试题目通常更容易应对。候选人经常会遇到侧重于基础数据结构与算法、动态规划以及双指针等模式的问题。总体而言，虽然难度依然不低，但相较于其他一些 FAANG 公司的同类面试，亚马逊的难度略微更易接受。

若按题目的难度占比来分，仅有12%为简易题，中等难度题目占比高达62%，剩余的26%为高难度面试题。

面试题与技术考察难度

常见面试题	考察技术点	难易度
最长有效子字符串的长度	双指针	高难度
生成有效数组的最小相邻交换次数	杂项	中等难度
分析用户网站访问模式	基础数据结构与算法	中等难度
蜡烛之间的盘子	二分查找、双指针	中等难度
最少按键次数	基础数据结构与算法、杂项	中等难度
使数组为空的最小操作次数	基础数据结构与算法、杂项	中等难度
连接词	高级数据结构、深度优先搜索、动态规划	高难度
重组字符串	基础数据结构与算法、堆、杂项	中等难度
巫师的总力量之和	杂项、双指针	高难度
最近最少使用缓存	基础数据结构与算法	中等难度

Amazon OA（在线评估）

亚马逊的在线测试（Online Assessment, OA）是其软件工程师招聘流程中的早期筛选环节，通常通过 HackerRank 或 CodeSignal 等平台进行。OA测试的核心目标旨在评估候选人的基础编程能力、数据结构与算法、行为能力和工作风格评估。

SDE I（入门级软件开发工程师）

侧重考察技术点:
- 基础数据结构和算法 (DS/Algo): 对数组、链表、字符串、树（二叉树）的基本操作和遍历有清晰理解。理解栈和队列。了解哈希表的基本概念和使用。
- 编程基础: 掌握至少一种编程语言，语法正确，能写出逻辑清晰的代码。
- 代码调试能力: 能理解简单代码逻辑，找出并修复常见的语法或逻辑错误。
- 时间/空间复杂度分析 (Big O): 能对简单算法进行初步的复杂度分析。
常见 OA/面试题类型:
- OA Debugging: 修复涉及数组遍历、字符串处理、链表操作、基本循环或条件判断的简单代码 bug。
- OA Coding:
  - 数组/字符串操作：两数之和 (Two Sum)、有效括号 (Valid Parentheses)、反转字符串/链表。
  - 链表操作：合并两个有序链表、删除链表节点。
  - 树：二叉树的各种遍历（前序、中序、后序）、求二叉树的最大深度。
  - 查找/排序：二分查找。
  - 基本哈希表应用。
- 面试 Coding: 类似 OA 题目，但在白板或共享编辑器上写，并需要向面试官解释思路。可能会有简单 follow-up，例如链表题变双向链表，树题增加平衡性要求（但通常不会要求实现平衡）。
- LP/行为: 主要考察 Learn and Be Curious, Customer Obsession, Ownership (针对自己的任务), Earn Trust (基本的团队合作)。问题如：“讲一个你学习新技术并将其应用到项目中的经历。”，“讲一个你犯错并从中学习的经历。”

SDE II（软件开发工程师 II）

侧重考察技术点:
- 更广泛和深入的 DS/Algo: 熟练掌握树（包括平衡树概念）、图的基本算法（BFS/DFS 及其应用，如拓扑排序）、堆、优先队列。初步理解动态规划、贪心算法、回溯等。
- 更复杂的问题解决能力: 能将中等难度的问题分解并用合适的数据结构和算法解决。
- 时间和空间复杂度分析: 能对更复杂的算法进行准确分析，并讨论优化方法。
- 面向对象设计 (OOD): 能进行简单的类设计。
- 系统设计基础 (初步考察): 对构建一个简单的、单一服务的系统有基本概念，了解缓存、数据库、负载均衡等组件的作用。
常见 OA/面试题类型:
- OA Coding:
  - DP 问题：爬楼梯、最小路径和、背包问题（简化版）。
  - 图/树问题：最近公共祖先 (LCA)、克隆图、判断环、层序遍历 (BFS)。
  - 堆/优先队列：前 K 个高频元素、合并 K 个有序链表。
  - 更复杂的数组/字符串问题：无重复字符的最长子串、滑动窗口最大值。
- 面试 Coding: 类似 OA 题目，但要求更高，需要讨论多种解法及其权衡，并能完美实现。可能会有更深入的 follow-up。例如：LRU Cache（要求实现）。
- 面试 System Design (基础):
  - 设计一个 URL Shortener。
  - 设计一个 Pastebin。
  - 设计一个在线计数器。
  - 问题侧重：核心功能、数据存储（选型理由）、如何处理并发、初步的伸缩性考虑（如增加服务器）。
- LP/行为: 除了 L4 要求外，更强调 Ownership (针对一个功能或小项目), Bias for Action, Are Right, A Lot (做出相对正确的技朮判断), Hire and Develop the Best (通过代码评审等方式指导 L4)。问题如：“讲一个你主导并成功交付一个功能的经历。”，“讲一个你在技术上与其他成员意见不一致，你是如何处理的？”

SDE III / Senior SDE（高级软件开发工程师）

侧重考察技术点:
- 高级 DS/Algo: 熟练掌握各种复杂数据结构和算法，能识别并应用高级算法模式解决难题。对算法有深度理解。
- 复杂的系统设计 (核心): 能设计大型、可伸缩、高可用、高并发的分布式系统。深入理解分布式系统的挑战（如一致性、容错性、网络分区）。
- 数据库知识: 深入了解关系型和非关系型数据库，索引、事务、分片、复制等。
- 缓存、消息队列、负载均衡等分布式系统组件: 深入理解其工作原理、选型和使用。
- 面向对象和系统设计原则: 设计模式、模块化、API 设计。
- 性能优化和监控: 能识别系统瓶颈并进行优化。
- 领导能力和技术判断力: 能在技术上带领团队，做出关键技术决策。
常见 OA/面试题类型:
- OA Coding: 题目难度偏高，可能涉及比较复杂的 DP、图算法、位运算技巧等。
- 面试 Coding: 题目难度 Hard，或者要求在复杂约束下进行优化。例如：实现分布式锁、复杂任务调度、设计特定领域的算法库。更侧重考察对底层原理的理解和解决复杂问题的创新性。
- 面试 System Design (深入):
  - 设计一个新闻 Feed 系统 (如 Twitter Feed)。
  - 设计一个分布式缓存系统。
  - 设计一个短链接生成和重定向系统 (大规模)。
  - 设计一个高并发的订票系统。
  - 设计一个监控或日志收集系统。
  - 问题侧重：架构选型、数据模型、分区策略、一致性模型（Eventual Consistency vs Strong Consistency）、高可用性方案、容错机制、并发控制、API 设计、服务间通信、容量预估和伸缩性策略。
- LP/行为: 在 L5 基础上，强调 Think Big, Deliver Results (针对大型或跨团队项目), Hire and Develop the Best (指导 L4/L5，参与招聘), Earn Trust (影响团队和跨团队), Dive Deep (深入技术细节解决问题),Frugality (考虑成本), Insist on the Highest Standards。问题如：“讲一个你设计并落地一个影响较大系统的经历。”，“讲一个你在团队中推动技术改进或采用新技术的经历。”，“讲一个你指导其他工程师并帮助他们成长的经历。”

Principal SDE（首席软件开发工程师）

侧重考察技术点:
- 极深的技术广度和深度: 在多个技术领域拥有专家级知识，能理解复杂系统的各个层面。
- 架构设计能力: 设计组织级甚至公司级的复杂系统架构，考虑长期演进、技术债务、跨团队协作、安全、合规等。
- 分布式系统理论和实践: 对分布式一致性协议、容错算法、分布式事务等有深刻理解。
- 解决开放性、高难度问题的能力: 能在高度不确定性和信息不全的情况下定义问题并找到创新性解决方案。
- 技术领导力和影响力: 能设定技术方向，影响其他资深工程师和管理层，推动技术变革。
- 高判断力: 在关键决策中展现出卓越的判断力。
常见 OA/面试题类型: (OA 阶段通常不会有 Principal 级别的技术题，或者仅作为初步筛选，重点在后续面试)
- 面试 Coding: 可能会有，但通常是开放性问题，或者要求实现某个核心、复杂的组件原型。更侧重考察对基础原理的理解和设计能力，而非简单的算法实现。
- 面试 System Design (架构师级别):
  - 设计一个全球规模的服务，要求极高的可用性和低延迟。
  - 设计一个处理海量数据（PB 级）的实时分析平台。
  - 设计一个跨多个业务领域的共享基础服务。
  - 讨论如何从单体架构迁移到微服务（大规模）。
  - 讨论某个著名大型系统的架构（如 AWS S3、DynamoDB 等），分析其设计选择和权衡。
  - 问题侧重：跨区域复制、灾难恢复、数据一致性的不同模型及其在不同场景下的适用性、复杂的并发控制、安全性、成本优化、运维复杂性、技术选型对组织结构的影响、长期技术战略。
- Technical Talk / Deep Dive: 要求详细介绍自己过去负责的最复杂、最有影响力的项目，包括技术挑战、架构决策、遇到的问题、如何解决、取得的成果等。面试官会进行非常深入的追问。
- LP/行为: 所有 LPs 都要求达到非常高的水平。特别强调 High-Judgment, Think Big, Invent and Simplify, Are Right, A Lot, Hire and Develop the Best (能指导 L6+ 的工程师), Earn Trust (在整个组织范围内建立信任和影响力)。问题如：“讲一个你在没有明确方案的情况下，定义并解决一个重大技术难题的经历。”，“讲一个你需要在多种高风险方案中做出最终技术决策的经历。”，“讲一个你在组织内部推动一项重要技术标准或倡议并取得成功的经历。”

行为面试 (BQ)

面试的时候，候选人经常会问到一些行为问题，就是让你讲讲过去经历过的事儿，看看你是怎么处理的。

比如说，他们可能问你，之前有没有遇到过那种时间特别赶的项目，你是怎么处理的？结果怎么样？这时候你就可以讲讲当时是怎么安排事情、怎么抓紧时间的，看看你有没有用啥技术让效率更高，最后是不是按时把项目搞定了，团队或者领导反响好不好。

或者问，你遇到过那种特别难搞定的 bug 吗？是怎么解决的？你可以说说当时找 bug 的思路，有没有一直钻研，或者有没有找同事一起想办法？看看你有没有用什么特别的工具或者技巧来搞定它。

还有一种情况，他们会问，有没有为了完成项目，临时学一门新的编程语言或者技术？你是怎么学的？你就讲讲你是怎么通过看书、看文档、上在线课或者问社区里的人来学的，看看你学得快不快，最后在项目里用得怎么样，顺利不顺利。

在团队合作方面，可能会问，你们团队有没有一起解决过什么特别有挑战的问题？当时的问题是啥？你们是怎么搞定的？这里就看你跟别人怎么配合了，重点说一下你们怎么沟通、怎么分工的，你在里面起了什么作用，是不是带头冲锋了，最后是怎么通过协作把问题解决的。

或者问，项目里有没有队友遇到困难，你去帮过他？具体怎么帮的？结果如何？这主要是看你是不是乐于助人，会不会解决问题。你可以讲讲你是怎么去指导或者支持他的，最后项目是不是因此顺利推进了，或者团队关系更好了。

像亚马逊这种特别强调“客户至上”的公司，肯定会问，你在团队项目里有没有优先考虑过客户的需求？有没有遇到过那种客户需求跟团队原计划冲突的情况？你是怎么让团队把重心转回到满足客户身上的？最后项目结果怎么样，客户满意不满意，这块就可以和公司的价值观联系起来说。

再比如，还是说学新技术，为了完成某个工作，你不得不学新的东西，你是怎么确保自己能学会、能用好的？你就讲讲你当时具体是怎么做的，比如主动找各种资料啊，尝试啊，确保能快速上手并且用好，达到项目目标。

团队里有分歧或闹矛盾的情况也常有，他们可能会问，你遇到过吗？你是怎么处理的？这就看你沟通能力和解决问题的能力了。说说你是怎么听大家意见、怎么去协调、怎么帮助大家达成共识的，最后团队是不是还能愉快地合作下去，活儿也没耽误。

最后，如果你的工作是开发软件，他们很可能问，有没有做过一个项目，开发的软件让用户体验大大提升了？讲讲你是怎么了解用户需要啥的，用了什么巧妙的办法或者新的功能，最后用户用了你的东西，是不是觉得好用多了，是不是更爱用了。

这些问题其实都是想看看你在实际工作中的表现和处理问题的方式，回答的时候放轻松，讲清楚具体过程和结果就行。

面试准备

亚马逊技术岗位的面试通关绝不是简单通过在Leetcode等平台猛刷题就能应对的了，更加合理的策略或者说需要提前做的准备理应是求助于社区如Reddit等，看看是否有已经参与过您即将需要参加的岗位的面试经验分享，或者找有经验的老师、学长进行请教，甚至模拟训练，最好是通过一些内部渠道提前拿到各个面试环节的最新真题，而CSOAsupport则是为面试辅助而生的平台，通过我们在大厂在职的成员以及以往代面过程中所积累的真题经验，能帮你获得更高的Offer成功率。

VO真题解答

想象你现在是亚马逊的一名软件工程师，负责管理数据中心的服务器集群。为了应对不同时间段的用户流量，我们需要动态调整服务器的运行状态。每个服务器集群可以用一个数字来代表它的当前运行能耗级别，这个级别可以从 0（完全关闭）到任意正整数（高能耗运行）。

一开始，所有服务器集群的能耗级别都是 0。

现在，你得到了一个未来某个时段的期望能耗级别列表，比如： expected_energy_levels = [3, 5, 2, 0, 6]

意思是：第 1 个集群（索引为 0）的能耗要达到 3。第 2 个集群（索引为 1）的能耗要达到 5。以此类推。

你能做什么？

你不能单独调整某个服务器集群的能耗级别。为了高效管理，你的操作是每次选择一段连续的服务器集群，然后把这段集群的能耗级别同时增加 1 单位。

比如：你可以选择第 2 到第 4 个集群（索引 1 到 3），一起增加 1 单位能耗。或者只对第 5 个集群（索引 4）增加 1 单位能耗。或者对所有集群增加 1 单位能耗……

总之：一次操作只能对一段连续的集群增加能耗，每个集群都增加 1 单位。

你的目标是：找出：最少需要多少次操作，才能把所有服务器集群的能耗从【全是 0】变成你老板给的目标能耗级别列表。

这道题很典型，它模拟了我们在亚马逊实际工作中会遇到的资源调度问题。本质上，我们是从一个服务器集群的**“零能耗”状态**，通过批量“提升能耗”的操作，来达到一个预设的能耗目标。我们要找的是最少操作次数。

这个题目其实是对我们刚才讨论的那种“区间加一”问题的实际业务场景化。它的核心逻辑和之前那道铺设道路的题目是完全一致的。

我们来再次分析一下，拿 expected_energy_levels = [3, 5, 2, 0, 6] 这个例子来说。

初始状态：所有服务器集群的能耗都是 [0, 0, 0, 0, 0]。
我们想要实现 [3, 5, 2, 0, 6]。
考虑一下，如果我需要把 cluster[0] 的能耗从 0 提升到 3，那么至少需要 3 次操作，而且这些操作都必须覆盖到 cluster[0]。这些操作可以是从 cluster[0] 开始往右延伸的任意长度。
关键在于，当我们从左往右看集群的能耗级别时，如果当前集群的期望能耗 expected_energy_levels[i] 比前一个集群的期望能耗 expected_energy_levels[i-1] 高，那就意味着多出来的那部分能耗提升，必然需要新的、独立的批次操作来完成。为什么呢？因为之前针对 i-1 或者更早的集群进行的那些批量能耗提升操作，最多也只能把 cluster[i] 提升到 expected_energy_levels[i-1] 的水平。要想达到更高的 expected_energy_levels[i]，就必须有新的、从 i 或者更靠右位置开始的能耗提升操作。
所以，我们可以总结出一个贪心策略：我们遍历这个期望能耗列表，每次遇到比前一个集群更高的能耗要求时，就把这个**“增量”**计入总操作次数。因为这些增量是无法通过之前的操作“白嫖”的，它必须靠新的操作来补齐。
具体的算法步骤如下：
1. 初始化 total_operations = 0。
2. 对于第一个集群（索引为 0）：它需要 expected_energy_levels[0] 次提升才能达到目标。所以，total_operations 加上 expected_energy_levels[0]。
3. 从 i = 1 开始，遍历到 expected_energy_levels.length – 1：
  - 如果 expected_energy_levels[i] 大于 expected_energy_levels[i-1]，这意味着从 cluster[i] 开始，我们需要额外进行 expected_energy_levels[i] – expected_energy_levels[i-1] 次能耗提升操作。这些操作是独立的，必须计入总数。所以，total_operations += (expected_energy_levels[i] – expected_energy_levels[i-1])。
  - 如果 expected_energy_levels[i] 小于或等于 expected_energy_levels[i-1]，那么 cluster[i] 的能耗可以通过之前那些把 cluster[i-1] 提升到更高能耗的操作来覆盖。不需要额外启动新的从 cluster[i] 开始的操作。

我们用 expected_energy_levels = [3, 5, 2, 0, 6] 这个例子实际跑一下：

初始化 total_operations = 0。
i = 0: expected_energy_levels[0] = 3。 total_operations = 0 + 3 = 3。（想象我们对从 cluster[0] 开始的一段集群，进行了 3 次能耗提升操作。）
i = 1: expected_energy_levels[1] = 5，而 expected_energy_levels[0] = 3。5 > 3。 total_operations += (5 – 3) = 2。现在 total_operations = 3 + 2 = 5。（这意味着从 cluster[1] 开始，又进行了 2 次新的能耗提升操作。）
i = 2: expected_energy_levels[2] = 2，而 expected_energy_levels[1] = 5。2 <= 5。不需要额外操作，total_operations 保持 5。（cluster[2] 的能耗要求是 2，可以通过之前覆盖 cluster[1] 到 5 的操作来满足。）
i = 3: expected_energy_levels[3] = 0，而 expected_energy_levels[2] = 2。0 <= 2。不需要额外操作，total_operations 保持 5。
i = 4: expected_energy_levels[4] = 6，而 expected_energy_levels[3] = 0。6 > 0。 total_operations += (6 – 0) = 6。现在 total_operations = 5 + 6 = 11。（从 cluster[4] 开始，又进行了 6 次新的能耗提升操作。）

最终，我们得出最少需要 11 次操作才能达到目标能耗状态。

这个方法的时间复杂度是线性的，即 $O (N)$ ，其中 N 是服务器集群的数量。空间复杂度是 $O (1)$ ，因为它只需要几个变量来存储中间状态。这种高效且逻辑清晰的解法，在亚马逊这种注重效率的场景下是非常理想的。