在北美 Tech 圈裡，Bloomberg 一直算是個“異類”。不走 FAANG 的刷題內卷路線，但 New Grad 的 TC 常年在 $170k–$200k，WLB 也相對穩定。很多人面 Bloomberg 翻車，並不是題不會，而是沒踩對評估點。OOD 權重極高，類的拆分、命名和職責邊界都會被細看；Think Aloud 是硬性要求，只寫不講基本直接扣分。題目也常帶變種，面試官會追問併發、異常處理和資料一致性。我們上週協助的一位 USC CS Master 學員就被這套體系卡過一次，後來針對 Bloomberg 風格系統調整，第二次 Phone Screen 順利透過。下面整理要點，供準備 Bloomberg 2026 NG 的同學參考。
真題重現：Design Underground System（表面 Medium，實際 OOD）
題目描述（高度還原）：
設計一個地鐵系統，支援：
- 乘客進站
checkIn(id, station, time) - 乘客出站
checkOut(id, station, time) - 查詢任一終點的平均通行時間
getAverageTime(start, end)
Bloomberg 面試中的隱性要求：
- 需要清楚區分「即時狀態」與「歷史統計」
- 需要能口頭討論並發與異常場景（即使程式碼不寫）
- 需要工業級命名與結構，而不是刷題式寫法
常見翻車點包括：
- 用一個 Map 硬塞所有數據，邏輯迅速失控
- 忘記處理重複 check-in / 非法 check-out
- 解釋不清楚為什麼是 O(1)
架構核心：雙 HashMap 解耦（Bloomberg 最愛）
這題的關鍵不在演算法，而在 資料建模。
設計原則
- Single Responsibility：
- 一個結構只負責「當前行程」
- 一個結構只負責「歷史統計」
- Write-Optimized：Bloomberg 更關心寫入效率與穩定性
資料結構拆解
check_in_map：- Key：userId
- Value：
(startStation, startTime) - 職責：只表示“正在發生的行程”
route_stats：- Key：
(startStation, endStation) - Value：
[totalTime, tripCount] - 職責：只做統計，不存個別資訊
- Key：
在真實面試中，能說一句： “I intentionally decouple in-flight trips from historical aggregates to keep responsibilities clean.” Impression 直接拉滿。
高品質實現（Python，面試可直接過 Review）
class UndergroundSystem:
def __init__(self):
# id -> (start_station, start_time)
self.check_in_map = {}
# (start_station, end_station) -> [total_time, trip_count]
self.route_stats = {}
def checkIn(self, id: int, stationName: str, t: int) -> None:
# In production, we might validate duplicate check-ins
self.check_in_map[id] = (stationName, t)
def checkOut(self, id: int, stationName: str, t: int) -> None:
if id not in self.check_in_map:
# Defensive coding: invalid checkout
return
start_station, start_time = self.check_in_map.pop(id)
route_key = (start_station, stationName)
duration = t - start_time
if route_key not in self.route_stats:
self.route_stats[route_key] = [0, 0]
self.route_stats[route_key][0] += duration
self.route_stats[route_key][1] += 1
def getAverageTime(self, startStation: str, endStation: str) -> float:
route_key = (startStation, endStation)
if route_key not in self.route_stats:
return 0.0
total_time, count = self.route_stats[route_key]
return total_time / count為什麼這版程式碼「像 Bloomberg 工程師寫的」？
- 命名即文檔：無需額外解釋變數含義
- O(1) 全覆蓋：所有介面都是 Hash 查找
- 狀態可預測：不會出現幽靈數據
面試官 Follow-up 高頻追問（90% 的加分點）
如果你程式碼寫完就停，大機率只是 Neutral。
Q1：如果是多執行緒環境怎麼辦？
答題方向：
- Python 可提
Lock/ Java 可提ConcurrentHashMap - 或說明：寫操作需要原子性，讀可以 eventual consistency
Q2：為什麼不用資料庫？
標準話術：
- 面試場景強調 in-memory latency
- 資料規模與訪問模式適合 HashMap
- 持久化是系統層面的擴充套件，而不是這道題的核心
Q3：如果 station 數量非常大？
加分點：
- 站點對是稀疏的
- 只記錄真實發生的路線
ProgramHelp 的價值：不是“幫你寫”，而是“幫你過”
很多人會說：
“這題我早就刷過了。”
但 Bloomberg 面試真正淘汰的是：
- 不會講設計的人
- 緊張狀態下表達崩盤的人
我們在實戰中做的不是代寫，而是：
- 實時提醒 OOD 結構是否偏離
- 即時修正英文表達與專業術語
- 在 Follow-up 環節給出可直接複述的話術
你在面試官眼裡呈現的，是一個：
思路清晰、表達成熟、像“提前一年轉正”的工程師
最後一句真心話
當一個 $180k+ 的 Offer 擺在你面前時， 真正昂貴的從來不是輔導費用， 而是 因為一個表達失誤而錯過的機會成本。
如果你不想在 Bloomberg、Meta、Apple 這種 OOD 重度公司“裸考”， ProgramHelp 的專家團隊，已經替你把所有坑踩完。
你只需要，在關鍵時刻，做對選擇。
