Netflix 软件工程师面试题汇总 | 40 道真实面经

💡 核心要点 (Key Takeaways)

• Netflix 的 coding 轮叫 TPS（Technical Problem Solving），反馈常是「Need to collaborate more」，协作表达和题目难度同样重要
• 题不是纯 LeetCode，而是 practical OOP/concurrency/threading：Blocking Queue、ConcurrentMap with TTL、AtomicCounter、Latency Tracker、Movie History
• LeetCode 也出，且成家族：数组查重 I/II/III、合并区间、Course Schedule I/II/III、Parallel Courses、Meeting Room I/II/III
• Design 高频：Latency Tracker（P90/P99）、Movie History、frequency cap、执行有 dependency 的 task framework
• Culture 前置：HR 会提前 share 公司文化 page（Memo），行为面要能结合 memo 谈
• 面试官会主动给 hint，「不要固执己见，要 leverage 面试官的 hint」「多说自己的 thoughts，边写边说」
• 反思文化：候选人会公开复盘「代码正确 O(n) 但不够 clean 该不该挂」，clean 代码是隐性要求

一、Netflix SWE 面试流程 — TPS 轮与 Culture Memo

Netflix 的 SWE 流程有一个和其他大厂明显不同的地方：coding 轮叫 TPS（Technical Problem Solving），而且协作表达和题目难度同样重要。一位候选人的复盘标题就是「TPS 轮：题目澄清反复、时间不够用」，最终反馈是「Need to collaborate more（多协作）」——他确实有问问题、拿确认，但「还是三次理解偏差」，时间被来回澄清吃掉，最后 5 分钟压出来的版本不够 clean，最终被拒。 Netflix 的题不是纯 LeetCode，而是 practical OOP / concurrency / threading 题：Blocking Queue、ConcurrentMap with TTL、AtomicCounter、Latency Tracker、Movie History 这类要「设计并实现一个类」的题占大头，LeetCode 原题（数组查重、合并区间、Course Schedule）也会出但通常成家族（I/II/III）。 一个前置环节值得注意：Culture Memo。HR 会提前 share 公司文化 page，行为面要能结合 memo 谈。一位候选人复盘：行为面第一题就是「Talk about Memo（HR 会提前 share 公司文化 page）」，然后是 resume go through（现在在干什么、这个 team 的 mission 是什么、你做了什么、最大的 project）、最近收到的 constructive feedback。Netflix 的文化（radical candor、ownership、freedom & responsibility）是硬信号，不是客套。 整体上 Netflix 的面试官风格偏「协作 + 给 hint」，官方给候选人的建议原话是：「a. 问 clarification questions，不要一上来就写 code，把这个过程当作 collaborative 的过程；b. 面试官给 hint 的话不要固执己见，要 leverage 面试官的 hint；c. 多说自己的 thoughts，边写边说」。

• Coding 轮叫 TPS，协作表达和难度同等重要，反馈常是「collaborate more」
• 题偏 practical OOP/concurrency，不是纯 LeetCode
• Culture Memo 前置，HR 提前 share，行为面要结合 memo
• 官方建议：先 clarify 别急着写、leverage 面试官 hint、边写边说
• Clean 代码是隐性要求，正确但 messy 可能拿不到强 signal

二、Coding 轮：高频题清单

汇总 2026 年候选人反馈的 coding 题目，分两类：LeetCode 家族（成系列出）和 practical OOP/concurrency（Netflix 特色）。整体特征是「题目不难，但考 clean、协作和 concurrency 基本功」。 LeetCode 家族要成系列准备（I/II/III 都要会），practical 题要能「设计并实现一个类」并讲清 trade-off。

• 数组查重 I/II/III — 检测重复 ID / K 距离内的重复 / 近似 ID（|id1-id2|<=T 算同一系列）
• 合并重叠区间 I/II/III
• Course Schedule I/II/III + Parallel Courses I/II/III
• Meeting Room I/II/III
• Blocking Queue — offer/poll/peek/size + wait/signal
• ConcurrentMap with TTL — LC 2622 变体，lazy cleanup + capacity limit & LRU cleanup
• AtomicCounter — increment/decrement/get + wait/signal on value reach zero
• Weighted cache 的 get 和 put
• Latency Tracker class — 收集多用户延迟 + 查询 P90/P99
• Movie History class — add movie / retrieve history / clear history
• 执行有 dependency 的 task 的 framework（task interface 和 framework 自己 design）
• 实现简易版 linux jq — 按路径查找 + wildcard
• 十秒内的 log 去重
• DFS 打印每个 node 的 level 和是不是 balanced node
• 首页 shelf dedupe（Netflix 业务场景，见真题详解）

三、两道真题详解 — 考察点拆解

