最近整理了几份 Netflix onsite 面经，虽然很多题目来自不同候选人，但整体结构其实非常一致。Coding、System Design、Data Modeling，再加上两轮 Behavioral，基本是固定配置。题目本身并不算特别难。下面按模块把这些面经串起来讲一下。

Coding：经典题变体，关键在扎实和表达

Coding 部分整体不难，基本都是经典题的变形。常见的有 Tree DFS、拓扑排序，还有一些带设计味道的小系统，比如 command undo system。比如 undo system 这道题，本质就是设计一个支持按 tag 回滚的操作系统。没有 tag 就回滚最近操作，有 tag 就回滚最近带该 tag 的操作。核心考察点其实不是算法难度，而是你如何组织数据结构，让查找和删除都高效，同时代码结构清晰。

拓扑排序这类题更偏基础能力验证。虽然题型很熟，但面试官通常会加一些变化，比如要求输出所有可能结果，或者对结果排序，甚至追问复杂度变化。这时候如果你只停留在会写 Kahn 或 DFS这一层，是不够的，还需要对各种变形有准备。

这一轮真正重要的点是，你要能自己快速验证代码、讲清楚边界情况，并且对 runtime 有明确分析。很多人会写，但讲不清，这一轮就容易失分。

System Design：考察深度，而不是框架

System Design 这一轮通常是一个比较典型的在线系统设计题，难点不在于能不能设计出来，而在于你能讲多深。基本结构上，你需要先把系统拆成 read path 和 write path，这几乎是默认要求。如果这一层都没有讲清楚，后面很难展开。

接下来关键在于细节。比如数据存在哪里，用什么缓存策略，如何处理高并发流量，这些都需要你主动展开。很多面经提到，如果面试官没有深入追问，你需要自己往下讲，否则很容易被认为只停留在表层。还有一个重要点是一致性和原子性问题。比如多个请求同时更新某个状态时，会不会出现竞态条件，你是否需要原子操作，如何保证正确性。这些通常是区分知道和理解的关键。

另外，比较好的回答会同时覆盖实时路径和离线处理，比如实时服务负责在线决策，离线系统负责数据沉淀或模型训练。这种online + offline结合的思路，往往能体现系统理解的完整性。这一轮其实很明显是在看你的工程经验深度，而不是模板化回答。

Data Modeling：从结构到理解

Data Modeling 表面上是让你设计数据库 schema，但实际上是在考你对一个复杂系统的理解能力。基础部分大家都会，从顶层实体一路拆到子结构，建立层级关系，这一部分通常不会有太大问题。但真正的差异在于你是否能覆盖更多维度，以及你如何解释这些设计。

比如你是否考虑了不同类型的数据、配置和状态如何组织，是否考虑了扩展性，以及不同实体之间的关系如何影响系统行为。这些都比画多少表更重要。有一个比较典型的情况是，候选人把整体结构讲得很完整，但没有深入某些关键维度，最后被认为理解不够。这说明这一轮不是看有没有讲到，而是看有没有讲透。

如果你能在讲 schema 的同时，自然延伸到系统流程，比如数据如何进入系统、如何被消费、如何被追踪，这会让你的回答更有说服力。

Behavioral：看起来简单，其实最有决定性

Behavioral 通常有两轮，而且很多时候是 manager 或 senior 面试官来面。问题本身很常规，比如 feedback、conflict、ownership、ambiguity、impact 等，但考察点非常明确。

这一轮核心是在看你是否和团队匹配。很多情况下，面试官并不会深挖某个具体项目，而是通过多个问题去判断你的工作方式、沟通风格，以及你是否具备独立推动事情的能力。一个比较容易踩坑的点是，被动回答问题。如果你只是回答表面问题，而没有主动补充背景、细节和决策过程，很容易被认为经验不够深入。

还有一点是，这一轮非常看相关经验。如果你的过往经历和岗位需求匹配度高，整个对话会非常顺畅；反之，即使回答没有明显错误，也可能被认为不够 fit。

总体感受

从这些面经来看，这类 onsite 面试并不以难题著称。Coding 是常规题，System Design 和 Data Modeling 也属于经典范围。真正的挑战在于，面试标准非常一致，就是看你是否具备成熟工程能力，以及是否可以快速适应实际工作。

如果你的回答停留在表层，比如设计只讲框架，数据建模只讲结构，Behavioral 只讲故事而不讲决策，那么即使没有明显错误，也很难脱颖而出。但如果你能在每一轮主动深入，比如在系统设计里讨论细节 trade-off，在数据建模里解释设计背后的原因，在 Behavioral 里清晰讲出你的影响和决策逻辑，那么整体表现会明显更强。