最近复盘了一场 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 好好梳理一遍。工程思维真的比刷题数量重要。需要更多真题或者想了解面试辅助服务请 联系我们。
