Meta Site Reliability Engineer Interview Questions (2026)

1. 1Recruiter screen30 minEasy

   Process overview, level calibration, and prep guidance — Meta recruiters actively coach on round formats.

2. 2Technical screen45 minHard

   Two DSA problems in 45 minutes on a plain shared editor with no autocomplete or execution.

3. 3Coding round ('Ninja')45 minHard

   Two more problems at loop difficulty; clean near-compilable code and verbalized complexity analysis expected.

4. 4System design ('Pirate')45 minHard

   Design a Meta-scale product system (feed, Stories, chat) with emphasis on read-heavy fan-out, caching, and data modeling.

5. 5Behavioral ('Jedi')45 minMedium

   Deep past-experience discussion on conflict, growth, and impact aligned to Meta values; graded as a real signal round.

1. Q1

   How would you build a capacity forecast for this service?

   Capacity PlanningMeta-specific

   Context: Production scenario: social feed ranking and fanout service traffic is growing steadily and leadership asks when capacity will become unsafe.

   How to answer: To build a capacity forecast, I would start by identifying key resource metrics (CPU, memory, network I/O, disk I/O) and business metrics (QPS, active users, data stored) that drive resource consumption. I'd then collect historical data for these metrics over a significant period (e.g., 6-12 months) and analyze trends, seasonality, and growth patterns. I would select appropriate forecasting models, such as ARIMA, Prophet, or simple linear regression, based on data characteristics and validate their accuracy using historical data. Finally, I would incorporate business growth projections and safety margins to produce a multi-horizon forecast (e.g., 1-week, 1-month, 3-month, 6-month) and establish a regular review and adjustment process.

2. Q2

   How would you prepare capacity for a known peak?

   Capacity PlanningMeta-specific

   Context: Production scenario: Meta expects a major traffic spike for social feed ranking and fanout service during a launch, holiday, or media event.

   How to answer: A strong answer outlines a data-driven approach starting with historical data analysis to identify peak characteristics (magnitude, duration, growth). It then covers forecasting techniques, considering both organic growth and specific event impacts, and translating forecasts into resource requirements (CPU, memory, network, storage). Finally, it details the execution plan, including procurement/provisioning lead times, testing with load simulations, and establishing monitoring and rollback strategies for the peak event.

3. Q3

   How would you identify the true capacity bottleneck?

   Capacity PlanningMeta-specific

   Context: Production scenario: social feed ranking and fanout service scales unevenly: CPU is fine, but database connections, network egress, or disk IOPS saturate first.

   How to answer: Start by defining capacity and identifying all potential resource constraints (CPU, memory, network I/O, disk I/O, database connections, third-party API limits). Implement comprehensive monitoring and alerting for these metrics across all service components. Conduct load testing and stress testing, gradually increasing traffic until a resource saturates or performance degrades. Analyze the results to pinpoint the specific resource that reaches its limit first, confirming it with system-level metrics and application logs. Finally, validate the bottleneck by observing its saturation during real-world peak traffic or by simulating its exhaustion.

4. Q4

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

   Capacity PlanningMeta-specific

   Context: Production scenario: Kubernetes clusters hosting messaging delivery pipeline show low average utilization but frequent pod scheduling failures.

   How to answer: A strong capacity plan for Kubernetes extends beyond average CPU/memory by considering peak usage, resource fragmentation, and critical resource types like network I/O and disk I/O. It involves analyzing historical P95/P99 metrics, understanding application-specific resource profiles (e.g., burstable workloads, memory-intensive jobs), and accounting for Kubernetes overhead (kube-system pods, daemonsets). Furthermore, it requires planning for node auto-scaling buffer, pod anti-affinity rules, and potential future growth or new service rollouts. Finally, a robust plan incorporates a 'what-if' analysis for failure scenarios and defines clear saturation limits for non-CPU/memory resources.

5. Q5

   How would you decide where capacity can be safely reduced?

   Capacity PlanningMeta-specific

   Context: Production scenario: Finance asks Meta to reduce infrastructure spend for social feed ranking and fanout service without violating SLOs.

   How to answer: A strong candidate would first identify services with excess capacity by analyzing historical utilization data (CPU, memory, network I/O) and current traffic patterns. They would then prioritize services based on their criticality, error budget, and blast radius. Safety would be ensured by considering redundancy levels (N+1, N+2), failure domain diversity, and the impact of a single host or zone failure. Finally, they would propose a phased reduction plan with robust monitoring, rollback capabilities, and load testing to validate the new capacity levels.

6. Q6

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

   Capacity PlanningMeta-specific

   Context: Production scenario: social feed ranking and fanout service 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. For normal conditions, it's typically a percentage (e.g., 20-30%) above peak demand, accounting for organic growth, minor spikes, and maintenance. For failure conditions, it's additional capacity to absorb the load of a failed component (e.g., a server, rack, or even an entire availability zone) without performance degradation or cascading failures. This often means N+1 or N+M redundancy, where 'N' is the minimum required capacity and '+1' or '+M' is the spare capacity for failures.

7. Q7

   How would you design a realistic load test?

   Capacity PlanningMeta-specific

   Context: Production scenario: A new version of social feed ranking and fanout service needs capacity validation before billions of read/write events per day.

   How to answer: A realistic load test requires understanding the system's architecture, identifying critical user journeys and their traffic patterns (e.g., peak hours, geographic distribution), and defining clear success metrics. The test environment should mirror production as closely as possible, and the load generation tool must support simulating diverse user behaviors and protocols. Finally, analyze results against defined SLOs/SLIs, identify bottlenecks, and iterate on the test design and system improvements.