1. 首页 Shelf Dedupe（Netflix 业务场景 + 协作） 题目：Netflix 首页有一列 shelf，每个 shelf 有一堆 title，要在 viewport（每个 shelf 最多显示 X 个）里做 dedupe（垂直滚动先不管，视为无限）。一位候选人完整复盘了 v1→v5 的推进：v1 是全局去重（拿到口头确认就开写，结果发现不是他要的）；v2 只在前 X 个 unique 里全局去重（还是不对）；v3 前 X 位跨 shelf 去重、之后只在各自 shelf 内去重（思路对但实现有坑）；v4 最后 5 分钟 fix 版（能跑但 if/else 很乱）；v5 是面试后整理的 clean 版本。最终 clean 版的逻辑是：维护 global_visited 和 local_visited 两个集合，「len(current) < x 且 title 不在 global_visited」就加入全局并加入 local；「len(current) >= x 且 title 不在 local_visited」就加入 local。 这题真正的考点不是算法，而是协作：候选人的反思是「我确实有在问问题、拿确认，但还是三次理解偏差；说明我的提问方式和确认方式可以再优化（比如举具体 counterexample 让对方否定/肯定）」「Need to collaborate more 很可能指的是：更主动用例驱动对齐需求、边画边说、让对方看到你的思考分支，而不是拿到一句口头确认就开写」。应对方式：动手前用具体 counterexample 对齐需求，把思考分支画出来给面试官看，不要拿到一句「OK」就埋头写。 2. ConcurrentMap with TTL（concurrency 基本功） 这题是 LC 2622 的变体：实现一个带 TTL 的 ConcurrentMap，要求支持 1) lazy cleanup（读时检查过期）和 2) capacity limit & LRU cleanup（满了按 LRU 淘汰）。考点是并发下的正确性：多线程读写时怎么保证一致性（锁粒度、CAS vs lock）、TTL 过期怎么判定（存 deadline 还是存 timestamp + ttl）、LRU 淘汰和 TTL 过期两个维度怎么并存。Netflix 的 concurrency 题（Blocking Queue 的 wait/signal、AtomicCounter 的 value reach zero 时唤醒）考的都是同一套基本功——Java 的 synchronized/wait/notify、ReentrantLock、ConcurrentHashMap 的使用。应对方式：把 wait/signal 的正确模式（while 而非 if、在锁内检查条件）和 LRU + 过期组合的数据结构（HashMap + 双向链表 + 时间戳）提前练熟。

• Shelf dedupe 考点是协作：用 counterexample 对齐需求、边画边说、展示思考分支
• 拿到一句口头确认别急着写，先确认到位再动手
• ConcurrentMap with TTL 考并发正确性 + LRU/过期两维度组合
• wait/signal 用 while 检查条件，在锁内判定，是 Netflix concurrency 基本功

四、Design 轮：Latency Tracker 与 Movie History

Netflix 的 design 高频题集中在「设计并实现一个类」的形态，而不是传统的大系统白板设计。 Latency Tracker class：设计并实现一个类，收集多用户的延迟（latency）报告并提供分析洞察，支持两个核心接口——1) 报告延迟（每个测量值是一个毫秒数值）；2) 查询 P90/P99 延迟。考点是分位数的高效计算：在线/流式场景下怎么维护 P90/P99（t-digest、histogram bucketing、或保留样本 + 排序），以及多用户隔离（按 user 分桶还是全局）。 Movie History class：设计并实现一个管理用户电影浏览历史记录的类，支持三个接口——1) add movie to history（记录用户何时浏览了某部电影）；2) retrieve browsing history（按浏览顺序返回，最近浏览排在最后）；3) clear browsing history。考点是 OOD 结构（用户与历史的映射、时间戳维护、去重策略）。 frequency cap 和 执行有 dependency 的 task 的 framework（task interface 和 framework 要自己 design）也会出。整体上 Netflix 的 design 偏「把 OOP 设计 + 算法 + concurrency 结合」，纯架构的题相对少。

• Design 多为「设计并实现一个类」，不是大系统白板
• Latency Tracker 考 P90/P99 高效计算（t-digest/histogram）
• Movie History 考 OOD 结构 + 时间戳 + 去重
• frequency cap、dependency task framework 也会出

五、Behavioral 与 Culture — Memo 是前置

Netflix 的行为面和 culture 强绑定，核心是结合公司 Memo 谈。HR 会提前 share 公司文化 page，行为面第一题经常就是「Talk about Memo」。 高频问题（真实出现过的问法）： - 现在在干什么、这个 team 的 mission 是什么、你做了什么、最大的 project - 最近收到的 constructive feedback 是什么，如果没有，你有什么 constructive feedback 给自己 - 结合 Memo 谈你认同/不认同的文化点 Netflix 的文化关键词是 radical candor、ownership、freedom & responsibility。行为面要能拿出具体的 ownership 故事（我主动承担了什么、push back 了什么、结果如何），而不是泛泛的「我很负责」。注意 Netflix 也鼓励「radical candor」——能坦诚谈自己的缺点和收到的负面反馈（「supervisor 对你的负面评价会是什么」这类问题），比包装自己更得分。 一位被拒候选人的反思很有代表性：他公开复盘了自己「代码正确、O(n)、可读的解，但不够 clean」该不该挂的问题——这说明 Netflix 的隐性要求是clean 的代码 + 协作的表达，不只是正确性。

