在北美 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 的專家團隊，已經替你把所有坑踩完。
你只需要，在關鍵時刻，做對選擇。