8. Q8

   How would you plan regional capacity and traffic shifting?

   Capacity PlanningMeta-specific

   Context: Production scenario: cache-heavy multi-region architecture must serve traffic even if one region or edge location fails.

   How to answer: A strong answer would begin by outlining a phased approach to regional capacity planning, starting with demand forecasting based on historical trends, product roadmaps, and growth projections, broken down by region. Next, it would detail how to translate this demand into resource requirements (CPU, memory, storage, network) and then into physical infrastructure (servers, racks, power). For traffic shifting, the candidate should discuss strategies like DNS-based routing (e.g., weighted round robin, latency-based), load balancers (L4/L7), and application-layer controls, emphasizing gradual shifts with canary deployments and robust rollback plans. Finally, it should cover monitoring key metrics (latency, error rates, resource utilization) during shifts and having well-defined incident response procedures for unexpected issues.

9. Q9

   How would you plan and operate shard capacity?

   Capacity PlanningMeta-specific

   Context: Production scenario: A shard for social feed ranking and fanout service becomes hot while overall fleet utilization is moderate.

   How to answer: A strong answer would outline a phased approach starting with understanding current usage patterns and growth projections for each shard. It would then detail how to establish clear capacity metrics (e.g., CPU, memory, I/O, network) and define buffer policies. The candidate should discuss proactive monitoring, alert thresholds, and automated scaling mechanisms or manual rebalancing strategies (e.g., shard splitting, migration) to address hot shards or overall capacity shortfalls. Finally, it should touch upon regular capacity reviews, stress testing, and disaster recovery considerations.

10. Q10

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

    Capacity PlanningMeta-specific

    Context: Production scenario: social feed ranking and fanout service has enough compute, but database connection limits are exhausted during spikes.

    How to answer: A strong answer would begin by defining key metrics like QPS, latency, and error rates, and identifying the service's traffic patterns. It would then discuss how to determine optimal connection pool size by balancing throughput, latency, and resource utilization, often using Little's Law as a guiding principle. The candidate should explain how to model downstream concurrency limits based on the downstream service's capacity and an understanding of its resource bottlenecks (CPU, memory, I/O). Finally, the answer should emphasize the importance of load testing, monitoring, and iterative adjustment to validate the plan and adapt to changing conditions.

11. Q11

    How would you plan cache capacity and eviction policy?

    Capacity PlanningMeta-specific

    Context: Production scenario: Cache eviction rate for social feed ranking and fanout service rises, causing origin saturation and higher latency.

    How to answer: Capacity planning involves understanding workload patterns (read/write ratio, object size distribution, access patterns like Zipfian) and setting an appropriate cache size to achieve target hit rates and latency. This requires analyzing historical data and projecting future growth. Eviction policy selection (e.g., LRU, LFU, FIFO, ARC, LIRS) depends on the access patterns and desired performance characteristics, often aiming to maximize hit rate for a given cache size. A strong plan also considers cost, operational overhead, and monitoring for continuous optimization.

12. Q12

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

    Capacity PlanningMeta-specific

    Context: Production scenario: messaging delivery pipeline accumulates a large queue backlog during a partial outage.

    How to answer: To calculate backlog drain, first determine the current backlog size (items/bytes) and the ingestion rate. Next, identify the system's current processing capacity and its maximum sustainable processing capacity. Calculate the net drain rate by subtracting the ingestion rate from the processing capacity. Finally, estimate the time to drain by dividing the backlog size by the net drain rate and compare this against the freshness target deadline.

13. Q13

    How would you capacity-plan edge or CDN infrastructure?

    Capacity PlanningMeta-specific

    Context: Production scenario: points of presence serving mobile and web clients must absorb a sudden regional traffic shift while keeping social feed ranking and fanout service latency low.

    How to answer: A strong capacity plan for edge/CDN infrastructure starts with understanding traffic patterns (geographic distribution, peak vs. average, content types) and infrastructure capabilities (PoP locations, server specs, network bandwidth). Key steps include forecasting demand using historical data and growth projections, then modeling capacity requirements per PoP, considering redundancy and failover. Finally, implement a continuous monitoring and adjustment process, including stress testing and buffer capacity, to react to unforeseen spikes or changes in traffic.

14. Q14

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

    Capacity PlanningMeta-specific

    Context: Production scenario: Replication, logs, and customer traffic share network links for social feed ranking and fanout service.

    How to answer: A strong answer would start by defining the services and their traffic patterns, identifying critical services and their peak bandwidth requirements. It would then detail how to gather data (e.g., historical metrics, load testing) and project future growth using various forecasting methods. For protection, the candidate should discuss traffic prioritization (e.g., QoS, separate networks), admission control, and circuit breakers. Finally, it should cover monitoring, alerting, and regular review processes to adapt the plan.

15. Q15

    How would you plan storage capacity and retention?

    Capacity PlanningMeta-specific

    Context: Production scenario: Storage for social feed ranking and fanout service grows faster than forecast because retention and indexing changed.

    How to answer: A strong answer outlines a data-driven approach, starting with identifying key metrics like current usage, growth rate (daily/weekly/monthly), and data types. It then details forecasting methodologies (e.g., linear regression, exponential smoothing) and discusses factors influencing growth (e.g., new features, user growth, data retention policies). The plan should include defining buffer capacity, setting up monitoring and alerting for thresholds, and establishing a regular review cycle with stakeholders. Finally, it addresses data retention strategies, including tiered storage and data lifecycle management.

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

Be fast and correct on coding; for design, drive the conversation; prepare impact-focused behavioral stories

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

Other roles at Meta

Site Reliability Engineer interviews at other companies