• 行为面结合公司 Memo 谈，HR 提前 share 文化 page
• 准备具体的 ownership 故事，不是泛泛的「我负责」
• Radical candor：能坦诚谈缺点和负面反馈更得分
• 隐性要求：clean 代码 + 协作表达，不只是正确性

六、常见挂因复盘

从 2026 年 Netflix SWE 候选人的失败案例里，可以归纳出四类高频挂因。 1. TPS 轮协作不够（最典型）。「Need to collaborate more」是 Netflix 的高频拒因。不是题没做出来，而是「拿到一句口头确认就开写」「理解偏差三次」「最后 5 分钟压出不够 clean 的版本」。启示：用 counterexample 对齐需求、边画边说、展示思考分支，把过程当协作而不是单干。 2. 代码不够 clean。「正确、O(n)、可读，但不够 clean」——Netflix 对代码质量有隐性 bar， messy 的 if/else、命名不清、结构混乱会削弱 signal。即使正确，也要主动 refactor 到 clean。 3. Concurrency 基本功不熟。Blocking Queue 的 wait/signal、AtomicCounter 的 value reach zero 唤醒、ConcurrentMap with TTL 的并发正确性，考的都是 Java 并发基本功。wait/signal 用 if 而非 while、锁外检查条件，是高频错误。 4. Culture 信号不足。结合 Memo 谈不出具体 ownership 故事、不敢谈负面反馈，会削弱 culture signal。Netflix 的文化是硬门槛，不是客套。

• TPS 协作不够是最典型挂因，用 counterexample 对齐 + 展示思考分支
• 代码不够 clean 会削弱 signal，正确也要 refactor 到 clean
• Concurrency 基本功（wait/signal、锁内检查）不熟会卡
• Culture 要结合 Memo 谈具体 ownership，不是客套

七、4 周训练计划

按 Netflix 实际流程的权重排优先级：TPS 协作表达 > concurrency/OOD > LeetCode 家族 > culture。 Week 1 — LeetCode 家族。数组查重 I/II/III、合并区间、Course Schedule I/II/III、Parallel Courses、Meeting Room I/II/III 成系列刷，每道练到能默写 I/II/III 三个版本的差异和优化。 Week 2 — Concurrency 基本功。Blocking Queue（wait/signal）、AtomicCounter（value reach zero 唤醒）、ConcurrentMap with TTL（LRU + 过期）、weighted cache 各实现一遍。把「while 检查条件、在锁内判定」的 wait/signal 模式练成肌肉记忆；整理 Java 并发一页纸（synchronized/ReentrantLock/ConcurrentHashMap）。 Week 3 — OOD Design + TPS 协作。Latency Tracker（P90/P99）、Movie History、dependency task framework 各做 30 分钟。重点练 TPS 协作：每道题先列 counterexample 对齐需求，边写边说，最后主动 refactor 到 clean。首页 shelf dedupe 这类业务题专门练「协作表达」。 Week 4 — Culture + 全流程模拟。结合 Netflix Memo 准备 2-3 个 ownership 故事（主动承担、push back、坦谈话题），练习「radical candor」式谈缺点。最后两天做 2 次完整模拟（60 分钟 TPS + 30 分钟 design），请人按 Netflix 的协作追问强度压。

• Week 1：LeetCode 家族 I/II/III 成系列
• Week 2：Concurrency 基本功 + Java 并发一页纸
• Week 3：OOD Design + TPS 协作表达
• Week 4：Culture ownership 故事 + 2 次全流程模拟

八、如果时间紧迫

如果距面试不足两周，优先级排序是：先保 TPS 协作（每道题先 counterexample 对齐需求、边写边说、refactor 到 clean），再保 concurrency 三道（Blocking Queue、AtomicCounter、ConcurrentMap with TTL），LeetCode 家族压缩到数组查重 + Course Schedule + 合并区间三组。Netflix 的 culture memo 前置，提前读 HR share 的文化 page 并准备 1 个 ownership 故事。 如果希望有人帮你按 Netflix 的真实题型做一轮模拟（60 分钟 TPS 协作 + OOD design + culture 追问），可以预约 30 分钟免费咨询，我们会评估你当前距离各轮 bar 的差距，再决定投入哪个环节。也可以看看我们针对 Netflix 的完整备考指南： 相关文章：
Netflix 面试备考指南 · SWE 面试全解析 · 面试辅助服务

• 时间不足两周：TPS 协作 > concurrency 三道 > LeetCode 三组
• Culture memo 前置，提前读文化 page 准备 ownership 故事
• 30 分钟免费咨询可评估你距离各轮 bar 的差距