HackTheRounds Interview Experiences

Netflix Software Engineer Interview Experience (2026) - Command Undo & Ads Audience Targeting, Offer

Netflix ads platform SWE VO: 5 rounds covering Command/Undo OOP coding, ads data modeling, Audience Targeting system design, manager behavioral, and deep domain

By Anonymous ยท 2026-03-17

Background

Netflix's loop is unlike the other FAANGs, and I went in underprepared for just how unlike it would be. I have 5 years of backend experience, most of it on ads adjacent systems at a streaming startup, which is the only reason the ads-heavy rounds did not bury me. Five rounds in a single half-day, every round carrying signal, and an expectation that you can hold a real conversation about the business, not just draw boxes and name AWS services.

Timeline

Total: about 7 weeks.

Format

Netflix's VO is 5 back to back rounds across roughly 5 hours with short breaks. The structure this cycle:

No "bar raiser" in the Amazon sense. Every interviewer is senior, and the whole loop biases hard toward ads platform problems because that is the team hiring.

Round 1: Coding, Command with Undo

Problem: Implement a class that supports execute(command) and undo() . Each command is an arbitrary object that can be run, and calling undo() reverses the most recent executed command. Calling undo() when nothing has been executed should be a no-op, not a crash.

This is an intentionally open OOP problem. The interviewer is not looking for a LeetCode-style grind; they want to see how you model state and how you think about interfaces.

I opened with the interface before writing any implementation: a Command contract with execute() and undo() , and an executor that owns a history stack. The executor's execute runs the command and pushes it on success; its undo pops the top command and reverses it, no-oping on an empty stack.

Then I sketched a concrete example to ground the abstraction: an AddItem command that pushes onto a list on execute and pops on undo. The interviewer immediately probed three things: what if a command throws during execute (do not push it onto history), what about nested or compound commands (Composite pattern, undo applies in reverse order), and what about multi-step undo (trivial extension, undo(n) ).

The last 10 minutes drifted into a quieter design question about redo. I sketched the two-stack pattern, executed moves go on the undo stack, undone moves go on the redo stack, any new execute clears the redo stack. I have used that pattern at work so it came out naturally.

Round 2: Data Modeling, Ads

Problem: Design the data model for Netflix's ads platform. You need to cover advertiser accounts, creatives, campaigns, audience segments, delivery/pacing events, and reporting aggregates.

This is where the interview stops being generic. The interviewer pushed on ads-domain distinctions: line items versus creatives, frequency cap as a first-class entity, and how to represent an audience segment that is both definable (boolean expression over user attributes) and materializable (list of user IDs refreshed on a schedule).

I drew the core tables:

  • `advertiser(advertiser_id, billing_account_id, ...)`
  • `campaign(campaign_id, advertiser_id, start_ts, end_ts, budget, pacing_strategy)`
  • `line_item(line_item_id, campaign_id, bid, frequency_cap, targeting_expression)`
  • `creative(creative_id, advertiser_id, asset_url, duration_seconds)`
  • `creative_line_item(creative_id, line_item_id)` many-to-many
  • `audience_segment(segment_id, definition_json, last_materialized_ts)`
  • `segment_membership(segment_id, user_id, added_ts)` high-volume, partitioned
  • `impression_event(event_id, user_id, line_item_id, creative_id, ts, pod_position)`

Follow-ups: "Why did you pick that partition key for impression event?" I used (date, line item id) because reporting queries always bucket by time and slice by line item. "How would you sharding segment membership at a billion rows?" Consistent hash on user id , since lookups are "does user X belong to segment Y" rather than full segment enumeration.

Practice it: [[problem/29?company=6|Design Ads Data Modeling]]

Round 3: System Design, Ads Audience Targeting

Problem: Design a service that, given a user requesting a video, returns the set of ads eligible to serve that user. The service must support audience segment membership, frequency cap enforcement, budget pacing, latency under 50 ms at p99, and bulk upload of new segments from batch jobs.

