Optiver 的 SDE NG 面试流程里有 coding 和 design，这一点和很多同级别公司不太一样——他家的 NG 是真的会考系统 design 的，而且不是走形式的那种。这篇笔记主要聚焦第一轮 coding 面试。整体时长一小时，代码在 Hackerrank 上完成，看起来很常规，但实际体验下来会发现，这一轮对工程基本功和计算机基础的要求明显高于普通算法面。

面试整体节奏与预期

在 Optiver，第一轮 coding 并不是“给一道题 → 写最优解 → 结束”这种套路。相反，它更像是一场围绕同一个问题的技术深挖。面试官给出题目之后，通常不会立刻让你写代码，而是先进入一个较长的讨论阶段。他们非常在意你对问题的拆解能力，以及你是否能从不同角度思考解决方案。这一阶段如果表现不好，基本也就不用等后面的实现了。

多解法讨论是刚需，而不是加分项

一个非常重要、也非常容易被低估的点是：Optiver 会明确要求你给出多个 solution。注意，这不是你可以顺便提一嘴其他方法，而是面试官会主动追问：“还有没有别的解法？”、“如果不用这个数据结构，你会怎么做？”接下来你需要清楚地描述每一种方案的时间复杂度、空间复杂度，以及在不同约束条件下的优劣取舍。更关键的是，这里的 pros & cons 不是停留在 O(N)、O(logN) 这种算法课层面的讨论，而是会自然延伸到更工程化的问题，比如常数因子、cache 友好性、实现复杂度、以及在真实系统中可能遇到的坑。如果你只准备了标准答案，而没有对其他方案进行过系统性思考，这一段会非常被动。

面试官非常在意“底层到底发生了什么”

Optiver 面试一个非常鲜明的特点是：讨论经常会一路下钻到底层实现。比如你提到用某个数据结构，面试官可能会接着问它在内存里的布局是什么样的；你说某种方案空间效率更高，对方可能会追问它的 memory access pattern 是否连续；如果你用的是 Java 或 C++，甚至可能会聊到 garbage collection、对象分配、指针间接访问带来的性能影响。也就是说，如果你的知识储备还主要停留在“刷题算法 + STL/Collections 会用”的层面，而对操作系统、内存模型、缓存、语言运行时缺乏直觉理解，那么这轮面试会非常吃力。Optiver 明显更偏好那种能把抽象算法和真实机器行为联系起来的候选人。

实现只是中后段，而不是全部

在完整讨论了多种方案之后，面试官才会让你在 Hackerrank 上选择其中一个进行实现。这里反而不是最难的部分，因为真正的难点已经在前面的设计和权衡中体现过了。不过需要注意的是，他们对代码质量的期望并不低。变量命名、边界条件、可读性都会被看在眼里，而不是只要 AC 就行。

Test cases 必须自己补，而且要跑通

写完 implementation 之后，面试并不会立刻结束。你需要自己设计 test cases，覆盖常见情况和边界情况，并在 Hackerrank 上实际运行，确保没有 bug。这一环节非常能区分人。有些 candidate 在这里会暴露出对 corner case 不敏感的问题，或者逻辑上本来就存在漏洞。Optiver 显然更希望看到你像一个真正的工程师一样，对自己的代码负责，而不是写完就交。

高频题型与背后的考察点

从过往经验来看，第一轮 coding 的高频题包括 Union Find、Binary Search Tree 等经典数据结构。题目本身并不新，但 Optiver 并不是在考你有没有见过，而是在考你对这些基础结构理解得有多深。比如 Union Find，不只是能不能写出 path compression，而是你是否理解不同优化策略对时间和空间的影响；BST 也不只是插入和查找，而可能延伸到平衡性、退化情况，甚至内存访问效率。从这个角度看，Optiver 的 NG coding 面试，本质上是在筛选那种基础扎实、思维严谨、并且具备系统级直觉的工程型选手。如果你的准备方向只是刷题数量，那很可能会和他们的预期产生错位。