最近又有同學問到 Stripe OA ，題型依然是熟悉的那一套，整體來說變化不大。簡單給大家同步一下最新情況，方便準備這家公司面試的同學心裡有個底。
Stripe OA 基本形式
Stripe 的 OA 一直比較固定：
- 時長：60 min
- 題目數量：1 題
- 型別：Hard OOD（物件導向設計）
雖然只有一道題，但千萬不要被數量迷惑。這題 題面非常長、實現量也很大，基本屬於一邊讀題一邊設計類結構，同時還要快速完成程式碼實現，對 coding 速度和設計能力都有要求。好訊息是目前Stripe OA 題庫其實非常小。這家公司這麼多年下來，基本就反覆在出三套題，很多同學做過幾十套 OA 統計下來，也還是這幾道經典題輪換。
Stripe OA 獨家真題
這是一個多階段負載均衡器實現題，需要逐步實現 5 個部分的功能，核心是為每個 CONNECT 請求分配目標 Jupyter 伺服器，並記錄日誌，同時處理斷開和粘性路由等規則。
Part 1: 基礎負載均衡
- 目標：為新
CONNECT請求選擇當前連線數最少的伺服器；若數量相同，選索引最小的（索引從 1 開始）。 - 資料結構：需要維護每個伺服器的當前連線數
connections_count（陣列，長度為numTargets）。 - 輸出：對每個
CONNECT請求，返回connectionId,userId,targetIndex格式的日誌。
Part 2: 處理斷開連線
- 新增
DISCONNECT請求：根據connectionId找到其所在伺服器，將該伺服器連線數減 1。 - 資料結構：新增
connection_to_target字典，記錄每個connectionId對應的目標伺服器索引。 - 約束：
DISCONNECT僅針對已連線的connectionId。
Part 3: 基於 object ID 的粘性路由
- 新增約束：若多個
CONNECT請求指定相同 objectId，必須路由到同一臺伺服器，即使該伺服器當前負載更高。 - 資料結構：新增
object_to_target字典，記錄每個objectId繫結的目標伺服器索引。 - 邏輯：處理
CONNECT時，先檢查objectId是否已繫結伺服器；若已繫結，直接使用該伺服器；否則執行 Part 1 的負載均衡邏輯，並將objectId與選中伺服器繫結。
一點真實建議
Stripe OA 60分鐘一道題難點不在演算法，在於工程實現的能力。很多同學做這道題時最大的挑戰其實是時間管理。Stripe OA 我們帶過不少，對常見題型和實現思路都比較熟悉。如果你最近也在準備 Stripe 或類似的工程實現型 OA，希望考試時有人 幫你把控節奏、關鍵節點提醒、避免卡在細節上，也可以 聯絡我們 瞭解一下具體的準備方案。
END
