亞馬遜SDE II面試完整經歷：從在線評估到拿offer的全流程復盤

背景介紹

先說一下我的基本情況：本科和碩士都在國內讀的計算機，畢業後在一家中型互聯網公司做了4年後端開發，技術棧主要是Java和Go，日常涉及微服務架構、分佈式系統、消息隊列這些。說實話，在原公司幹得還行，但總覺得天花板明顯，加上一直有去海外工作的想法，就開始看Amazon的機會。

2025年9月，我在LinkedIn上看到Amazon上海office的SDE II崗位在招人，同時Seattle也有對應的headcount。猶豫了一下，最後兩個都投了——想著如果上海能成也不錯，Seattle的話更是夢寐以求。投完簡歷大概兩週後收到recruiter的郵件，說通過了簡歷篩選，讓我先做OA（Online Assessment）。

說實話，準備Amazon面試的過程比我想像中要長得多。算法要刷，系統設計要練，但最讓我意外的是Amazon Leadership Principles（LP）行為面試的權重——幾乎每一輪都穿插著LP問題，這在國內公司的面試裡幾乎不會遇到。我花了大概6週時間準備，下面按時間順序把整個面試流程完整復盤一下。

在線評估（OA，2道題，120分鐘）

收到OA連結後，系統給的時間是120分鐘內完成2道算法題。OA是在HackerRank平台上做的，可以選語言，我選了Java。

第一題：日誌聚合與分析

題目大致是：給定一個伺服器日誌文件，每條日誌包含timestamp、serverId、responseTime、statusCode四個欄位。要求實現一個函數，統計每個server在指定時間窗口內的平均響應時間，並按平均響應時間從高到低排序返回。如果平均響應時間相同，按serverId升序排列。

這題不算難，本質上是分組聚合+排序的問題。我用HashMap按serverId分組，計算每個server的平均響應時間，然後自定義Comparator排序。大概15分鐘寫完，跑了一下test cases全部通過。

第二題：任務調度器

題目是經典的LeetCode 621變體：給定一個任務列表和冷卻時間n，求完成所有任務所需的最短時間。不過這題加了一個額外條件——部分任務之間有依賴關係，必須在某個任務完成後才能執行另一個。

這個依賴關係的處理讓我卡了一會兒。我先用拓撲排序處理依賴，確定了任務的執行順序約束，然後再用貪心策略安排執行時間。說實話這個思路我一開始沒想清楚，在紙上畫了好幾分鐘才理順。最後寫出來的代碼比較長，大概40多行，test cases過了80%——有兩個edge case沒處理好，時間不夠了就沒繼續調。

OA結果：3天後收到recruiter郵件，說OA通過了，約了後續的virtual onsite面試時間。一共4輪，安排在兩天內完成。

第1輪 LP行為面+算法（約55分鐘）

面試官是一位在Amazon工作了5年的SDE III，印度裔，口音比較重但語速適中，溝通還算順暢。

LP部分（約20分鐘）

他先問了兩個LP問題：

問題1：Tell me about a time when you went above and beyond for a customer.（對應LP：Customer Obsession）

我準備過這個，講的是之前公司做ToB項目時，客戶提了一個緊急的數據遷移需求，原本不在sprint scope裡，但我主動加了班，週末兩天把遷移腳本寫好並測試通過，週一就交付了。客戶非常滿意，後來還續約了。我用STAR方法回答，重點強調了為什麼客戶需要這個以及我的行動如何直接影響了客戶滿意度。

問題2：Tell me about a time when you had to make a decision without having all the information you needed.（對應LP：Bias for Action）

這個我講的是一次線上故障——凌晨2點收到告警，數據庫連接池耗盡，但當時沒有完整的日誌能定位根因。我根據經驗判斷是慢查詢導致連接洩漏，果斷先做了限流降級，然後再排查。結果判斷是對的，15分鐘恢復服務。面試官追問了"如果判斷錯了怎麼辦"，我說會先確保降級方案本身是安全的、可回滾的，然後快速驗證假設。

算法部分（約30分鐘）

題目：設計一個數據結構支持insert、delete和getRandom，三個操作都要求O(1)時間複雜度。

這是LeetCode 380原題，我之前刷過。HashMap + ArrayList的方案，insert時把元素加到list末尾並在map中記錄索引；delete時把要刪的元素和list末尾元素交換，然後刪除末尾，同時更新map中的索引。寫完代碼後面試官讓我走了幾個test case，又問了並發安全的問題——如果多線程同時操作怎麼辦。我說可以加ReentrantLock或者用CopyOnWriteArrayList，面試官點了點頭，沒繼續深追。

這一輪整體感覺不錯，LP回答流暢，算法也沒卡殼。

第2輪 系統設計（約55分鐘）

面試官是一位Senior SDE，華人，在Amazon AWS部門工作。這輪純系統設計，沒有LP。

題目：Design a URL Shortener（類似bit.ly）

這題算是系統設計的經典題了，但面試官的要求比我想像中更深入。我按照標準的系統設計框架展開：

