一小时 Screen：一道题的两种解法

Screen 是一小时，没有寒暄，没有聊简历，直接进入写题环节。整场面试只有一道题。开始时我先讲了自己对题目的理解以及整体思路，确认对齐之后开始 implementation。平台已经提供好 test cases，不需要自己写测试代码。实现过程比较顺利，代码通过了所有 tests，而且时间上还剩下大约半小时。

这个时候 interviewer 并没有结束，而是对场景做了调整，让我重新思考有没有 time complexity 更优的写法。于是我又在原有解法基础上重新设计并实现了一个 optimized version。写完之后还有一些 follow-up，主要围绕 edge cases、complexity analysis，以及如果数据规模进一步扩大应该如何处理。整体来看，Screen 虽然只有一道题，但考察方式很立体。不是简单刷题，而是从 correctness 到 optimization，再到思维延展，层层递进。核心在于是否能够在一个 problem 上持续深入。

Virtual Onsite：三轮风格完全不同

Virtual onsite 总共三轮，分别是 Coding、System Design 和 Project Deep Dive。三轮风格差异很大，但共同点是都偏重真实 engineering 能力，而不是纯 algorithm 技巧。

Coding：Order Book 设计，algorithm 与 engineering 的结合

Coding 这一轮也是一小时，但明显比 Screen 更偏向 engineering 能力。题目是设计一个订单撮合簿（Order Book），要求支持 high-frequency 插入、删除，以及按 price 排序查询。也就是说，这不是单纯的 LeetCode 题，而是一个带有明确 business background 的 data structure 设计问题。

实现层面必须保证 algorithm correctness，比如如何在 O(log n) 或更优 time complexity 下完成操作。但真正拉开差距的是后面的 follow-up。interviewer 围绕 production environment 展开了大量追问，例如在 high concurrency 场景下如何优化、data structure 如何支持 horizontal scalability、如何做 code refactoring 以支持更多 order types、如何抽象 interface 以提高 extensibility。

这部分其实非常考验实战经验。如果只是停留在能 AC的层面，回答会显得比较单薄。需要结合真实 system 经验去讨论 memory layout、lock granularity、hotspot data、abstraction layer 设计等问题，才能让答案更有说服力。

System Design：毫秒级 Risk Control System 设计

System Design 是我觉得最有挑战的一轮。题目是设计一个 risk control system，要求在 millisecond-level latency 下对每笔 transaction 做 compliance 与 risk validation。interviewer 会提供一个现有的 architecture diagram，以及部分 upstream / downstream services 的 interface 说明。你的任务不是从 zero 开始，而是在现有体系下设计一个可落地的 risk control system。

这一轮对 API design 关注不多，重点在 high-level architecture。包括 data flow 怎么走、core components 如何拆分、synchronous 与 asynchronous 边界在哪里、state 如何管理等。画完 diagram 之后，还剩下二十多分钟，接下来几乎全是 deep dive。问题集中在 scalability、fault tolerance 和 monitoring metrics 上。例如 system 如何在 peak traffic 下保持 low latency，依赖服务 failure 时如何做 graceful degradation，如何设计 observability metrics 以保证 real-time risk system 的稳定运行。

这一轮的感觉是，不只是考你会不会设计，而是考你是否真的想清楚 system 在真实 production environment 下会遇到什么问题。

Project Deep Dive：最有 Robinhood 风格的一轮

最后一轮是 Project Deep Dive，这一轮非常有 Robinhood 特色。需要提前选一个 project，准备几页 slides，然后给 interviewer 做讲解。interviewer 的 background 很可能和你并不相同，因此讲解时不能假设对方了解你的 domain。

这就要求对复杂的 domain knowledge 做深入浅出的表达。既要讲清楚 technical details，又不能陷入过于专业的细节泥潭。如何讲清楚 background problem、为什么要做这个 project、technical decision 背后的 trade-off、最终 impact 如何衡量，都是重点。讲解结束后，interviewer 会有大量问题。不仅是 technical questions，还有关于 team collaboration、project planning、stakeholder management 等方面的 behavioral questions。比如为什么选择某种 solution、当 project 遇到阻力时如何推进、如何协调 cross-functional collaboration 等等。

这一轮其实非常综合，既考察 technical depth，也考察 communication 能力和 leadership。