近期 Amazon 再次開啟大規模 Online Assessment 發放，本輪 OA 統一使用 HackerRank 平台。不少同學在做完之後的共同感受是：題目本身並不偏難，但一旦理解偏差，後續代碼幾乎無法挽回。今天來對 Amazon OA 的兩道 Coding 題進行系統性複盤，幫助後續參加 OA 的同學提前建立正確預期。
Amazon OA 基本資訊概覽
- 測試平臺：HackerRank
- 題目數量：2 道 Coding
- 整體難度：中等偏上
- 主要考察能力：
- 複雜業務規則的快速抽象
- 動態資料結構的使用能力
- 貪心策略是否合理
- 對隱藏約束和邊界條件的敏感度
第一題：伺服器分配與 Cost 計算問題
題目背景
系統中存在若干臺伺服器，每臺伺服器擁有一定數量的空閒例項。伺服器狀態以陣列形式給出，陣列下標代表伺服器編號，數值代表當前可用例項數量。
現在有 m 位客戶依次到來，每一位客戶都需要選擇一台服務器租用一個實例。服務器的狀態會隨著客戶的選擇不斷發生變化。
分配與 Cost 規則
對每一位客戶，系統會執行如下操作：
- 在當前所有伺服器中，選擇 空閒例項數量最多 的伺服器
- 成功選擇後，該伺服器的空閒例項數量減 1
- 本次選擇會產生一個 cost，其計算方式為：
- cost = 選擇前，當前所有伺服器中的最小空閒例項數 + 最大空閒例項數
最終要求輸出：在 m 位客戶完成分配之後，所有 cost 的累計總和。
解題本質分析
這是一道非常典型的 Amazon 風格題目，本質並不是考察複雜演算法，而是考察候選人是否能夠：
- 快速識別這是一個 動態維護最大值和最小值的問題
- 在多次更新場景下，避免使用低效的全陣列掃描
在 ProgramHelp 的輔導過程中，這道題的主要失分原因集中在三個方面：
- 沒有意識到 cost 必須在「選擇之前」計算
- 每一輪透過遍歷陣列尋找最大/最小值，導致時間複雜度過高
- 沒有正確處理例項數量減到 0 後的伺服器狀態
正確解題方向
這類問題的標準解法是使用堆結構 來維護伺服器狀態：
- 使用最大堆動態維護當前空閒例項最多的伺服器
- 同時維護當前最小空閒例項值（可透過最小堆或額外計數結構）
每一輪操作只需要：
- 取最大值
- 記錄當前最大與最小
- 更新伺服器狀態並重新入堆
只要資料結構選擇正確，整體實現是穩定且可控的。
第二題：Log 零件與 Warehouses 分配最大化問題
題目背景
系統中存在多個 log delivery，每個 log 對應一定數量的零件（parts）。現在有 k 個 warehouses，其中 k 為偶數。
儲存規則如下：
- 每個 warehouse 只能儲存來自 同一個 log 的零件
- 同一個 log 的零件可以被分散儲存到多個 warehouse
- 允許存在部分 log 的零件最終未被任何 warehouse 儲存
排序與目標約束
當所有 warehouse 完成儲存後：
- 按照每個 warehouse 儲存的零件數量進行排序
- 排名前
k/2的 warehouse 被認為是“存儲最多的一半” - 排名後
k/2的 warehouse 被認為是“存儲最少的一半”
題目要求輸出：
後半部分（儲存最少的 k/2 個 warehouse）中，零件數量之和的最大可能值。
解題核心難點
這道題的難點並不在於實現，而在於對目標的理解。
很多同學會下意識地想要“儘量多存零件”，但真正的最佳化目標並不是總儲存量，而是：
在排序之後，儘可能抬高後半部分 warehouse 的總和。
這意味著：不能讓前半部分 warehouse 吃掉過多零件，分配策略必須盡量均衡，同時滿足單 warehouse 只能來自同一 log 的限制。
為什麼很多 Amazon OA 會選擇專業助攻？
在 ProgramHelp 的真實案例中，很多同學的問題並不是“完全不會寫”，而是：OA 時間不足，來不及試錯，題目規則復雜，容易在細節處踩坑，平台限制嚴格，一次失誤直接淘汰。
Amazon OA 的本質是篩人而不是教學。在這種情況下，選擇穩定、經驗成熟的面試支持，往往比單純“再刷幾道題”更有效。