1. 需求澄清：我問了讀寫比例（面試官說10:1讀多寫少）、是否需要自定義短鏈、是否需要分析統計、QPS預估等。面試官給了明確回答後我開始設計。

2. API設計：定義了createShortUrl(longUrl, customAlias?)和getLongUrl(shortUrl)兩個接口。

3. 核心方案：短鏈生成我提了兩種——base62編碼和MD5哈希截取。面試官讓我比較優劣，我分析了base62可讀性好但需要全局計數器（分佈式環境下有瓶頸），MD5哈希不需要協調但有衝突風險。最後我選了預生成batch ID的方案：用DynamoDB的原子計數器批量獲取ID段，本地分配後再base62編碼。

4. 存儲層：用DynamoDB存儲映射關係，shortUrl做partition key。面試官追問了緩存策略，我說用ElastiCache (Redis)做熱點短鏈的緩存，LRU淘汰。

5. 可擴展性：討論了如何通過增加partition和read replica來水平擴展。

卡殼的地方：面試官問了一個我沒準備過的問題——"如果某個短鏈突然變成熱點（比如某個大V分享了短鏈），如何防止緩存擊穿？"我想了一會兒，說可以用請求合併（request coalescing），即多個並發請求只放一個去DB查，其餘等待結果。面試官追問具體實現，我提到可以用一個並發標記（比如AtomicBoolean），但說實話講得不太清楚，感覺這部分回答得比較勉強。

整體來說這輪還行，但熱點緩存那塊確實暴露了我的準備不足。

第3輪 LP行為面+算法（約55分鐘）

面試官是一位在Amazon工作了3年的SDE II，美國白人，非常友善，這輪的氛圍比較輕鬆。

LP部分（約20分鐘）

問題1：Tell me about a time when you disagreed with a colleague's technical approach. How did you handle it?（對應LP：Have Backbone; Disagree and Commit）

我講的是之前和同事在技術選型上的分歧——他想用RabbitMQ，我主張用Kafka。我列舉了Kafka在我們場景下的優勢（高吞吐、持久化、回溯消費），同時也承認RabbitMQ在低延遲場景的優勢。最後我們做了一次benchmark對比，數據支持了我的方案，團隊決定用Kafka。面試官追問"如果最終決定不是你的方案呢"，我說"Disagree and Commit——我會全力執行團隊的決定，不會消極怠工"。

問題2：Tell me about a time when you delivered a result under a tight deadline.（對應LP：Deliver Results）

講的是去年雙11期間，我們組負責的訂單服務需要在3天內上線一個新功能。我拆解了任務，把非核心邏輯做成feature toggle先關掉，核心路徑先上線，然後逐步開放。最終提前半天完成，線上零故障。

算法部分（約30分鐘）

題目：給定一個二元樹，找到從根節點到葉子節點的所有路徑，使得路徑上節點值之和等於給定targetSum。返回所有符合條件的路徑。

LeetCode 113原題，DFS回溯。我很快寫完了遞迴解法，面試官讓我解釋時間複雜度——我說最壞情況O(N * H)，N是節點數，H是樹高（因為每條路徑需要拷貝）。面試官又問如果樹非常大、遞迴棧溢出怎麼辦，我說可以改成迭代版本用顯式棧，或者限制最大深度。這輪整體順利。

第4輪 LP行為面+算法（約55分鐘）

面試官是一位Principal Engineer，在Amazon幹了8年，氣場很強。這輪是我壓力最大的一輪。

LP部分（約25分鐘，這輪LP問得特別深）

問題1：Tell me about a time when you took ownership of a problem that wasn't technically your responsibility.（對應LP：Ownership）

我講的是一次跨組協作的故障——前端團隊反饋接口超時，但問題出在我們組的數據庫查詢上。雖然前端先找到我，我完全可以讓他們去提ticket給DBA，但我選擇自己先排查，發現是一條缺少索引的慢查詢。我直接加了索引並優化了SQL，30分鐘解決。面試官追問"你覺得這算是你的responsibility嗎"，我說"在Amazon的語境下，Ownership意味著看到問題就解決，而不是推給別人"。

問題2：Tell me about a time when you had to learn something new quickly to solve a problem.（對應LP：Learn and Be Curious）

講的是之前項目需要用gRPC，但我完全沒經驗。我花了一個週末看官方文檔和示例代碼，週一就能寫出proto定義和server/client端代碼了。面試官追問"你覺得學習新技術最大的挑戰是什麼"，我說"不是語法，而是理解它背後的設計哲學和適用場景"。

追問（這輪最難的LP問題）：面試官說"You mentioned you added an index to solve the slow query. What if that index caused other problems, like slower writes or increased storage? How would you handle that?"

這個問題讓我愣了幾秒。我說我會先在staging環境評估索引的影響，包括寫入延遲和存儲增長的監控數據，然後和DBA一起review。如果影響可接受就上線，如果不可接受就考慮其他優化方案（比如查詢改寫、分庫分表）。面試官似乎對這個回答還算滿意，但表情不太容易讀。

算法部分（約25分鐘）

題目：設計一個LRU Cache，支持get和put操作，都要求O(1)時間複雜度。

