Citadel 跟大廠區別很大。不問LeetCode原題，不考八股。全程場景驅動，圍繞交易系統聊。面試官是寫交易系統的工程師，追問很深，會一直問到你不會為止。我順利透過 OA 與三輪 Onsite，以下是詳盡面經，包含 Citadel interview questions 、我的解答思路、面試官反饋以及備戰建議。
第一輪：OA + Tech Screen
OA（90分鐘） 兩道演算法 + 一道系統設計，時間很緊。
演算法1：滑動視窗極值
實時價格流，固定視窗大小，每次滑動一格，要求 O(n) 返回視窗內 max 和 min。
解法：兩個單調佇列（雙端佇列）分別維護最大值和最小值候選。
- 入隊時彈出不滿足單調性的元素；
- 出隊時判斷隊首是否滑出視窗。 重點處理視窗初始化和佇列為空的邊界。 寫完程式碼後補充了時間/空間複雜度說明（為什麼是 O(n) 而非 O(nk)），面試官很關注程式碼風格和註釋習慣。
演算法2：併發安全的訂單簿
支援多執行緒插入/刪除訂單、價格查詢、撮合。讀寫比約 7:3，高吞吐下保證一致性。
方案：
- 按價格檔位分段加讀寫鎖（std::shared_mutex），降低鎖競爭；
- 撮合跨價格層級時按固定順序加鎖防死鎖；
- 用無鎖佇列做寫入緩衝，後臺執行緒批次消費平滑延遲。 解釋了不用全域性鎖（會成為瓶頸）和完全無鎖（複雜度高易出錯）的原因。用了原子操作 + memory order（release/acquire）。
系統設計：低延遲日誌系統
交易系統產生海量日誌，不能阻塞主路徑，還需支援時間範圍/關鍵詞快速查詢。
分層儲存方案：
- 熱資料：記憶體 Ring Buffer + 預分配記憶體池，寫入 O(1)；
- 溫資料：mmap 檔案，利用 OS 頁快取，非同步批次刷盤，零複製；
- 冷資料：LSM-tree 壓縮儲存，適合查詢； 額外提到 sendfile 零複製。 說明不用傳統關係型資料庫的原因（B+樹隨機 IO 延遲高）。
Tech Screen（45分鐘）
自我介紹專案：學校做的分散式訊息佇列（Go）。 核心點：Topic 分片 + Raft 共識、sendfile 零複製、令牌桶背壓、WAL 持久化。
追問：
- 吞吐翻倍如何水平擴充套件？→ 一致性雜湊 + 動態再平衡，過渡期雙寫 + 冪等去重。
- 節點宕機如何不丟不重？→ WAL 保證不丟，訊息唯一 ID + 布隆過濾器 + Redis 消費者去重，實現 Exactly-Once 效果。
特別環節：用非技術語言解釋分散式鎖。
比喻：就像機場共享充電寶櫃子，每人掃碼拿唯一櫃門號，防止衝突。面試官認可，認為和 Trader/Quant 溝通時這種表達很重要。
小機率題：策略勝率 55%，盈虧比 1:1，交易 100 次，至少盈利 60 次的機率？ 用二項分佈 + 正態近似（μ=55，σ≈4.97），得出約 15%-18%。強調真實交易更看重風控和生存能力。
第二輪：Onsite（60分鐘）—— 全市場場景題
做市商場景 股票現價 100 美元，突然大額賣單砸盤，如何調整報價？
回答框架：
- 正常報價：理論中間價掛單，動態 spread + 量，庫存中性化；
- 訂單流監控：買/賣單到達率失衡時拉寬 spread、減量；
- 極端應對：立即撤買單、觸發熔斷、限倉，波動率上升後進一步保守。
Fermi 估算：曼哈頓每天消耗多少杯咖啡？ 假設白天總人口 300 萬，分人群（白領、服務業、遊客）估算日均消費，最終得出約 420 萬杯。強調假設透明和邏輯鏈條。
底層實現：低延遲訂單簿
- 資料結構：std::map（紅黑樹）維護價格層級，每個價格對應 FIFO 訂單佇列；
- 最佳化：無鎖跳錶、記憶體池、CPU 親和性、快取行對齊（alignas(64) 防偽共享）。
手撕：時間輪定時器（訂單超時撤單） 分層時間輪（毫秒→秒→分鐘），新增/刪除 O(1)，槽位級自旋鎖 + 物件池。
第三輪：終面（60分鐘）—— Tech Lead
Tech Lead面，一半技術一半行為面。
Why Citadel
Citadel Securities工程團隊規模小但人均產出高，工程師程式碼直接影響當日盈虧。大廠寫的模組可能只是大系統一環，離最終結果遠。這裡離問題域近，做什麼為什麼做都清楚。
Behavioral
實習時做回測框架，量化研究員認為功能正確就行不用管效能。我跑profiling定位熱點函式，用資料溝通：最佳化後回測時間大幅縮短，策略迭代更快。對方同意後，用SIMD指令重寫核心計算模組，回測速度提升40%且數值結果一致。後續其他研究員也用了這套程式碼。講的時候結構：背景、衝突、行動、結果，突出資料驅動的溝通方式。
分散式交易系統設計
需求：全球跨時區交易，訂單從紐約、倫敦、東京接入，路由到對應交易所。延遲毫秒級，可用性99.999%。
架構：
- 多活資料中心：紐約、倫敦、東京、新加坡各部署完整服務，就近接入
- DNS智慧解析加Anycast路由，自動導向最近機房
- 跨區域走專線或最優網路路徑，避免公網延遲
- 每中心內部：接入層做前置風控，撮合引擎在記憶體完成，交易閘道器連交易所
一致性：
- 賬戶餘額、持倉等全域性資料用多主複製
- 跨區域衝突用版本向量解決，寫入帶版本號，衝突按規則合併
- 大部分場景接受最終一致性，延遲低於閾值內允許短暫不一致
- 交易執行路徑追求強一致性，用分散式事務或Saga模式
可用性：
- 每層冗餘，單機故障自動切備機
- 心跳檢測，秒級發現故障
- 關鍵路徑無狀態或狀態可快速重建
- 熔斷降級：某交易所連不上時快取訂單稍後重試，不影響其他交易所
追問跨區域延遲與一致性tradeoff：交易系統優先低延遲和可用性，一致性極端情況可短暫犧牲但最終收斂。同一使用者多訂單路由到不同區域，短期可能看到不一致，但執行結果以交易所確認為準，最終同步到全域性狀態。
反問環節
問應屆生成長建議。面試官說少花時間學框架，框架會過時。把作業系統、網路、編譯原理打紮實，理解計算機怎麼工作。交易系統核心能力是在不確定條件下快速決策和權衡風險，不是看書能學會的，在真問題裡練出來的。
從方向模糊到拿下Citadel Offer
這次 Citadel 面試能順利透過，我最想說的是：一個人硬扛真的太難了。後來我找到了 Programhelp，他們的學長為我提供了全程 OA 實戰輔助和麵試深度輔導，包括真題預測、程式碼最佳化、系統設計推演和高強度模擬面試，讓我在真實面試中明顯更有底氣和條理。
如果你也在準備 Citadel、Jane Street、NVIDIA、Point72 等高強度面試，感覺一個人複習效率低，強烈建議瞭解一下 Programhelp。他們專注提供 OA 實戰輔助和麵試指導，學長會直接跟你溝通，根據你的情況制定針對性方案。
有需要的同學可以直接聯絡 Programhelp 詳談。