This is a heavy ads-domain round. A generic "design a URL shortener" template will fail instantly. The interviewer expects you to know what candidate generation looks like in an ads system.

I broke it down into four planes:

  1. Targeting plane. For each request, two steps. First, segment-membership lookup for the user, fanning out to all segments they belong to. Second, an inverted index from segment ID to eligible line items, intersected with campaign state. Redis sets for the hot path, 1 minute TTL, cold write path Kafka to Flink to Redis.
  2. Frequency cap plane. Per user per line item per time window, backed by sharded Redis with expiry. Tradeoff: exact counts with atomic INCRs (slower at peak), or count-min sketches (fast but imprecise at the cap boundary).
  3. Budget pacing plane. Token bucket per line item, replenished by a scheduler that knows daily budget and hours remaining. Each serve decrements the bucket atomically.
  4. Bulk segment upload. S3 staging to Spark diff to Kafka delta events to online Redis. Key insight: never republish the full segment, only deltas, or a billion-user segment melts your cluster.

The interviewer spent the last 15 minutes on the frequency cap tradeoff. I said I would ship exact counts first and move to count-min only if INCR throughput bottlenecked. Pushback: two pods serving the same user simultaneously? I said the cap check is eventually consistent, so occasional single-impression overserve is cheaper than distributed locking.

Practice it: [[problem/28?company=6|Design Ads Frequency Cap System]]

Round 4: Manager Behavioral (45 min)

Standard Netflix culture questions driven by the deck. What Netflix actually filters on:

  • Ownership and explicit decisions (not "we decided to...", but "I decided, here is why")
  • Disagreement handling, including with your own manager
  • A story where you killed a project that was not working, cleanly

I had three prepared stories and only used two. The manager spent maybe half the time on a single incident where I had pushed for a design that later turned out to be wrong, and what I did when I realized. Netflix is famous for wanting calibrated people, not confident people. Make sure at least one of your stories has a genuine "I was wrong and here is how I corrected course" arc.

Round 5: Domain Experience Deep Dive

This round has no standard shape. The interviewer drilled on the one ads project on my resume, with depth beyond anything I have had at other companies:

  • Which specific feature ingested from which pipeline with which schema
  • What was the p99 of your service and what was the bottleneck
  • If you had to redesign it today, what would you change
  • Why did you pick that serialization format, what were the alternatives

If your domain story is not airtight for 45 minutes, Netflix will find the cracks. This is where the interview earns its reputation.

Result

Offer about a week after the loop. Comp at Netflix's standard top-of-market cash heavy package. The compensation conversation itself is a thing unto itself at Netflix, not negotiable in the way it is at Meta or Google.

Tips

  1. Ads platform knowledge is not optional for this team. The Round 3 interviewer told me, explicitly, that they had moved on from generic-design candidates. If you cannot discuss line items, frequency caps, and pacing strategies without being taught them during the interview, the loop will not go well.
  2. For Round 1, open with the interface. Netflix coding rounds reward clean abstraction. Do not jump into Python and expect the interviewer to pattern-match. Spend five minutes drawing the class relationships first.
  3. Bring a real story for Round 5, not a resume story. If the ads project on your resume was tangential, say so in Round 4 and pivot the deep dive to a project where you actually owned the hard parts. The interviewer will respect that more than a hedge.
  4. Data modeling is not a generic ERD exercise. Know the specific domain vocabulary. "Segment" versus "audience" versus "cohort" are all different things depending on the ads vendor. Use the ones the interviewer uses.
  5. Frequency cap is a test question, not a footnote. Every ads system design at Netflix ends up at frequency cap. Have your answer on exact versus approximate counts cached and ready with concrete numbers.
  6. Five rounds in one day is a stamina test. Eat before the 3 pm round. Block 30 minutes after for notes before you forget which interviewer asked what. I wrote up each round immediately after and it helped in the followup call.

Netflix is the most domain-biased loop I have done. If your background fits, it is a great experience. If it does not, study the domain before you apply, not during.