LeetCode 146原題，HashMap + 雙向鏈表。這題我太熟了，10分鐘寫完。但面試官加了一個follow-up：如何實現多線程安全的LRU Cache？

這個follow-up讓我有點措手不及。我說了兩種方案：一是整體加鎖（簡單但性能差），二是分段鎖（類似ConcurrentHashMap的思路，把cache分成多個segment，每個segment有自己的鎖）。面試官讓我寫分段鎖的偽代碼，我寫了個大概框架，但細節上有些地方不太確定——比如segment數量怎麼確定、resize時怎麼處理。面試官沒有繼續追問，只是說"interesting approach"。

這輪出來後我心情比較複雜，LP追問很深入，算法的follow-up也沒完全答好，感覺是四輪中最不確定的一輪。

面試真題匯總

以下是本次Amazon SDE II面試中遇到的所有題目，按輪次整理：

在線評估（OA）

題目1：日誌聚合與分析
考察點：HashMap分組聚合、自定義排序
難度：Medium

題目2：帶依賴的任務調度器
考察點：拓撲排序 + 貪心調度
難度：Medium-Hard

第1輪：LP行為面+算法

LP1：Customer Obsession — 超越客戶期望的經歷
LP2：Bias for Action — 信息不充分時做決策的經歷
算法：Insert Delete GetRandom O(1)
考察點：HashMap + ArrayList組合數據結構設計
難度：Medium

第2輪：系統設計

Design a URL Shortener
考察點：分佈式ID生成、DynamoDB存儲設計、緩存策略、熱點防擊穿
難度：Medium-Hard

第3輪：LP行為面+算法

LP1：Have Backbone; Disagree and Commit — 技術分歧的處理
LP2：Deliver Results — 緊急deadline下交付成果
算法：Path Sum II（二元樹路徑和）
考察點：DFS回溯
難度：Medium

第4輪：LP行為面+算法

LP1：Ownership — 承擔非自身職責的問題
LP2：Learn and Be Curious — 快速學習新技術的經歷
追問：Ownership的邊界與權衡
算法：LRU Cache + 多線程安全follow-up
考察點：HashMap + 雙向鏈表、並發控制（分段鎖）
難度：Medium（原題）/ Hard（follow-up）

心得體會與建議

面試結束後等了大概5個工作日，recruiter打電話通知我拿到了offer，是Seattle的SDE II，總包比我預期高一些。回顧整個面試過程，有幾點建議想分享給準備Amazon面試的朋友：

1. LP不是走過場，它是Amazon面試的核心
我之前以為LP行為面只是走個形式，但實際上面試官問得非常深入，而且會追問細節。建議至少準備6-8個不同場景的故事，每個故事覆蓋2-3個LP原則，用STAR方法組織。特別要注意數據量化——"提升了30%的響應速度"比"提升了響應速度"有說服力得多。

2. 算法題難度在LeetCode Medium左右，但要準備follow-up
Amazon的算法題不會特別難，但面試官幾乎都會加follow-up，比如並發安全、空間優化、邊界條件等。刷題時不要只追求AC，要理解每種數據結構的變體和擴展。

3. 系統設計要體現Amazon的技術棧偏好
面試中提到DynamoDB、ElastiCache、CloudWatch這些AWS服務會加分。當然不是說你要硬塞，而是如果你熟悉AWS生態，在方案選擇時自然地用上這些組件，面試官會覺得你更fit。

4. 面試是雙向選擇，保持真實
我在第4輪的LP追問中其實有些回答不夠完美，但都是真實的經歷和思考。Amazon的面試官很看重authenticity，編造的故事經不起追問。與其背模板，不如好好梳理自己的真實項目經歷。

FAQ

Q1：Amazon SDE II面試一般有幾輪？
通常是OA + 4輪virtual onsite。4輪中一般是1輪純系統設計，3輪LP+算法。部分候選人可能會有額外一輪bar raiser，但我的面試中沒有遇到。

Q2：Amazon LP行為面到底有多重要？
非常重要。Amazon有一個說法叫"LP是面試的50%"，雖然不是精確的權重，但實際感受是LP和技術的比重幾乎對半。如果LP回答不好，即使算法全對也可能被拒。建議認真研究Amazon的16條Leadership Principles，每條至少準備1-2個故事。

Q3：OA沒滿分能過嗎？
可以。我的OA第二題只過了80%的test cases，但依然通過了。Amazon更看重你的解題思路和代碼質量，而不是單純的通過率。當然，如果兩題都只過了一半，那就可能比較懸了。

Q4：面試中可以用中文回答LP問題嗎？
如果你投的是上海office，部分面試官可能是華人，可以用中文溝通。但Seattle office的面試官基本都是英文，建議全程用英文準備和回答。即使面試官是華人，如果他用英文提問，你也應該用英文回答。

Q5：從面試到offer一般要等多久？
我的情況是面試後5個工作日出結果。但據我了解，Amazon的debrief meeting通常在面試後1-2週內舉行，之後recruiter會通知結果。如果超過兩週沒消息，可以主動發郵件跟進。