最近覆盤了一場 Citadel SWE 的面試，說實話整體強度挺真實的。不是那種花裡胡哨的刁鑽題，但每一步都很貼近實際交易系統場景。Coding 更偏工程思維，Behavioral 挖得也很深。如果只按刷題思路準備，多少會有點吃力。下面按模組聊聊。
Coding：Order Book 設計
這題是一個簡化版的訂單簿設計。輸入的資料包含四個欄位：exchange_id、price、quantity、order_type（bid 或 ask）。要求設計一個類，支援訂單實時插入，並實現兩個核心方法。
第一個是 get_exchange_bbo。傳入某個 exchange_id，返回這個交易所當前的最高買價和最低賣價。
第二個是 get_nbbo。返回全市場範圍內的最高買價和最低賣價，也就是所有交易所綜合之後的最優報價。
這類題本質不難，關鍵是你怎麼選資料結構，是否貼近真實場景。
思路：
核心就是圍繞“如何快速拿到最優買價和賣價”來設計結構。因為有多個交易所，可以先用一個 HashMap 按 exchange_id 做分組，每個交易所對應一個獨立的 OrderBook。每個 OrderBook 內部分成買單和賣單兩塊：買單用 MaxHeap 維護，堆頂就是最高買價；賣單用 MinHeap 維護，堆頂就是最低賣價。這樣訂單插入是 O(log N)，查詢單個交易所的最優報價是 O(1)。
get_exchange_bbo 只需要讀取對應交易所兩個堆的堆頂即可；get_nbbo 則遍歷所有交易所的最優買賣價，選出全域性最高和最低，複雜度 O(E)，因為交易所數量通常不多，這一步開銷很小。如果面試官追問擴充套件場景，比如訂單取消或修改，可以補充 Heap 不方便刪除中間元素，實際工程中可以用 TreeMap 或紅黑樹來支援 O(log N) 的插入和刪除，這種 trade-off 思考會是加分點。
Behavioral 環節
這一輪其實挺關鍵的，大概二十分鐘左右，追問密度不低。面試官會圍繞簡歷深挖，比如你為什麼選這個技術，而不是另一個？系統最大的瓶頸是什麼？當時怎麼定位問題？有沒有評估其他方案？
Ownership 是重點。他們會透過細節問題判斷你是不是核心參與者。如果專案不是自己真正主導的，基本幾輪追問下來就會露餡。Technical depth 也很重要。你是否真的理解自己做過的系統，而不是停留在表面。另外一個點是表達能力。能不能把複雜的系統講清楚，用比較直白的話說明白你的設計思路，這一點影響很大。
整體感受
Coding 不算難，但很工程化。不是刷題型那種套路題，而是偏真實系統建模。Behavioral 壓力不小，尤其是連續細節追問的時候，需要思路清晰，不能亂。
如果最近在準備 Citadel SWE 或者 HFT / 交易系統相關崗位，建議把 Order Book 基本結構、撮合邏輯、以及資料結構 trade-off 好好梳理一遍。工程思維真的比刷題數量重要。需要更多真題或者想了解面試輔助服務請 聯絡我們。
