Netflix onsite 面试结构非常一致：Coding、System Design、Data Modeling，再加上两轮 Behavioral，基本是固定配置。题目本身并不算特别难，但面试标准非常一致，看你是否具备成熟工程能力。
Coding 部分整体不难，基本都是经典题的变形。常见有 Tree DFS、拓扑排序，还有一些带设计的小系统。比如 command undo system 本质就是设计一个支持 ADD、MUL、UNDO 和 PRINT 的命令系统，核心是维护 command history，使每次 UNDO 只撤销最近一个尚未撤销的修改操作。得分点主要是用 stack 保存历史状态或可逆命令。另外拓扑排序类题会加变化，比如要求输出所有可能结果，或者对结果排序，甚至追问复杂度变化。
System Design 通常是一个比较典型的在线系统设计题，难点不在于能不能设计出来，而在于你能讲多深。基本结构上你需要先把系统拆成 read path 和 write path，这几乎是默认要求。接下来关键在于细节——数据存在哪里，用什么缓存策略，如何处理高并发流量，一致性问题和原子性问题。比较好的回答会同时覆盖实时路径和离线处理，比如实时服务负责在线决策，离线系统负责数据沉淀或模型训练。
Ad 方向有两道频率很高的题：ads audience targeting system 和 ads frequency cap system。后者 Frequency Capping 的核心是：广告展示前 Ad Server 使用稳定的 request_id 调用 reserve，系统根据当前生效且版本化的 campaign policy，检查 viewer + campaign 在一个或多个 rolling window 下是否还有额度，只有所有规则都有容量才能原子预占并返回一个 2 分钟有效的 permit。相同 request_id 重试必须返回相同结果。之后 caller 可以幂等地 confirm 或 cancel，未确认的 permit 超时自动释放额度。
主要得分点：强一致、原子的 check-and-reserve 防止超发；reserve/confirm/cancel 幂等；rolling window 和 permit expiration；policy versioning；按 viewer-campaign 分片水平扩展；跨 AZ 持久化和 fail-closed；以及完整的 audit/debug 能力。
Data Modeling 表面上是让你设计数据库 schema，实际上是在考你对一个复杂系统的理解能力。基础部分大家都会，但真正的差异在于你是否能覆盖更多维度，以及你如何解释这些设计。如果你能在讲 schema 的同时自然延伸到系统流程——数据如何进入系统、如何被消费、如何被追踪——这会让你的回答更有说服力。
Behavioral 通常有两轮，而且很多时候是 manager 来面。问题本身很常规（feedback、conflict、ownership、ambiguity、impact），但考察点非常明确——看你是否和团队匹配。一个比较容易踩坑的点是被动回答问题，如果你只是回答表面问题而没有主动补充背景、细节和决策过程，很容易被认为经验不够深入。如果你的回答停留在表层——设计只讲框架，数据建模只讲结构，Behavioral 只讲故事而不讲决策——那么即使没有明显错误，也很难脱颖而出。