Netflix interview prep

Use the STAR format: describe the context and the decision you disagreed with, the specific concern you raised and how you raised it (data, an experiment, or a clear argument), the outcome, and what you would do differently. Show that you can advocate for your position while remaining constructive, and that you can commit to a decision once it has been made even when you disagree.

What a strong answer covers: The goal is to show technical judgment and professional communication, not to relitigate old grievances. Avoid framing the story as you versus them. A strong answer includes evidence you used to make your case.

Follow-up: What would you do if the team made the same decision again and the outcome was worse than you predicted?

Last reviewed 2026-10-07

Use STAR: explain the project goal, what you built, what happened, and what you did next. Own your share of the failure rather than attributing it entirely to data, compute, or other constraints. Name a specific technical mistake — a leaky split, a flawed evaluation metric, a mislabeled dataset — not a vague sense that the model was wrong. Describe what you learned and how you applied it on a subsequent project.

What a strong answer covers: A strong answer names a specific technical root cause, not bad luck or insufficient time. The retrospective action matters as much as the failure itself.

Follow-up: What would be the first thing you would investigate if you had three days to debug the same project now?

Last reviewed 2026-10-07

Use STAR: describe the decision, what information was missing, what assumptions you made and why, how you documented those assumptions, and what you did to limit downside risk. Show that you can move forward without perfect information while keeping the team informed about your uncertainty and the conditions that would change your decision.

What a strong answer covers: This tests judgment and risk management. A strong answer distinguishes between uncertainty that is worth waiting to resolve and uncertainty you can safely assume away for now.

Follow-up: How did you decide what additional information was worth waiting for versus what you could assume away?

Last reviewed 2026-10-07

Use STAR: set the scene, describe the failure and how you found it, and explain how you communicated it. Lead with the business impact first, then explain the cause at a level the audience can act on. Show that you gave them what they needed to make a decision rather than a full technical post-mortem. Include what you proposed to fix and what the outcome was.

What a strong answer covers: The best answers show empathy for what the stakeholder needs to know, not just what you know. Avoid jargon without explanation and avoid false reassurance about a fix that is not yet validated.

Follow-up: How would you set up a review process to catch similar issues before they reach stakeholders?

Last reviewed 2026-10-07

Use STAR: describe the problem you noticed, why it was not clearly owned, what you chose to do, how you involved or informed the right people, and the outcome. Show judgment about when to escalate versus act, and demonstrate that you understood the constraints and worked within or around them thoughtfully rather than bypassing important processes.

What a strong answer covers: This tests initiative and judgment. Interviewers probe whether you involved the right people at the right time. A strong answer shows you didn't silently take over someone else's work.

Follow-up: How did you decide this was your problem to solve rather than someone else's?

Last reviewed 2026-10-07

Find each user's first-seen date, group users into weekly cohorts, then count how many returned within 30 days. Divide retained users by cohort size to get the retention rate.

-- Table: events(user_id BIGINT, event_date DATE)
WITH first_seen AS (
    SELECT user_id, MIN(event_date) AS cohort_date
    FROM events
    GROUP BY user_id
),
cohort_size AS (
    SELECT
        DATE_TRUNC('week', cohort_date) AS cohort_week,
        COUNT(DISTINCT user_id)          AS total_users
    FROM first_seen
    GROUP BY 1
),
retained AS (
    SELECT
        DATE_TRUNC('week', f.cohort_date) AS cohort_week,
        COUNT(DISTINCT e.user_id)          AS retained_users
    FROM first_seen f
    JOIN events e
      ON  e.user_id    = f.user_id
      AND e.event_date >  f.cohort_date
      AND e.event_date <= f.cohort_date + INTERVAL '30 days'
    GROUP BY 1
)
SELECT
    c.cohort_week,
    c.total_users,
    COALESCE(r.retained_users, 0)                                    AS retained_users,
    ROUND(COALESCE(r.retained_users, 0)::numeric / c.total_users, 3) AS retention_rate
FROM cohort_size  c
LEFT JOIN retained r USING (cohort_week)
ORDER BY c.cohort_week;

What a strong answer covers: COALESCE handles cohorts with zero retention. The strict inequality on event_date excludes the sign-up day itself from the retained count. Clarify with the interviewer whether returning on the same day should count.

Follow-up: How would you extend this to compute 7-day, 30-day, and 90-day retention in a single query?

Last reviewed 2026-10-07

Define a proxy for long-term value: subscription retention, weekly active days, content satisfaction ratings, or a composite. Train a model to predict this metric rather than next-click engagement. Use offline simulation to check that optimising the proxy actually changes the long-term outcome, and run online experiments with a measurement window long enough to observe retention effects. Instrument the system to log counterfactuals so you can estimate long-term effects from historical data.

What a strong answer covers: Short-term engagement optimises for what is clickable, which can surface addictive or low-quality content. The hardest part is defining and measuring long-term value before you can optimise for it.

Follow-up: How would you measure whether a recommendation change improved long-term satisfaction in an A/B test that must conclude in two weeks?

Last reviewed 2026-10-07

Use content-based features: genre, cast, director, themes, and description embeddings, matched against content the user has watched. Allocate a small exploration fraction of impressions to new titles using upper confidence bound or Thompson sampling, balancing exposure with early quality signals such as completion rate and ratings as they accumulate. Retire the cold-start treatment once the item has enough interaction data for the collaborative model.

What a strong answer covers: The exploration fraction is a business decision: too little and new content is never discovered; too much and user experience degrades. Mention that the cold-start problem for new users and new items are separate problems with different solutions.

Follow-up: How would you decide when a title has accumulated enough watch history to graduate from cold-start treatment?

Last reviewed 2026-10-07