Quant SWE OA 准备指南：Citadel、HRT、Optiver、Jane Street 的 Coding 到底怎么练

Quant SWE 的 OA 和技术面试，和普通大厂 SDE 面试很不一样。很多候选人刷了几百道 LeetCode，到了 Citadel、HRT、Optiver、Jane Street、Two Sigma、DRW 这类公司，还是会觉得题目“不按套路出牌”。

原因很简单：Quant firm 更关心你在高压、强约束、低容错的工程环境里能不能写出正确、清楚、性能可控的代码。题目未必都是 hard，但时间紧、边界多、数据规模大、follow-up 深。你需要的不只是会做题，而是能快速建模、选择合适复杂度、解释 trade-off、自己设计测试。

这篇文章面向在美国准备 Quant SWE / Algo Dev / Trading Infrastructure 的中文候选人，重点讲准备框架，而不是押某一道原题。

Quant SWE OA 和普通 OA 的区别

普通 tech OA 常见模式是两道算法题，考察数据结构和复杂度。Quant SWE OA 也会考这些，但更容易出现下面几类特点：

时间更紧，75-90 分钟内要完成多道题或多 level
题面更长，读题和抽象本身就是考点
业务背景可能来自交易、调度、区间、状态机、资源分配
数学推导、组合计数、概率直觉可能混入 coding
测试隐藏得更严格，暴力解法很容易 TLE
面试后续会追问性能、内存、语言 runtime、低延迟系统

所以准备时不能只问“是哪道 LeetCode”。更有效的问题是：这个题属于什么模型，瓶颈在哪里，什么输入规模会打爆我的方案？

高频题型 1：区间、扫描线、排序

Citadel、HRT、Optiver 这类公司很喜欢区间和事件处理题。典型模型包括：

给定一组时间区间，求最大重叠数量
找到能覆盖最多对象的时间点
合并或查询大量 interval
资源在不同时间段的占用
按事件顺序维护状态

这类题最常见的坑是用 O(n²) 暴力比较所有区间。小样例能过，隐藏测试会超时。

更稳的思路是扫描线：

把每个区间拆成 start event 和 end event。
按时间排序。
从左到右扫描，维护当前 active count 或 active set。
注意闭区间、开区间、同一时间 start/end 的排序规则。
如果有 tie-break，单独处理。

面试时不要只说“用扫描线”。你要解释为什么最大值只可能出现在端点附近，为什么排序后线性扫描足够，以及同一时间点多个事件如何处理。

高频题型 2：组合计数和 modulo

Quant OA 里经常出现看起来像 DFS / DP，但其实可以推导成数学公式的问题。例如多进程调度、不能连续选择同一对象、满足某些排列约束的方案数。

准备这类题时要练三层思考：

先写小规模 brute force。
用 DFS 或 DP 验证样例，帮助理解状态。

再找状态转移规律。
如果每一层结构相同，当前选择只依赖上一层，通常可以压缩成 DP 或公式。

最后处理大数和 modulo。
如果答案需要 mod 1e9 + 7，要会快速幂、乘法取模、边界 n=0/1。

很多候选人一上来就写 DFS，结果超时；也有人直接猜公式，但边界错。正确做法是先用小例子验证，再把规律推广。

高频题型 3：业务规则模拟

Quant SWE 不是只写数学题。很多题更像小型业务系统：

交易记录更新
买卖订单撮合
资源分配
航班和货物收益优化
数据流中的 top-k 或实时统计
订单失败后的 refund / charge 规则

这类题的关键是把状态建模清楚。不要把所有逻辑写在一个 for loop 里。

建议拆成：

input parser
state model
event handler
rule evaluator
output formatter

如果题目有交易失败、退款、重新开放、时间顺序，先定义每个对象的状态机。否则后面加 follow-up 时很容易乱。

高频题型 4：性能和底层理解

Optiver、Jane Street、HRT 等公司常常会在 coding 之外追问实现细节：

还有没有另一种解法？
这个方案 cache friendly 吗？
C++ vector 和 map 的内存访问差异是什么？
Python 方案能不能撑住这个数据量？
为什么 heap 比 sorting 更适合这个场景，或者反过来？
如果数据流无法全部放入内存怎么办？

回答时不要只背 O(n log n)。Quant 面试更关心实际工程性能：

常数因子
memory allocation
contiguous memory
branch prediction
cache locality
IO / network cost
concurrency overhead

你不需要变成系统编程专家，但至少要能解释：为什么某个方案在真实机器上可能更快或更慢。

Jane Street 风格：Clarity 比炫技重要

Jane Street 的 general coding 通常不追求冷门算法，而是看你能不能把复杂业务规则实现得清楚。题目可能是 API 实现、状态更新、交易结果处理、时间顺序事件处理。

准备重点：

先澄清输入输出和事件顺序
写出清楚的数据结构
保持函数小而可测试
主动讨论 ambiguous cases
一边实现一边解释 reasoning

如果第二问加入失败交易、退款、回滚、时间顺序，你要先暂停，重新定义状态，不要直接硬改第一版代码。

语言选择：Python 还是 C++

OA 阶段 Python 通常足够，但如果目标是 HRT、Jane Street、Optiver 的低延迟、Algo Dev、Performance、C++ infra 岗，C++ 基础会明显加分。

Python 准备重点：

dict / set / heapq / bisect / deque
sorting key 和稳定排序
避免 O(n²) 字符串拼接
快速输入输出
用小函数组织业务规则

C++ 准备重点：

vector / unordered_map / map / priority_queue / set
iterator invalidation
pass by reference
custom comparator
memory layout
RAII 和基本 ownership

如果你用 Python 面 quant，要特别主动解释复杂度和瓶颈，避免给人“只会脚本”的印象。

一周冲刺计划

第 1-2 天：区间和扫描线

练最大重叠、会议室、区间合并、最小覆盖点、时间窗口统计。每题都写 O(n²) baseline 和 O(n log n) 优化。

第 3 天：组合计数和 DP

练不能连续选择、排列计数、路径计数、状态压缩、快速幂。重点是从 brute force 推导公式。

第 4-5 天：业务规则模拟

练订单状态、交易失败处理、load balancing、resource allocation、stream top-k。每题写状态机和测试。

第 6 天：性能表达

选 5 道题，分别说出 2-3 种方案，比较复杂度、常数、内存、实现复杂度。

第 7 天：完整 mock

做 75 分钟 OA 模拟，再做 45 分钟 coding interview。重点复盘读题时间、测试覆盖、是否能解释 trade-off。

需要 Quant SWE mock？

Quant SWE 面试最容易挂在时间管理、复杂度优化、业务状态建模和性能解释。Interview Coach Pro 可以帮你做 Citadel、HRT、Optiver、Jane Street 风格 coding mock，重点训练扫描线、DP 推导、业务模拟、C++/Python 复杂度表达。