Netflix Site Reliability Engineer Interview Questions (2026)

1. 1Hiring manager screen45 minMedium

   Manager probes seniority, autonomy, and whether your judgment fits a high-freedom, high-responsibility team.

2. 2Technical screen60 minHard

   Practical coding or problem solving in your domain — often closer to real work (data modeling, service code) than LeetCode drills.

3. 3System design round60 minHard

   Design streaming-scale infrastructure with honest tradeoff defense — resilience, regional failover, and cost at Netflix scale.

4. 4Domain deep-dive with team60 minHard

   Future teammates drill into your past systems, expecting staff-level depth and candid discussion of failures.

5. 5Culture interview45 minMedium

   Explicit culture-memo round on candor, Freedom & Responsibility, and keeper-test-worthy impact, run by a manager or partner team.

6. 6Leadership close30 minMedium

   Director-level conversation confirming seniority, compensation philosophy fit (top-of-market cash), and mutual expectations.

1. Q1

   How would you build a capacity forecast for this service?

   Capacity PlanningNetflix-specific

   Context: Production scenario: streaming playback API traffic is growing steadily and leadership asks when capacity will become unsafe.

   How to answer: To build a capacity forecast for a Netflix service, I would start by identifying key metrics like requests per second (RPS), CPU utilization, memory usage, and network I/O, along with their historical trends and seasonality (e.g., daily peaks, weekend surges, new show launches). I would then select an appropriate forecasting model, such as ARIMA, Prophet, or even simpler moving averages, depending on data characteristics and desired accuracy. Data sources would include Atlas for metrics and internal logging systems for business events. Finally, I'd incorporate business drivers like subscriber growth, content release schedules, and A/B test plans, using scenario analysis to project future demand and validate the forecast against actual usage, iterating as needed.

2. Q2

   How would you prepare capacity for a known peak?

   Capacity PlanningNetflix-specific

   Context: Production scenario: Netflix expects a major traffic spike for streaming playback API during a launch, holiday, or media event.

   How to answer: A strong answer would emphasize historical data analysis to understand the peak's magnitude, duration, and growth trends, considering both service-level and resource-level metrics. It would then detail a phased approach: forecasting future demand, provisioning additional resources (e.g., EC2 instances, database capacity) with a safety margin, and pre-warming or scaling up infrastructure. Finally, it would include a robust monitoring plan during the peak and a post-peak review to refine future capacity planning models and processes.

3. Q3

   How would you identify the true capacity bottleneck?

   Capacity PlanningNetflix-specific

   Context: Production scenario: streaming playback API scales unevenly: CPU is fine, but database connections, network egress, or disk IOPS saturate first.

   How to answer: A strong answer would emphasize starting with a clear definition of 'capacity' for the service, then leveraging a combination of monitoring, load testing, and profiling. Candidates should discuss using metrics (CPU, memory, network I/O, disk I/O, database connections, thread pools) to identify resource saturation points under increasing load. The true bottleneck is often not the first resource to hit 100%, but rather the one that, when optimized, yields the largest increase in overall system throughput or reduction in latency. Finally, they should mention iterative testing and analysis to confirm the bottleneck and validate fixes.

4. Q4

   How would you plan cluster capacity beyond average CPU and memory?

   Capacity PlanningNetflix-specific

   Context: Production scenario: Kubernetes clusters hosting control plane that selects CDN paths show low average utilization but frequent pod scheduling failures.

   How to answer: A strong answer would go beyond average CPU/memory to discuss resource types like ephemeral storage, network bandwidth, and I/O operations (IOPS). It would emphasize the importance of understanding application-specific resource profiles and peak usage patterns, not just averages. Furthermore, it would touch upon the need to account for Kubernetes overhead (kube-system pods, daemonsets), future growth, and redundancy/failover requirements. Finally, it would mention using tools for profiling, monitoring, and predictive analytics to inform capacity decisions.

