很多同學在準備 Bloomberg 或 FinTech（金融科技）類公司面試時，往往會陷入一個誤區：拼命刷 DP（動態規劃）和 Graph（圖論）難題。
但在 oavoservice 協助候選人復盤的過程中，我們發現 Bloomberg 的技術面有一種「詭異」的風格：題目看似不難，但對「程式碼潔癖」和「工程邏輯」的要求高得離譜。
今天我們就拆解兩道 Bloomberg 面試中的「試金石」題目。它們不考演算法的奇巧淫技，考的是你是否具備生產環境的 Coding 意識。
題目一：括號匹配的「語義陷阱」（Redundant Parentheses）
題目描述
一般公司只考「括號是否匹配」（LeetCode Easy 級別），但 Bloomberg 會追問：「是否存在冗餘括號？」
場景示例
((a + b))→ Redundant（多包了一層，沒有意義）(a + (b * c))→ Valid（括號改變了優先級或邏輯）(a)→ Redundant（單一變數不需要括號）
常見掛點
很多人只用 Stack 机械通過了 Valid Parentheses 的測試，卻忽略題目隱含的語義判斷。一旦被問到「如何定義冗餘」，就會答不清楚。
oavoservice 滿分思路
這題核心不在「用堆疊」，而在 「表達式是否有意義」。
工程視角：括號存在的唯一意義是改變運算優先級或包裹有效表達式。
做法：使用 Stack。當遇到右括號 )，開始 Pop 直到遇到左括號 (。
關鍵判斷：如果 Pop 的過程中沒有遇到任何運算子（operator），代表括號內是空的或只是包住單一變數——這就是冗餘括號。
面試官潛台詞：我招的是能寫 Clean Code 的人，不是只會複製模板的人。
題目二：多源匯率聚合（Real-time Exchange Rate Aggregation）
題目描述
這是非常經典的 FinTech 場景縮影：多個銀行（Banks）不斷上報貨幣對（Currency Pair）的匯率。
- Bank A 上報
USD-CNY: 7.2 - Bank B 上報
USD-CNY: 7.25 - Bank A 更新
USD-CNY: 7.22（覆蓋舊值）
要求：實作一個類別，支援 addRate，並能隨時透過 getAverage(currencyPair) 回傳該貨幣對在所有銀行中的平均匯率。
常見掛點
不少人直接寫 Map<Pair, List<Rate>>，每次查詢都遍歷 List 求平均。
結果：add 是 O(1)，但 getAverage 是 O(N)。
在金融讀多寫少（或高頻讀取）的場景下，讀性能太慢，直接不合格。
oavoservice 滿分思路
這題考的是「空間換時間」以及資料一致性。
建議維護三個 Map（或等價的巢狀結構）：
- Source of Truth：
Map<Bank, Map<Pair, Rate>>—— 記錄每家銀行最新值，方便去重與覆蓋。 - Aggregation：
Map<Pair, Sum>—— 維護總和。 - Counter：
Map<Pair, Count>—— 維護銀行數量。
在 addRate 時：
- 若該銀行之前上報過：Sum 先減舊值、再加新值（Count 不變）
- 若該銀行第一次上報：Sum 加新值、Count + 1
面試官潛台詞：能想到「增量更新」與「覆蓋語義」，代表你理解真實交易系統，而不是死背演算法。
總結：如何搞定「工程感」面試？
Bloomberg 不要求你手寫紅黑樹，但要求你：
- 程式碼要「穩」：邊界條件（例如除以零、空值）要處理完善
- 邏輯要「順」：每個設計決策（例如為何用 Map）都要講得通
如果你覺得「會做題但不會講、工程感不夠」是阻礙，oavoservice 也能提供面試準備與即時輔助。