HackTheRounds Interview Experiences

Netflix SDE Phone Screen Interview Experience (2026) - Rate Limiter, LRU & Video Streaming Design, Offer

Netflix SDE loop: sliding window rate limiter phone screen, LRU plus Merge K Lists coding, in memory file system with concurrency follow ups, and video streamin

By Anonymous · 2026-03-25

Background

The shape of Netflix's technical phone screen caught me completely off guard the first time through, which is the only reason I am writing this up. I had four years of backend work at a video infrastructure startup and applied via a recruiter who had seen my GitHub. The loop ended up being one recruiter call, one technical phone screen, and three technical onsite rounds. What made it different from every other FAANG loop I had done was how heavily concurrency and production-thinking showed up in every single round, from the 45-minute phone screen onward.

Timeline

Total: about 6 weeks.

Recruiter Call (30 min)

Light content, heavy signal on culture fit. The recruiter walked my resume once, asked what I was looking for next, and spent the last 10 minutes on why Netflix. I had read the Netflix Culture Memo twice before the call and anchored my answer in Freedom and Responsibility and Context not Control, tied to a concrete story from my current startup where I had pushed a design decision without waiting for manager approval. Saying "I watch a lot of Netflix" is the anti-pattern here. They care whether you will operate in the culture, not whether you use the product.

Technical Phone Screen (45 min)

Problem: Design a per-endpoint rate limiter. Given a request stream with timestamps and a per-user quota, decide whether each request should be admitted or rejected.

I chose sliding window log as the approach and kept the answer tight. Record each admitted request's timestamp in a per-user deque. On a new request, evict entries older than the window start, then compare the deque size to the quota. Linear time per request in the worst case but amortized constant because every timestamp is inserted and evicted at most once.

The real signal came in the follow-ups, which took 25 of the 45 minutes.

First push: time and space complexity. I walked through amortized insertion-eviction and the worst-case memory of O(quota users) . Second push: high-QPS optimization. I pivoted to sliding window counter as an approximation that trades exactness for fixed memory per user. Third push, and this was the real one: thread safety. My deque needed synchronization. I walked through three options: a coarse synchronized wrapper, per-user lock striping with a concurrent map, and a lock-free approach using atomic counters backed by the counter variant. The interviewer liked the lock-striping answer and asked me to estimate the contention reduction as a function of the number of stripes. I gave a rough 1 / stripes argument for uniform user distribution with caveats about hot users.

Practice it: [[problem/18?company=6|Rate Limiter]]

Virtual Onsite (3 rounds)

Three 60-minute rounds run over a single afternoon: classic coding, open-ended design, and system design.

Round 1: Coding — LRU Cache and Merge K Lists

Problem 1: Implement an LRU cache supporting get(key) and put(key, value) in constant time.

I proposed HashMap<Key, Node plus a doubly linked list. Every access moves the node to the head, evictions pop from the tail. The interviewer was not looking for the code; she was looking for why I had picked a doubly linked list over a singly linked list. I walked through the O(1) removal requirement when evicting from the tail or re-linking in the middle; with a singly linked list you cannot splice a node out in constant time because you need its predecessor. She followed up on memory overhead in real systems and I acknowledged the two extra pointers per node; for a cache of 1M entries in Java, that is on the order of tens of megabytes of pure pointer overhead.

Problem 2: Merge K sorted linked lists into one sorted list.

I led with the O(N log K) min-heap approach, pushing the head of each list into a heap and popping-advancing until all were drained. The interviewer asked for an alternative and I gave the divide-and-conquer merge, pairing lists and halving the list count per pass. Same asymptotic complexity but better constants in practice because heap operations have cache-unfriendly access patterns. She asked when I would pick one over the other. I said heap wins when K is small and lists are long because the heap stays tiny; divide-and-conquer wins when K is large because you avoid the log factor per pop.

Practice it: [[problem/15?company=6|Cache with Time Limit / TTL]]

Round 2: Open-ended Coding — In-Memory File System

Problem: Implement an in-memory file system supporting ls , mkdir , addContentToFile , and readContentFromFile .