5. Q5

   How would you decide where capacity can be safely reduced?

   Capacity PlanningNetflix-specific

   Context: Production scenario: Finance asks Netflix to reduce infrastructure spend for streaming playback API without violating SLOs.

   How to answer: A strong answer would begin by emphasizing data-driven decisions, specifically analyzing historical usage patterns (CPU, memory, network I/O) and identifying peak vs. average utilization. It would then discuss identifying non-critical services or components with high redundancy and low blast radius. The candidate should mention leveraging chaos engineering and load testing to validate assumptions and ensure reductions don't impact SLOs/SLAs, and finally, implementing a phased rollout with robust monitoring and rollback capabilities.

6. Q6

   How would you define healthy headroom for normal and failure conditions?

   Capacity PlanningNetflix-specific

   Context: Production scenario: streaming playback API runs at 65% CPU most days but incidents occur when a zone fails and traffic shifts.

   How to answer: Healthy headroom is the excess capacity available beyond current demand, ensuring service stability and performance. For normal conditions, it's typically a percentage buffer (e.g., 20-30%) above peak observed traffic, accounting for organic growth and minor spikes. For failure conditions, it must accommodate the loss of an entire availability zone (AZ) or a significant percentage of instances within an AZ, while still maintaining normal operating capacity in the remaining infrastructure. This often means designing for N+1 or N+M redundancy, where 'N' is the required capacity and '+1' or '+M' is the buffer for failure, ensuring no user impact during recovery.

7. Q7

   How would you design a realistic load test?

   Capacity PlanningNetflix-specific

   Context: Production scenario: A new version of streaming playback API needs capacity validation before global evening traffic peaks.

   How to answer: A realistic load test design involves first defining clear objectives and identifying critical user journeys. Next, analyze historical production traffic patterns (e.g., request rates, concurrency, peak times, geographical distribution) and system metrics to create a representative workload model, including different user types and their actions. Then, select appropriate tools and infrastructure, ensuring the test environment mirrors production as closely as possible. Finally, execute tests incrementally, monitor key performance indicators (KPIs) and resource utilization, and analyze results to identify bottlenecks and validate scalability.

8. Q8

   How would you plan regional capacity and traffic shifting?

   Capacity PlanningNetflix-specific

   Context: Production scenario: cloud-native microservices across regions must serve traffic even if one region or edge location fails.

   How to answer: A strong answer would begin by outlining the need for robust forecasting (historical data, growth projections, new service launches) to determine baseline capacity requirements per region. It would then detail the strategy for provisioning capacity, including a buffer for unexpected spikes and failover, and the use of diverse instance types/zones within a region. The candidate should explain how traffic shifting is enabled through DNS (e.g., Route 53), load balancers (e.g., ELB/ALB), and application-level routing, emphasizing automated health checks and progressive rollouts. Finally, the answer should touch upon regular capacity reviews, auto-scaling mechanisms, and disaster recovery drills to validate the plan.

9. Q9

   How would you plan and operate shard capacity?

   Capacity PlanningNetflix-specific

   Context: Production scenario: A shard for streaming playback API becomes hot while overall fleet utilization is moderate.

   How to answer: A strong answer would begin by defining sharding and its purpose in distributed systems, specifically for scalability and fault isolation. It would then detail the capacity planning process for shards, including workload characterization (e.g., QPS, latency, data size per shard), resource modeling (CPU, memory, network, disk I/O), and defining safety margins. The operational aspect would cover dynamic scaling strategies (e.g., rebalancing, adding/removing shards), monitoring key shard-level metrics, and having runbooks for common capacity-related issues like hot shards or under-provisioning. Finally, it would touch upon testing capacity plans and disaster recovery considerations.

10. Q10

    How would you capacity-plan connection pools and downstream concurrency?

    Capacity PlanningNetflix-specific

    Context: Production scenario: streaming playback API has enough compute, but database connection limits are exhausted during spikes.

    How to answer: Capacity planning for connection pools and downstream concurrency involves understanding the application's request rate, latency requirements, and the characteristics of the downstream service. Start by profiling typical request patterns and identifying peak loads. Then, use Little's Law to relate concurrency, throughput, and latency, and apply queuing theory principles to model the pool size. Finally, consider failover scenarios, retry mechanisms, and the impact of connection pool settings on both upstream resource utilization and downstream service stability, iterating with load testing.

