Netflix Software Engineer Onsite Coding Questions
56+ questions from real Netflix Software Engineer Onsite Coding rounds, reported by candidates who interviewed there.
What does the Netflix Onsite Coding round test?
The Netflix onsite coding round is the core technical evaluation. Software Engineer candidates typically see 2-3 algorithm and data structure problems. Problems range from medium to hard difficulty, and interviewers evaluate both correctness and code quality.
Top Topics in This Round
Netflix Software Engineer Onsite Coding Questions
Netflix Onsite | SWE | HM
Problem Statement: Task Scheduler with Buffered Execution You are tasked with designing a system, named TaskProcessor, that efficiently handles a stream of tasks. The system should ensure that when a certain...
Netflix | Onsite | Query JSON objects
Let\'s say you have an array of similar json objects. Example object: json { "field1": "bar", "field2": 1, "field3": true, "field4": [1, 2, 3], "field5": { "nested": { \t\t"other": [4, 5] \t} } ... } Design...
#1136 Parallel Courses
LeetCode #1136: Parallel Courses. Difficulty: Medium. Topics: Graph Theory, Topological Sort. Asked at Netflix in the last 6 months.
#2622 Cache With Time Limit
LeetCode #2622: Cache With Time Limit. Difficulty: Medium. Asked at Netflix in the last 6 months.
#210 Course Schedule II
LeetCode #210: Course Schedule II. Difficulty: Medium. Topics: Depth-First Search, Breadth-First Search, Graph Theory, Topological Sort. Asked at Netflix in the last 6 months.
#220 Contains Duplicate III
LeetCode #220: Contains Duplicate III. Difficulty: Hard. Topics: Array, Sliding Window, Sorting, Bucket Sort, Ordered Set. Asked at Netflix in the last 6 months.
#981 Time Based Key-Value Store
LeetCode #981: Time Based Key-Value Store. Difficulty: Medium. Topics: Hash Table, String, Binary Search, Design. Asked at Netflix in the last 6 months.
#1146 Snapshot Array
LeetCode #1146: Snapshot Array. Difficulty: Medium. Topics: Array, Hash Table, Binary Search, Design. Asked at Netflix in the last 6 months.
Data Modeling Interview: Design Schemas for E-Commerce, Analytics, and Time-Series Use Cases
## Round 1 - Data Modeling ## Problem You will be asked to design data schemas for three scenarios. For each, discuss table/collection design, relationships, indexes, and tradeoffs. **Scenario 1 — E-Commerce:** Model `Users`, `Products`, `Orders`, and `OrderItems`. Support queries: "all orders for a user" and "total revenue per product in the last 30 days." **Scenario 2 — Event Analytics:** You ingest 100M user click events per day `(user_id, event_type, page, timestamp, metadata JSON)`. How do you model this for fast time-range queries and funnel analysis? **Scenario 3 — Time-Series:** Store hourly sensor readings `(sensor_id, metric, value, recorded_at)` for 10,000 sensors over 5 years. Support: last 24h readings per sensor, and min/max/avg over any time window. ## Follow-ups 1. For Scenario 1, what indexes do you add and why? What is the query plan for "total revenue per product in the last 30 days"? 2. For Scenario 2, why is a row-per-event schema problematic at 100M/day? How do columnar formats (Parquet, BigQuery) help? 3. For Scenario 3, compare storing raw rows vs pre-aggregated hourly/daily summaries. What is the staleness tradeoff? 4. A product team wants to join Scenario 2 (clicks) with Scenario 1 (orders) to compute conversion rate. Describe the pipeline.
## Round 1 - System Design ## Problem Design a contact tracing system used during a disease outbreak. The system must: 1. Record a contact event: `log_contact(person_a, person_b, timestamp, duration_minutes)` — bidirectional. 2. Report exposure risk: `get_exposed(person_id, days_back, exposure_depth)` — return all people who came in contact (directly or through a chain of depth `exposure_depth`) with `person_id` in the last `days_back` days. 3. Mark a person as confirmed positive: `report_positive(person_id, test_date)`. 4. Automatically generate notifications for anyone within exposure_depth=2 of a confirmed positive. Walk through your data model, graph traversal strategy, and scalability concerns. ``` log_contact(A, B, t1, 30) log_contact(B, C, t2, 15) report_positive(A) get_exposed(A, days_back=14, exposure_depth=2) -> {B, C} ``` ## Follow-ups 1. The exposure graph could have millions of nodes. How do you make BFS/DFS efficient? What indexes does your DB need? 2. Privacy is critical — people's contact histories are sensitive. How do you design the system to minimize data retention and exposure? 3. A person is contacted as a potential exposure but later tests negative. How does your notification system handle false positives? 4. How would Bluetooth-based proximity detection (e.g., Apple/Google API) integrate with your backend contact log?
## Round 1 - System Design ## Problem Design a backend system that supports two core features for a video streaming platform: 1. **Video Downloads** — authenticated users can download videos for offline playback. Downloads must expire after 30 days and be DRM-protected. 2. **Creator Subscriptions** — users can subscribe to a creator; subscribers get early access to new uploads and ad-free playback. Cover: API design, data models, storage strategy, and at least one non-trivial scaling concern for each feature. **Clarifying questions to consider:** - What is the expected ratio of downloads to streams? - Should subscription state be strongly consistent or eventually consistent? - How many creators and subscribers are in scope (order of magnitude)? ## Key Components to Discuss - Download token issuance, signed URL generation, and expiry enforcement. - Subscription event fan-out: how to notify millions of subscribers when a creator uploads. - Storage tiering: hot vs. cold for downloaded content. - Preventing download link sharing (device binding, token fingerprinting). ## Follow-ups 1. How do you handle a creator with 10 million subscribers uploading a video — what does fan-out look like? 2. Where does the DRM key service live, and how do you protect it from abuse? 3. How do you ensure a user's downloaded library is consistent across two devices?
## Problem: DFS — Print Each Node’s Level and Whether It Is a Balanced Node Given a tree rooted at `root` (typically a binary tree; for an N-ary tree follow the interviewer’s definition), traverse th
## Problem: Implement a TTL Cache (cache with time limit) Implement a cache that supports key-based access where each entry has a time-to-live (TTL). Once an entry expires, reads should behave as a m
Implement a `WordCounter` class to count word frequencies from **streaming text**. You will receive multiple chunks of text over time. Split each chunk into words and accumulate counts. Provide a que
Thread-safe Sliding Window P99 Latency Tracker
## Thread-safe Sliding Window P99 Latency Tracker Implement a **thread-safe (concurrent)** latency tracker that supports ingesting latency samples and querying the P99 over a recent time window. You
## Problem: Weighted Cache Eviction (Weight-Constrained Cache) Design and implement a cache `WeightedCache` with a **total weight capacity** constraint. Each cache entry has: - `key` - `value` - `we
## Coding: Topological Sort / Dependency Resolution Given a directed graph representing dependencies among tasks labeled `0..n-1`. ### Input - First line: two integers `n m` (number of tasks and edg
## Problem: Implement a Command Executor with `execute` and `undo` Implement a `CommandExecutor` that can execute commands in order and undo the most recently executed command. Each `Command` must s
Topological Sort
## Problem: Topological Sort Given a directed graph with `n` nodes labeled `0..n-1` and a list of directed edges `edges`. Each edge is a pair `(u, v)` meaning `u -> v`. Return any **topological orde
Given a JSON object represented as nested `Map<String, Object>` (no string parsing required), implement a `jq`-like path query. ### Input - `json: Map<String,Object>` where values can be scalars or n
What to Expect in the Netflix Onsite Coding Round
The Netflix Software Engineer Onsite Coding round has a specific calibration purpose distinct from other rounds in the loop. Across 56+ verified reports on LeakCode for this exact round type, the consistent expectations: clear scoping of the problem before diving into a solution, explicit reasoning about complexity, structured handling of edge cases, and the ability to discuss trade-offs between two reasonable approaches.
Reports tagged with the Onsite Coding round at Netflix show recurring patterns in difficulty and topic distribution. The Onsite Coding round is typically 45-60 minutes; the interviewer is calibrated against a specific rubric. The discriminator between candidates who advance and candidates who do not is rarely the final correctness of the answer. It is the path: did you clarify, did you verbalize your approach, did you handle edge cases, and did you communicate throughout.
How To Prepare for This Specific Round
Filter the questions below to the most recent reports (past 6-12 months). Questions tagged for this exact round type from this exact company at this exact role level are the highest-signal data available. Older reports may reference questions that have since rotated out of the company's pool.
Practice 4-6 representative problems from this set under timed conditions. The goal is not memorization (companies rotate questions); the goal is to internalize the patterns the interviewer typically reaches for and the depth of follow-up to expect. Reports on LeakCode also tag the typical follow-up depth at this round type, which is the discriminating signal between hire and no-hire calibration.
Onsite Coding Round Timing and Format
The Onsite Coding round at Netflix typically runs 45-60 minutes. Use the first 2-3 minutes to clarify requirements; you should never start coding or designing without verifying the input/output format, constraints, and edge cases out loud. Use the next 5-7 minutes to verbalize your approach before writing any code. The middle 20-30 minutes are implementation. Reserve the final 10 minutes for testing with concrete examples and discussing optimization or trade-offs.
Time budget discipline is one of the most reliable senior-vs-junior discriminators in this round. Strong candidates verbalize where they are in their budget out loud ("I've used about 20 minutes, I have 15 minutes left for testing and one optimization"). This signals engineering maturity to the interviewer and creates positive feedback they can capture in writing.
Common Failure Modes in This Round
Reports tagged "no hire" at Netflix Software Engineer Onsite Coding commonly cite: coding silently without verbalizing approach, jumping to implementation before clarifying requirements, missing edge cases (empty input, single element, very large input), producing working code that the candidate cannot refactor when asked, and failing to test their solution with concrete examples before declaring done.
The single most predictive failure mode in 2025-2026 reports: not asking clarifying questions. Interviewers at all FAANG companies are explicitly trained to weight this dimension. Strong candidates ask 3-5 clarifying questions even on problems that look obvious; weak candidates dive into code immediately. The clarifying-question check is often the first signal recorded in the interviewer's notes.
See All 56 Questions from This Round
Full question text, answer context, and frequency data for subscribers.
Get Access