I modeled the tree with a node type that was polymorphic over "directory" (holds a map of child name to node) and "file" (holds a string buffer). mkdir walks the path and creates intermediate directories. ls returns the sorted list of child names if the path is a directory, or the single file name if it is a file. addContentToFile walks the path, creating missing intermediate directories, and appends to the buffer.

Follow-ups were where the round got difficult. The interviewer asked four escalating questions: how do you handle concurrent access, how do you store very large files, how would you add a permission model, and how do you validate path input.

On concurrency I opened with a global lock and was immediately told the performance would be unacceptable. I pivoted to per-node locks, acquiring in path order to avoid deadlock. The interviewer pushed on the classic "two clients move conflicting directories" case. I talked through acquiring both source and destination parent locks in canonical order. This is the refinement Netflix looks for, you start simple and then improve under pressure without panicking.

For large files I sketched chunked storage with content-addressable blocks. For permissions I proposed ACLs per node with inheritance from parent. For path validation I covered null bytes, backslash handling, and the .. traversal case.

Practice it: [[problem/19?company=6|In-Memory File System with Versioning]]

Round 3: System Design — Video Streaming Service

Problem: Design a video streaming platform at Netflix scale. Uploads from content partners on one side, adaptive playback to tens of millions of concurrent viewers on the other.

I structured the round in four blocks. First, functional and non-functional requirements. Partners upload masters, we transcode to multiple bitrates, viewers stream via adaptive bitrate, and playback latency under a few seconds at the 99th percentile. Second, the high-level architecture: an ingest service, a transcoding pipeline, a content management service, a CDN layer, a client-facing playback service, and a recommendation service.

Third, deep dives. On transcoding I talked through the chunk-level parallel pipeline, how a long master gets split into time-based segments and each segment transcoded independently to all target bitrates. On CDN I covered push versus pull distribution, cache warming for predictable spikes, and why Netflix would provision its own OpenConnect boxes at ISPs rather than rely exclusively on third-party CDNs. On the player I covered the DASH or HLS manifest plus the bitrate-ladder selection heuristic based on the client's measured throughput.

Fourth, when the interviewer asked about recommendations I was honest about my ML background. I stayed at the level of "offline training that produces embeddings, online serving that does candidate generation plus ranking, and a feedback loop via playback telemetry" rather than pretending to know deep details of Netflix's actual recsys. The interviewer appreciated the scope-honest answer.

Practice it: [[problem/32?company=6|Design Content Recommendation System]]

Behavioral Woven Throughout

Netflix does not have a single "behavioral round" on this loop. Every technical interviewer spends 10 to 15 minutes on behavioral questions. I got three recurring themes across the day:

  • A time you disagreed with a teammate and how it resolved
  • A time you operated under ambiguity and drove to a decision
  • A time you pushed back on a hiring manager or senior engineer

Use STAR. Keep the stories real. Netflix interviewers will deep-dive into the Situation and pull at threads you did not expect. If a story is half-fabricated it will not survive that scrutiny.

Result

Offer one week after the loop. Recruiter hit me with a verbal comp number that was at the top of my range and explicitly inflexible beyond a small adjustment. Netflix's cash-heavy comp model does not negotiate the way Meta or Google comp does, which was fine because the number was already strong.

Tips

  1. Rate limiter is a phone screen lock. If you are interviewing at Netflix, study rate limiter variants cold. Sliding window log, sliding window counter, token bucket, leaky bucket, and know which tradeoff buys you which property. Thread safety will come up.
  2. Have a multi-step refinement path for any design. Netflix interviewers push. They will take your first answer and ask "what if the scale doubles." Having a second and third iteration teed up is more valuable than a polished first answer.
  3. Doubly linked list vs singly linked list is a real question. Do not hand-wave why you picked the data structure. I have seen this question kill otherwise-strong candidates.
  4. Culture fit is tested in technical rounds too. I got asked "how do you make decisions without your manager in the room" during the system design round. Prepare one story for that.
  5. Be scope-honest on ML if it is not your background. Faking Netflix's recommender-system specifics is a trap. A candid "here is what I know at the level I know it" is scored higher than confident wrongness.
  6. The 25-minute follow-up is the round. Every Netflix coding round I did spent more time on follow-ups than on the first pass. Budget accordingly and do not burn 40 minutes writing the original solution.