11. Q11

    How would you plan cache capacity and eviction policy?

    Capacity PlanningNetflix-specific

    Context: Production scenario: Cache eviction rate for streaming playback API rises, causing origin saturation and higher latency.

    How to answer: A strong answer outlines a data-driven approach, starting with identifying key metrics like hit rate, latency, and memory usage. It then describes a process for collecting and analyzing production traffic patterns (e.g., request rates, object sizes, access frequencies) to project future growth and determine optimal cache size. For eviction policy, it discusses evaluating common algorithms (LRU, LFU, ARC) based on observed access patterns and workload characteristics, potentially using simulation or A/B testing. Finally, it emphasizes continuous monitoring, alerting, and periodic re-evaluation of both capacity and policy.

12. Q12

    How would you calculate whether the system can drain backlog before violating freshness targets?

    Capacity PlanningNetflix-specific

    Context: Production scenario: control plane that selects CDN paths accumulates a large queue backlog during a partial outage.

    How to answer: To determine if a system can drain a backlog before violating freshness targets, one must first quantify the current backlog size (e.g., number of items, bytes). Next, calculate the system's current processing rate (items/second, MB/second) and the required processing rate to meet the freshness target, considering the backlog and the target time. Compare the current processing rate against the required rate, factoring in any incoming data rate. If the current rate is insufficient, identify bottlenecks (CPU, I/O, network, memory) and propose scaling strategies (horizontal/vertical) to increase capacity, then re-evaluate.

13. Q13

    How would you capacity-plan edge or CDN infrastructure?

    Capacity PlanningNetflix-specific

    Context: Production scenario: CDN and edge-routing layer must absorb a sudden regional traffic shift while keeping streaming playback API latency low.

    How to answer: A strong capacity plan for edge/CDN infrastructure starts with understanding traffic patterns, including peak loads, geographic distribution, and content types, using historical data and forecasting models. It involves modeling the capacity of individual edge nodes (CPU, memory, network I/O, disk I/O) and aggregating these to regional and global capacities. Critical considerations include redundancy (N+1, N+M), burst capacity for unexpected spikes, and the impact of new features or content. Finally, the plan should incorporate regular load testing, monitoring of key metrics, and an iterative feedback loop for continuous refinement.

14. Q14

    How would you capacity-plan bandwidth and protect critical traffic?

    Capacity PlanningNetflix-specific

    Context: Production scenario: Replication, logs, and customer traffic share network links for streaming playback API.

    How to answer: A strong capacity plan for bandwidth involves understanding current and projected traffic patterns, categorizing traffic by criticality, and implementing mechanisms for protection. Key steps include baselining current usage, forecasting growth based on business metrics and historical trends, and modeling peak scenarios. Critical traffic protection involves implementing QoS/traffic shaping, redundant network paths, and auto-scaling network resources. Regularly review and adjust the plan based on actual usage and new service deployments.

15. Q15

    How would you plan storage capacity and retention?

    Capacity PlanningNetflix-specific

    Context: Production scenario: Storage for streaming playback API grows faster than forecast because retention and indexing changed.

    How to answer: A strong answer outlines a data-driven approach, starting with identifying critical metrics like current usage, growth rate (daily/weekly/monthly), and data types/lifecycle. It then details forecasting methodologies (e.g., linear regression, seasonal adjustments) and the importance of buffer capacity. Finally, it addresses retention policies, data tiering (hot/warm/cold), and the need for regular review and automation to adapt to changing needs and prevent outages.

Practice these with instant AI feedback in a live mock interview → Start a Netflix Site Reliability Engineer mock

Demonstrate senior-level judgment and ownership; study Netflix's culture memo; be ready for candid discussions

Indicative Site Reliability Engineer pay in India: ~₹12–52 LPA (role-level range, not a Netflix-specific figure).

Other roles at Netflix

Site Reliability Engineer interviews at other companies