最近 Amazon OA 2026 已經開始陸續放量，時間點主要集中在 1 月下旬到 2 月初。從整體體驗來看，今年的 OA 延續了 Amazon 一貫的出題風格：題目是新殼，但底層模型並不陌生，更看重的是你能不能快速把問題抽象成標準解法，而不是會不會某一道偏門技巧。這場 OA 一共兩道題，我這場大概 15 分鐘左右就全部 AC。趁著記憶還清晰，簡單整理一下題目和思路，給後面準備 Amazon OA 的同學做個參考。
Q1：Longest Same-Speed Segment
給定一個選手速度陣列，你最多可以刪除 k 個選手，問刪除之後，陣列中能得到的「速度完全相同的最長連續段」長度是多少。注意這裡的“連續段”是刪除之後的結果，也就是說原陣列中間可以夾著別的速度，但你可以選擇刪掉它們。
解題思路
這道題其實本質是“按值分組 + 在下標上滑窗”的經典模型。關鍵在於觀察：我們關心的其實是“某一個固定速度 v 能做到多長”。對於同一個速度，只需要記錄它在原陣列中出現的所有下標位置。
具體做法是先用 hashmap，把每個速度對應的所有下標存起來。然後對每個速度的下標陣列用滑動視窗，視窗表示“選擇這些下標作為保留的同速選手”。在視窗內部，需要刪除的其他速度數量可以用公式計算：視窗最後一個下標減去第一個下標再加一，減去視窗內元素個數。如果這個值不超過 k，就說明這個視窗可行。維護視窗長度的最大值，遍歷所有速度後取最大值即可。
本質上，這題是在下標軸上，最多允許刪 k 個“雜質”，求能拉出多長的同值連續區間。
Python 參考程式碼
from collections import defaultdict
def longestSameSpeedSegment(speeds, k):
pos = defaultdict(list)
for i, v in enumerate(speeds):
pos[v].append(i)
ans = 0
for indices in pos.values():
left = 0
for right in range(len(indices)):
# 需要刪除的數量
while indices[right] - indices[left] + 1 - (right - left + 1) > k:
left += 1
ans = max(ans, right - left + 1)
return ans時間複雜度是 O(n)，這是非常典型的 Amazon OA 接受解法。
Q2：Special Nodes in Tree
給定一棵樹，以及三個指定節點 x、y、z。對於樹中的每一個節點，計算它到 x、y、z 的距離。如果這三個距離排序後能構成一個勾股三元組（a² + b² = c²），則稱這個節點是特殊節點。問一共有多少個特殊節點。
解題思路
這題核心只有兩個點：樹上 BFS 就是最短路，每個節點只需要知道它到 x、y、z 的距離。
具體做法是分別從 x、y、z 出發，各做一次 BFS，得到三個陣列：distX[i]、distY[i]、distZ[i]，表示每個節點到三個指定節點的距離。然後對每個節點 i，取出這三個距離，排序後判斷是否滿足 a² + b² = c²，如果滿足就計數。因為樹的邊權都是 1，所以 BFS 得到的就是最短路，整體複雜度 O(n)，空間消耗也完全可控。
整體複雜度 O(n)，空間也完全可控。
Python 參考程式碼
from collections import deque
def bfs(start, graph, n):
dist = [-1] * n
q = deque([start])
dist[start] = 0
while q:
u = q.popleft()
for v in graph[u]:
if dist[v] == -1:
dist[v] = dist[u] + 1
q.append(v)
return dist
def countSpecialNodes(n, edges, x, y, z):
graph = [[] for _ in range(n)]
for u, v in edges:
graph[u].append(v)
graph[v].append(u)
dx = bfs(x, graph, n)
dy = bfs(y, graph, n)
dz = bfs(z, graph, n)
cnt = 0
for i in range(n):
d = sorted([dx[i], dy[i], dz[i]])
if d[0] >= 0 and d[0] * d[0] + d[1] * d[1] == d[2] * d[2]:
cnt += 1
return cntFAQ｜Amazon OA 常見問題
Amazon OA 一般多久出結果？沒訊息是不是就掛了？
這個問題幾乎是每一輪都會被問到。實際體驗是，Amazon 的 OA 結果推進節奏非常依賴批次和 headcount，有的候選人幾天內就能收到下一步，有的則會間隔一到兩週。如果你 OA 是全 AC，但短時間內沒有任何動靜，更多時候是流程優先順序或者 HC 調整的問題，並不一定代表已經被淘汰。一個比較明顯的訊號是，真正被系統或 recruiter 標記為繼續推進的候選人，流程通常不會被無限期擱置。
OA 一定要全 AC 才有後續嗎？
說結論會比較現實一些。對於 Amazon 來說，尤其是 New Grad 或 Early Career 批次，全 AC 的透過機率明顯更高。並不是說少過一兩個 hidden case 就一定沒機會，但從大量面經反饋來看，全 AC 基本相當於進入 Tech Screen 或 VO 的“入場券”。OA 在 Amazon 的篩選權重確實非常高。
題目做出來了，但程式碼不夠優雅，會有影響嗎？
在 OA 階段，Amazon 更關注的是程式碼是否穩定、是否正確，以及是否覆蓋了邊界情況。只要時間複雜度在合理範圍內，不存在明顯 bug，邏輯自洽，基本不會因為你沒有寫出最優雅或最短的程式碼而被卡。OA 更像是在驗證你能不能在有限時間和壓力下寫出可用、可維護的程式碼，而不是炫技。
Amazon OA 常見題型應該怎麼準備？
從最近幾輪 OA 的題型來看，出現頻率最高的還是滑動視窗、雙指標、BFS 或 DFS、基於 HashMap 的建模，以及一些狀態不復雜但需要抽象能力的 DP。相比無目的地刷題，更重要的是訓練自己在讀完題目的一兩分鐘內，能不能快速把問題歸類到一個熟悉的模型中，這一點往往比題量更關鍵。
沒有 refer，只靠海投和 OA 還有機會嗎？
答案是肯定的。Amazon 是少數幾家 OA 權重極高的公司之一，只要簡歷基礎不拉胯、OA 表現足夠穩定，即使沒有 refer，也完全有機會被直接撈進後續流程。在很多實際案例中，OA 的表現比 refer 更能決定你能走多遠。
OA 最容易翻車的地方在哪裡？
最常見的情況並不是演算法不會，而是題意沒有完全吃透就開始寫，或者在複雜度和邊界條件上掉鏈子。比如沒有考慮空輸入、極小規模的資料，或者在滑動視窗和 BFS 中不小心寫出隱性超時。Amazon 的 OA 並不介意你多花一點時間想清楚，但非常容易因為“寫得快但不穩”而直接被篩掉。
關於大廠 OA
如果你想在 OA 階段少踩坑、提高透過率，尤其是面對時間有限的情況下還需要保證準確率，提前有一套專業實時助攻方案真的能省掉不少焦慮。Programhelp 支援遠端、無痕、全程指導，讓你在自己電腦上就能順利完成 OA，適合準備 Amazon、Microsoft、Snowflake 等大廠的同學。
