亞馬遜面試策略：真題解答與OA面經

亞馬遜面試準備：問題與OA演練

亞馬遜（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等，看看是否有已經參與過您即將需要參加的崗位的面試經驗分享，或者找有經驗的老師、學長進行請教，甚至模擬，面试辅助而生的平台，通过我们在大厂在职的成员以及以往代面过程中所积累的真题经验，能帮你获得更高的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)$ ，因为它只需要几个变量来存储中间状态。这种高效且逻辑清晰的解法，在亚马逊这种注重效率的场景下是非常理想的。