HackTheRounds Interview Experiences

Netflix Data Engineer Interview Experience (2026) - Recommendation Pipeline, Star Schema & A/B Testing, Offer

Netflix Data Engineer onsite: 6 rounds covering real time recommendation pipeline, SQL binge watch sessionization, lineage tracking, schema validation, star sch

By Anonymous ยท 2025-09-10

Background

I'd been working as a data engineer for about five years, mostly at a streaming analytics shop where I owned a Kafka ingest pipeline and the warehouse layer it fed. A friend who flipped to Netflix the year before pinged me when his org opened a senior DE req on the experimentation and content analytics warehouse team. Because Netflix runs each team as its own hiring entity, the loop leaned heavily on streaming, schema design, and experimentation infrastructure rather than pure algorithm grinding.

Timeline

Total: about 7 weeks.

Recruiter Call (45 min)

The recruiter screened motivation hard. Why Netflix specifically, what scale of data I had operated, and which of Kafka, Spark, and Presto I had run in production. I anchored my answers on a Kafka exactly-once project from my last role and a Presto rollout that replaced a creaky Hive footprint. The Culture Memo came up explicitly on the recruiter call rather than waiting for the onsite, which surprised me.

Technical Screen (60 min)

Live coding plus a small SQL exercise. The coding portion was Python: implement a streaming aggregator that keeps the top-k most-viewed titles over the last N events, with the constraint that titles can fall out of the top-k as the window slides. I used a doubly linked list paired with a hash map keyed by title to get amortized constant-time updates, which the interviewer accepted but pushed me on memory bounds when N was large.

The SQL exercise asked for the longest streak of consecutive days a single user watched at least one title. Window functions, gaps-and-islands. I solved it with a ROW NUMBER minus dense rank trick over a date series and walked the interviewer through the islands.

Virtual Onsite (6 rounds)

Round 1: Real-time Recommendation Pipeline

Problem: Design the data ingestion and serving pipeline behind a real-time recommendation engine. Cover ingest, online and offline feature engineering, model serving, and how late-arriving events are reconciled with the warehouse.

I opened with Kafka topics partitioned on user id for ingest, then a Flink job for online feature derivation that wrote to a feature store, with a parallel nightly Spark job for slower features. Model serving was a stateless container behind a service mesh that pulled live features and historical embeddings on request. The interviewer pressed on late-arriving events and I walked through watermarking, allowed lateness, and a side-output channel for events that arrived after the watermark fired so the offline pipeline could backfill into the warehouse.

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

Round 2: SQL Over Viewing Events

Problem: From a viewing events table, return the top 10 titles that were binge-watched in the past month, where binge-watching is defined as a session of at least four consecutive episodes within a twelve-hour window.

Window functions all the way. I sessionized first by user and title with a gap-based session id, lagging the timestamp and marking a session break when the gap exceeded the threshold, then counted episodes per session, kept sessions of at least four, and finally aggregated binge sessions per title. The interviewer pushed on what happens when sessions span midnight and on whether count(distinct episode id) was needed if the data carried duplicates, which it apparently does in their feed.

Round 3: Data Lineage Tracking

Problem: How would you track the path of a single record from source ingest through every transform to the final report it lands in? Make it durable, queryable, and column-level.

I argued for an explicit metadata catalog with column-level lineage, harvested both at job runtime through a Spark and Flink listener and statically by parsing job DAGs at submission time. I sketched a graph store keyed by dataset and column, with edges carrying the transform that produced them. The interviewer drilled on durability, asking what happens when a lineage event is dropped, and I owned the gap by talking through a write-ahead log into Kafka and a sweeper that re-reads recent jobs from the metastore for reconciliation.

Round 4: Streaming Data Quality Monitoring

Problem: A producer changes a schema in a streaming feed. Design the safeguards that catch the change before it corrupts a downstream report.

I built the answer in three layers. Schema registry with backward and forward compatibility checks at producer time. Runtime schema validation at the consumer with a quarantine topic for nonconforming records. A slower data drift layer that watches null ratio, distinct cardinality, and outlier rate per field over a rolling baseline. Alerts get tiered: hard alerts at the validation layer page on call, drift alerts go to a Slack channel for analyst triage. The interviewer asked how I would distinguish a real upstream bug from a legitimate distribution shift after a marketing campaign, and I conceded that the answer is rarely automatic and usually requires a human review queue.

Round 5: Warehouse Schema for Content Analytics

Problem: Design the warehouse model for content viewing analytics. Optimize for daily title rollups, geographic breakdowns, and slowly evolving title attributes like genre tags and country availability.

Star schema. The fact table at the grain of one row per playback session, with session id , user id , title id , device id , geo id , start ts , watch seconds . Dimensions for title, device, geography, and date. Slowly Changing Dimension Type 2 on the title dimension so when Netflix reclassifies a genre or pulls a title from a region, history stays intact for retroactive reporting. The interviewer pushed on retention and clustering keys, and I argued for (date, title id) since most reporting filters on date and aggregates on title.

Round 6: A/B Testing Pipeline

Problem: Design the experimentation pipeline. Variant assignment, telemetry, analysis, multiple-comparison correction, all at Netflix scale.

I built the answer in four blocks. Assignment via deterministic hash on user id with a sticky cache so a user sees the same variant across sessions. Telemetry through events tagged with experiment id and variant id, persisted to the warehouse alongside the rest of the event stream. Analysis as a daily job that emits primary, secondary, and guardrail metrics with confidence intervals, plus sequential testing to avoid peeking bias on long-running experiments. Multiple comparisons handled with Benjamini-Hochberg when an experiment carried more than a handful of metrics. The interviewer pushed on cluster randomization for cases where users could influence each other, and I conceded that user-level assignment breaks down for social features and pivoted to clustered designs.

Result

Offer about seven weeks after the resume screen. Netflix's offer is heavy on cash and light on equity by design, which I had heard about before but still found striking on paper. The recruiter walked me through the band quickly, gave me a few days to decide, and that was that.

Tips

  1. Pre-read the Culture Memo before the recruiter call, not before the onsite. The motivation questions land in the very first conversation, and the recruiter is scoring whether your reasons map to Freedom and Responsibility. I had seen people lose the loop on the recruiter call and not understand why.
  2. SQL window functions are not optional. Every Netflix DE round I had touched used either gaps-and-islands or rank-over-partition logic. Spend a focused weekend on `LAG`, `LEAD`, `ROW_NUMBER`, and `NTILE` until you can write them without thinking.
  3. Kafka, Spark, and Presto are the price of admission. Interviewers expect you to articulate exactly-once semantics, watermarking, and Presto query planning. Have at least one production war story for each.
  4. A/B testing infrastructure is a separate study area from experimentation theory. Knowing what a p-value is is not enough. Netflix wants you to build the platform that runs thousands of experiments concurrently without contaminating each other.
  5. Slowly Changing Dimensions matter for content analytics. Netflix titles get reclassified, pulled, and re-released constantly. SCD Type 2 came up in three rounds for me. Know the bookkeeping at column level.
  6. Cash-heavy offers compress equity-tax mental models. If you have offers from Meta or Google to compare against, be ready for a careful spreadsheet, because the comparison is not apples to apples.