一位剛結束 Amazon New Grad SDE loop 的同學來做了完整覆盤。三輪結構很典型：一輪純 Coding、一輪純行為面（Behavioral），還有一輪 Coding + BQ 混合。題目本身都不算難，但整個 loop 下來能明顯感覺到一件事——考察的深度在逐輪抬高。他們不只看你能不能做出來，更看你表達是否清晰、思考是否系統、對 Leadership Principles（LP）的理解是否真的內化。下面按輪次拆開講，附上三道題的完整 Python 程式碼和一份 LP→STAR 對應表。
面試概況
| 項目 | 詳情 |
|---|---|
| 公司 | Amazon |
| 職位 | SDE（New Grad / 新鮮人） |
| 輪次 | 3 輪：1 純 Coding + 1 純 BQ + 1 混合 |
| 單輪時長 | 40–45 分鐘 |
| 題目難度 | LeetCode Easy–Medium，高頻標準題 |
| 核心考點 | 表達清晰度 + 系統化思考 + LP 內化 + STAR 結構 |
第一輪：純 Coding（2 題 / 45 分鐘）
非常 Amazon 的效率——寒暄兩句就直接進 livecode，兩道題塞進 45 分鐘。
題目 1：驗證回文串 II（刪一個字元）
給一個字串，問最多刪除一個字元後能否變成回文串。
思路
雙指標從兩端向中間收縮。字元相等就繼續；一旦不相等，就有兩種「補救」機會——要麼刪左指標的字元，要麼刪右指標的字元。只要其中任一段是回文，整體就成立。用一個 helper 判斷某個區間是否為回文即可。
面試官追問的邊界：空字串（視為回文）、單字元（回文）。
Python 解法
def valid_palindrome_ii(s: str) -> bool:
"""最多刪除一個字元，判斷能否構成回文串。"""
def is_palindrome(left: int, right: int) -> bool:
while left < right:
if s[left] != s[right]:
return False
left += 1
right -= 1
return True
i, j = 0, len(s) - 1
while i < j:
if s[i] != s[j]:
# 遇到第一處不匹配：嘗試刪左邊字元 或 刪右邊字元
return is_palindrome(i + 1, j) or is_palindrome(i, j - 1)
i += 1
j -= 1
return True # 空字串 / 單字元 / 本身已是回文
時間複雜度：O(n)，最多觸發一次 helper 的線性掃描。 空間複雜度：O(1)。
題目 2：插入區間並合併
給一組已按起點排序、互不重疊的區間，再給一個新區間，要求把它插入並合併所有重疊部分，回傳新的區間列表。
思路
一趟線性掃描，分三段處理：
- 把所有完全在新區間左側（
end < new_start）的區間原樣加入結果。 - 把所有與新區間重疊的區間和新區間合併：不斷用
min更新起點、max更新終點。 - 把剩下完全在右側的區間原樣接上。
面試官追問「為什麼不用二分搜尋定位插入點」——答：這題需要的是把重疊段合併掉，仍要線性掃描一遍重疊段。線性一趟掃描邏輯更直觀、更穩，二分只能省下定位那一步，整體複雜度沒變，反而容易在邊界上出錯。
Python 解法
def insert_interval(intervals, new_interval):
"""在有序不重疊區間中插入 new_interval 並合併重疊部分。"""
result = []
new_start, new_end = new_interval
i, n = 0, len(intervals)
# 1) 完全在新區間左側的，直接加入
while i < n and intervals[i][1] < new_start:
result.append(intervals[i])
i += 1
# 2) 與新區間重疊的，逐個合併
while i < n and intervals[i][0] <= new_end:
new_start = min(new_start, intervals[i][0])
new_end = max(new_end, intervals[i][1])
i += 1
result.append([new_start, new_end])
# 3) 剩下完全在右側的，直接接上
while i < n:
result.append(intervals[i])
i += 1
return result
時間複雜度：O(n)，一趟掃描。 空間複雜度：O(n)，用於存放結果。
第二輪：純行為面（3 題 / 40 分鐘）
這一輪由一位 EM（Engineering Manager）主導，全程 LP 驅動。Amazon 的 BQ 不是走過場，面試官會順著你的回答一層層往下挖細節，看你講的是不是真事、當時到底怎麼判斷的。
問題 1：講一次你和同事或主管意見不合的經歷
對應 LP：Have Backbone; Disagree and Commit。
覆盤同學講的是「因為一個相依沒到位、堅持延後上線」的故事：用資料說明按原計畫上線的風險，充分表達了反對意見；但當決策被上級推翻後，他選擇 commit，全力配合執行。面試官真正在看的，是你有沒有真的聽進對方的觀點、之後能不能協作推進，而不是一味堅持自己。
問題 2：Ownership
講一次你主動扛起了職責範圍之外的事。覆盤同學講的是一次線上事故：他排查日誌、修復了髒資料，還順手補上了監控告警。面試官追問：「你是先申請許可，還是直接就上手做了？」他的回答是：「我先把問題清楚地同步給了相關的人，確保大家都知情，然後就主動接手了。」——既體現了主人翁意識，也沒有變成擅自行動。
問題 3：Failure
講一次失敗。覆盤同學講的是自己高估了負載、導致服務崩潰的經歷，重點講了事後如何做覆盤（retrospective）、整理出改進的 action items。Amazon 想看的是你如何直面失敗，而不是把一件失敗的事包裝成「其實也不算失敗」。這一點很關鍵——試圖淡化失敗，反而會被扣分。
第三輪：混合（2 BQ + 1 Coding）
面試官是一位年輕、語速偏快的工程師。前半段兩道 BQ，後半段一道字串題。
BQ 1：Earn Trust
覆盤同學講的是在一個前端專案裡引入型別系統的經歷。起初被同事認為是過度設計（overengineering），他透過後續可維護性的提升和交付效率的資料證明了價值。面試官追問：「如果他們還是不認同呢？」——他的回答很成熟：「我會先問清楚，在他們眼裡成功長什麼樣，然後圍繞這個結果去對齊，而不是糾結在具體實作方式上。」
BQ 2：Invent and Simplify
講一次你用創新的方式簡化了流程。覆盤同學講的是自己做了一個自動化工具，把 API 文件和程式碼生成打通。面試官追問：「你怎麼衡量它的效果？」——答：對比了手動流程的耗時和工具節省下來的時間，用量化指標說話。
Coding：字串解碼
這一輪的程式題是字串展開。這裡用 LeetCode 394 的經典形式：把 3[a]2[bc] 解碼成 aaabcbc，3[a2[c]] 解碼成 accaccacc。
思路
用堆疊來處理巢狀結構。走訪字串：
- 遇到數字：累計多位數字（可能不只一位）。
- 遇到
[：把「當前已拼好的字串」和「當前的重複次數」分別壓入兩個堆疊，然後重置，進入新一層。 - 遇到
]：從堆疊裡彈出重複次數和上一層的字串，把當前層字串重複相應次數後，接到上一層後面。 - 遇到字母：直接追加到當前層字串。
用兩個堆疊：一個存字串片段，一個存重複倍數。
面試官很吃「主動寫測試案例」這一套，還追問了時間/空間複雜度的權衡。
Python 解法
def decode_string(s: str) -> str:
"""解碼形如 3[a]2[bc] 的編碼字串（LeetCode 394）。"""
num_stack = [] # 存重複次數
str_stack = [] # 存進入當前層之前已拼好的字串
current = "" # 當前層正在建構的字串
num = 0 # 當前累計的數字（支援多位）
for ch in s:
if ch.isdigit():
num = num * 10 + int(ch) # 處理多位數字，如 12[a]
elif ch == '[':
num_stack.append(num) # 儲存重複次數
str_stack.append(current) # 儲存上一層已有內容
num = 0
current = ""
elif ch == ']':
repeat = num_stack.pop()
prev = str_stack.pop()
current = prev + current * repeat # 展開當前層並拼回上層
else:
current += ch # 普通字母
return current
時間複雜度：O(N)，N 為解碼後輸出字串的總長度（每個輸出字元建構一次）。 空間複雜度：O(N)，堆疊深度與巢狀層數、輸出長度相關。
LP → STAR 對應表
Amazon 的 BQ 本質是「用一個真實故事，證明你身上有某條 LP」。建議每條 LP 至少準備 1–2 個故事，並嚴格按 STAR 結構組織：Situation（背景）→ Task（任務）→ Action（行動）→ Result（結果，最好帶量化指標）。
| 面試問題 | 對應 LP | STAR 關鍵點 |
|---|---|---|
| 和同事/主管意見不合 | Have Backbone; Disagree and Commit | Situation：相依未就緒風險；Action：用資料表達反對，被推翻後全力 commit；Result：如期協作落地 |
| 主動扛起分外之事 | Ownership | Situation：線上事故；Action：查日誌、修髒資料、補監控，先同步再接手；Result：恢復並預防復發 |
| 一次失敗 | Learn and Be Curious / Deliver Results | Situation：高估負載致崩潰；Action：做覆盤、列 action items；Result：直面問題並沉澱改進 |
| 說服他人接受你的方案 | Earn Trust | Situation：引入型別系統被質疑過度設計；Action：用可維護性 + 交付效率的資料證明；Result：對齊「結果」而非「實作」 |
| 用創新簡化流程 | Invent and Simplify | Situation：文件與程式碼脫節；Action：做自動化工具打通生成；Result：對比手動 vs 工具耗時，量化收益 |
備考策略
Amazon 的題型這些年變化不大，但細節的深度、推理的完整度、以及對 LP 的內化程度在持續抬高。三點建議：
- BQ 不是講故事，是結構化思考。 很多人以為行為面就是把經歷講得動聽，但 Amazon 想看的是 STAR + 量化指標——用結構去解釋你的選擇、行為和判斷。每條 LP 備 1–2 個故事，先寫 bullet，再練口述，最後模擬被追問的場景（「你當時為什麼這麼判斷？」「怎麼衡量效果？」）。
- Coding 是標準化高頻題。 雙指標、區間、堆疊這類 pattern 反覆出現。做出來只是底線，真正加分的是：能講清邏輯、能主動說改進方向、能報出時間/空間複雜度、能主動寫測試案例覆蓋邊界。
- 主動覆蓋邊界。 空字串、單字元、多位數字、空區間——面試官幾乎一定會問。與其等他問，不如你先說出來。
FAQ
Q1：Amazon New Grad SDE 一般幾輪？難度如何？
通常是 3–4 輪的 loop（本次是 3 輪），常見結構是純 Coding、純 BQ、以及 Coding+BQ 混合。題目多為 LeetCode Easy–Medium 的高頻標準題，純難度並不高，但對表達清晰度和 LP 理解的要求逐輪上升。
Q2：Amazon 的 BQ 到底在考什麼？
考的是你身上有沒有對應的 Leadership Principles，以及你能不能用結構化的方式把真實經歷講清楚。面試官會順著回答往下挖細節，判斷故事是否真實、你當時的判斷依據是什麼。用 STAR 組織、帶上量化結果，比把故事講得華麗重要得多。
Q3：講「失敗」的時候，是不是應該挑一個「其實還好」的例子？
不建議。Amazon 明確想看你如何直面真正的失敗——如何覆盤、如何沉澱改進。把失敗包裝成「其實不算失敗」反而暴露了你不願正視問題，通常會被扣分。選一個你真的搞砸過、但事後有實質改進的例子。
Q4：Coding 題做出來了，為什麼還可能被拒？
因為「做出來」只是底線。面試官同時在評估：思路表達是否清晰、有沒有主動分析複雜度、有沒有主動寫測試案例覆蓋邊界、面對 follow-up（比如「為什麼不用二分」）能不能給出有說服力的權衡。溝通和工程判斷力和正確性同等重要。
Q5：區間插入這種題，用二分搜尋會更好嗎？
定位插入點確實可以用二分，但這題的核心是把重疊區間合併掉，仍然要線性掃描一遍重疊段。線性一趟掃描邏輯更直觀、邊界更穩；二分只省下定位那一步，整體複雜度沒變，還更容易寫錯。面試裡能講清這個權衡，本身就是加分項。
正在準備 Amazon SDE 的面試？ 如果你想在 Coding 的表達細節和 BQ 的 STAR 結構上更從容，我們可以幫你做針對性的模擬面試和 LP 故事打磨。
立即加入微信 Coding0201，取得 Amazon 高頻題庫與 LP/STAR 精修。
聯絡方式
- 微信：Coding0201
- Email：[email protected]
- Telegram：@OAVOProxy