根据我们最近收集到的多组面试数据，可以明确地说，Optiver 现在在面试流程和标准上，几乎已经不再区分 Intern 和 New Grad。无论是形式还是难度，都要求候选人具备扎实的CS基础、熟练的coding能力以及对系统性能的理解。整个流程分为三轮，分别对应技术筛查、核心编码实现与系统架构设计，每一轮都与 Optiver 的交易业务紧密结合，体现出他们对工程师“懂底层、能高效、讲原理”的要求。

1️⃣ Round One

第一轮通常是一小时的tech screen，在 HackerRank 上进行。经典题目是 LRU Cache 的实现，理论上最佳解法是使用双向链表配合哈希表来实现 O(1) 的查找和更新操作。但是面试官并不会止步于代码的正确性，而是会不断深入followup，从链表在内存中的布局方式，到节点分配的内存开销，再到操作系统层面的 inode 与文件缓存机制，几乎把考察范围从数据结构延展到了计算机体系结构。这一轮的目的并不是单纯地筛选出会写题的人，而是要判断candidates是否真正理解数据结构背后的设计，是否知道内存访问的代价和指针操作的风险。能解释出为什么采用这种结构、在内存局部性上能带来什么收益、不同设计方案在 CPU cache line 层面会造成什么影响，往往能给面试官留下较深的印象。

2️⃣ Round Two

第二轮同样在 HackerRank 上进行，但性质不同。这一轮要求candidate实现一个轻量级的 Order Book System，也就是交易撮合引擎的核心组件。系统会不断接收包含 symbol、side（买卖方向）、price、quantity 和 timestamp 的订单事件，candidate需要实时维护每个交易对的最优买价与卖价，并在满足成交条件时生成匹配结果。题目通常分三个level推进：最初是实现最优价格的实时更新，随后引入订单撮合与部分成交逻辑，最后扩展到支持订单取消、修改，以及基于价格优先和时间优先的撮合规则。每一个level都在逐步逼近真实交易系统的复杂度。这道题考察的不仅仅是编程能力，而是数据结构设计与事件驱动逻辑的结合。candidate必须在有限的时间内权衡有序结构（红黑树、heap、deque）与查找结构（如 map、unordered_map）的使用，同时保证系统能高效地处理上千条订单流并维持确定性。

3️⃣ Round Three

第三轮虽然被称为 system design，但与常规的分布式架构题并不相同。Optiver 更看重候选人是否能设计出一个低延迟、高可靠的实时交易infra。面试中通常不需要画架构图，而是通过口头阐述系统的核心组件与数据流向来展示设计思维。讨论会从如何高效存储和更新订单状态开始，逐渐扩展到如何以毫秒级甚至微秒级的延迟分发市场数据，如何设计异步回调与事件订阅机制以避免阻塞，以及在多线程环境下如何确保撮合逻辑的原子性和一致性。这一轮的关键不是知道答案，而是能展示你在性能tradeoff、并发控制与数据一致性方面的思考。能谈到 lock-free queue、ring buffer、memory pool、snapshot + incremental update 等概念，往往能让面试官感受到你具备真正的系统工程意识。

综合来看，Optiver 的面试风格具有鲜明的业务导向和技术深度。它不像一般科技公司的面试那样偏重抽象算法，而是更接近真实生产系统的考察。候选人如果只停留在表层代码实现，往往无法拿到高分。想要表现出色，除了熟练掌握经典数据结构与算法外，更要理解 market microstructure 的基本概念，比如 bid/ask、spread、order book 的构成与动态；同时也要具备一定的操作系统与网络编程知识，了解 epoll、zero-copy、cache coherence 这些底层机制。