# Model Answer: The Netflix Memo Walkthrough This is not a coding problem with one right answer — it's a communication and judgment test. The interviewer is reading *how* you think and whether your written memo, your stories, and your level claim form one coherent, high-signal narrative. Below is a model framework, a fully worked example you can adapt, and what "good" looks like for each of the five parts. Everywhere you see a number, treat it as an **illustrative placeholder** — substitute your own real, defensible metrics. ## How to run the walkthrough (5–7 minutes) Lead with conclusions, support with specifics — this mirrors the memo format Netflix is testing. 1. **Memo overview** — one sentence on problem + why now, then goal and non-goals. 2. **2–4 key decisions** — each as *choice → rejected alternative → trade-off → mitigation.* 3. **Metrics** — primary metric, guardrails, and how you'd attribute impact. 4. **Culture mapping** — 2–3 Netflix principles, each backed by one STAR story with quantified results. 5. **Level** — a confident recommendation justified by scope, ambiguity, cross-team influence, and outcomes, plus why not the adjacent level. A note on Netflix's culture: the current values center on **judgment, selflessness, courage, communication, inclusion, curiosity, innovation, and impact**, plus the long-standing operating ideas of **"people over process"** and **"context, not control"** (managers give context and let people make decisions). Map to the principles your evidence genuinely supports — do not recite all of them. --- ## Part 1 — Memo Overview **What good looks like:** the listener knows the stakes within a minute, and the goal is bounded with explicit non-goals. Template: - **Problem + why now (one sentence):** "X is costing us [metric/user pain]; it matters now because [urgency: growth inflection, reliability risk, strategic shift]." - **Goal:** a single, measurable outcome. - **Scope / non-goals:** what you deliberately excluded — the clearest signal of prioritization. **Worked example (sample memo topic — improving a member-facing API):** - *Problem & why now:* "Our member-facing recommendations API has crept to a p95 of ~350 ms and 99.95% availability; tail latency is now correlated with session drop-off, and traffic is projected to double next year, so the current architecture won't hold." - *Goal:* "Cut p95 to ≤150 ms and raise availability to ≥99.99% within two quarters, without regressing ranking quality." - *Non-goals:* "No changes to the ranking model itself, and no UI work — this is purely the serving and data-access path." --- ## Part 2 — Key Decisions and Trade-offs **What good looks like:** 2–4 decisions where the answer wasn't obvious, each with a genuinely considered alternative and an explicitly accepted risk + mitigation. Use this shape per decision: **chosen option → main alternative → trade-off accepted → mitigation.** Worked example (three decisions for the API memo): 1. **Active-active multi-region vs. active-passive** - Chose active-active to remove the regional single point of failure and shave tail latency by serving from the nearest region. - Trade-off: cross-region consistency and operational complexity. - Mitigation: idempotency keys, per-endpoint consistency levels (strong for writes, read-your-writes where required), and chaos/failover drills before GA. 2. **gRPC for internal service-to-service vs. staying on REST/JSON** - Chose gRPC for the chatty internal hop to cut serialization overhead; kept REST at the edge for client compatibility. - Trade-off: tooling and team ramp-up. - Mitigation: a shared IDL/proto repo, codegen, and lint rules so the change scaled across teams. 3. **Read cache (with CQRS) on the hot read path vs. a single read/write path** - Chose a short-TTL read cache for read-heavy endpoints. - Trade-off: staleness risk. - Mitigation: TTL with background refresh, fast invalidation on writes, and cache-bypass for sensitive flows. The point isn't these specific choices — it's that each one names the alternative, the cost you accepted, and how you contained the downside. --- ## Part 3 — Metrics and Expected Impact **What good looks like:** a primary metric, guardrails, and a credible attribution method — with honesty about measured vs. projected numbers. - **Primary success metrics:** p95/p99 latency, availability (error-budget burn). - **Guardrails (must not break):** correctness/ranking quality, error rate, cost per 1k requests, downstream saturation (queue depth, CPU). - **Attribution / measurement:** phased canary (1% → 10% → 50% → 100%) with automated rollback on guardrail breach; A/B where a business metric is involved, with a sample-ratio-mismatch (SRM) check and a pre-specified minimum detectable effect so you don't p-hack a result. Useful framing formulas: - Availability $= 1 - \dfrac{\text{downtime}}{\text{total\_time}}$ - Error rate $= \dfrac{\text{errors}}{\text{requests}}$ - Cost per 1k requests $= \dfrac{\text{total\_cost}}{\text{requests}/1000}$ **Expected impact (illustrative — replace with your real data):** - p95 350 → 150 ms; availability 99.95% → 99.99% (~4× fewer down-minutes/month); error rate 0.8% → 0.2%; cost/1k req down ~20% via right-sizing + caching. - *Business translation:* "We hypothesize a latency reduction of this size lifts session conversion by a fraction of a point; I'd treat that as a projection and validate it with an A/B test rather than claim it as fact." Naming the line between measured and projected is itself a strong signal. --- ## Part 4 — Culture Mapping and Evidence **What good looks like:** 2–3 principles your memo *and* a real story both demonstrate, told in STAR form with first-person actions, quantified results, and the principle named explicitly. Map memo elements to principles, for example: - **Judgment:** explicit trade-offs, clear success/failure criteria, scoped non-goals. - **Communication:** the memo and ADRs themselves — high-context writing that lets others act autonomously ("context, not control"). - **Courage / candor:** pre-mortems, a documented risk register, owning the risks you accepted. - **Impact / curiosity:** ambitious but measurable targets; reusable tooling that multiplies other engineers. **Story 1 — Zero-downtime auth migration (Judgment, Courage, Communication)** - *Situation:* A legacy single-region auth service ran at p95 ≈ 420 ms and 99.95% availability with frequent escalations. - *Task:* Lead a multi-quarter migration to a multi-region, lower-latency design with no user-visible downtime. - *Action:* Introduced an auth abstraction layer, traffic mirroring, idempotency tokens, deterministic conflict handling, staged canaries, and weekly risk reviews with SRE and Product; made the call to delay GA by two weeks when chaos tests surfaced a consistency edge case. - *Result:* Availability 99.95% → 99.99% (~75% fewer down-minutes), p95 420 → 180 ms, login success +0.5 pp, P1 incidents −80%; coordinated 4 teams over 6 months. - *Principle:* judgment under ambiguity, candor in surfacing the risk, communication via ADRs that kept teams autonomous. **Story 2 — Payments resiliency and safe retries (Impact, Selflessness, Inclusion)** - *Situation:* Checkout drop-offs from a flaky gateway plus duplicate-charge risk under retries. - *Task:* Raise payment success and protect users with transparent, safe failover. - *Action:* Built a payment orchestration layer over multiple processors with idempotency keys, circuit breakers, and dynamic routing; aligned Legal, Finance, and Support on retry/refund policy; shipped behind guardrailed A/B. - *Result:* Payment success +1.2 pp, duplicate charges → near-zero, P1s −70%; standardized runbooks adopted by 3 teams. - *Principle:* bias to measurable impact; selflessness/inclusion in cross-functional alignment that let other teams move faster. Tell stories where *you* made the hard call — courage is shown through a real disagreement or trade-off, not adjectives. --- ## Part 5 — Level Calibration (L5 vs. L4) **What good looks like:** a confident recommendation grounded in the same evidence from Parts 2–4, plus an explicit contrast with the adjacent level. Calibration axes: - **Scope & ambiguity:** Senior (L5) typically owns *ambiguous, cross-team* problems end-to-end; strong-IC (L4) executes excellently within a more defined scope. - **Ownership without authority:** influencing partner teams via ADRs, shared metrics, and design reviews. - **Technical depth:** designing the system *and* its safety net (canaries, error budgets, chaos), plus reusable standards. - **Outcomes:** durable, quantified wins. **Recommendation (example): L5 / Senior.** - *Scope & ambiguity:* led multi-quarter, cross-team programs in genuinely open-ended problem spaces, defining strategy, interfaces, and SLOs. - *Influence without authority:* drove consensus across 4+ partner teams through written context, not mandate. - *Depth + outcomes:* designed multi-region, low-latency systems with guardrails; delivered double-digit latency/availability gains and −70–80% P1s. - *Why not L4:* "Beyond shipping features within one team, I owned the cross-team roadmap and made org-level trade-offs — that ownership of ambiguity is the L4→L5 line for me." If your evidence is narrower, it is *stronger* to argue L4 confidently — deep execution excellence plus readiness to grow into cross-team scope — than to overclaim L5 and have it unravel under follow-ups. Mis-calibration in either direction is the failure mode here. --- ## Addressing the follow-ups - **"A decision you'd make differently":** Pick a real one and show learning — e.g., "I'd start the cache layer with stricter invalidation from day one; we spent a sprint debugging staleness we could have designed out." This demonstrates curiosity and honest self-review, not weakness. - **"Metrics came back worse than expected":** Describe catching it via guardrails/SRM, rolling back via the canary, root-causing, and re-shipping — the safety net working as designed beats a story where nothing went wrong. - **"Where you disagreed with a stakeholder":** This is the courage/candor probe — name the disagreement, your reasoning, how you escalated or were overruled, and the outcome. Disagreeing well (and committing) is the signal. - **"Hired one level below — first 90 days":** Show you'd take a high-scope, high-ambiguity problem, deliver a measurable win, and build cross-team trust — i.e., demonstrate the next level's behaviors rather than waiting for the title. ## Common failure modes to avoid - A memo with no non-goals (reads as unscoped) or decisions with no rejected alternative (reads as unconsidered). - Vanity metrics with no guardrails or attribution — claiming causality you can't defend. - Generic culture buzzwords with no STAR evidence, or stories that use "we" and never reveal *your* call. - Over- or under-leveling: a level claim that the projects in Parts 2–4 don't support. - Running long — keep the walkthrough to 5–7 minutes and invite the interviewer to probe.