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 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.

2. Q2

   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.

3. Q3

   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.

4. Q4

   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.

5. Q5

   How would you plan capacity for autoscaling lag?

   Capacity PlanningMeta-specific

   Context: Production scenario: Autoscaling eventually adds enough capacity for social feed ranking and fanout service, but user impact occurs during warm-up.

   How to answer: A strong answer identifies autoscaling lag as the time delay between a demand increase and the autoscaler provisioning new capacity. Key strategies include maintaining a buffer of pre-warmed capacity, predicting future load using historical data and leading indicators, and optimizing autoscaler configuration (e.g., faster scale-out policies, aggressive cooldown periods). Implementing proactive scaling based on predictive models or scheduled events, rather than purely reactive metrics, is also crucial. Finally, designing services to gracefully degrade under temporary overload can mitigate the impact of residual lag.

6. Q6

   How would you define capacity in terms of SLO rather than raw throughput?

   Capacity PlanningMeta-specific

   Context: Production scenario: social feed ranking and fanout service can handle target QPS, but p99 latency violates SLO beyond 70% utilization.

   How to answer: Capacity in terms of SLO means defining the maximum load a system can handle while still meeting its Service Level Objectives, rather than just its raw throughput. This involves understanding how latency, error rates, and other SLOs degrade under increasing load. A strong answer would discuss using load testing and saturation metrics to identify the 'knee' or 'cliff' where SLOs begin to be violated. It also implies that capacity is dynamic and dependent on the specific SLOs being measured, and that headroom is needed to absorb spikes without SLO breaches.

7. Q7

   How would you capacity-plan scarce resource pools?

   Capacity PlanningMeta-specific

   Context: Production scenario: social feed ranking and fanout service depends on scarce specialized hardware or high-memory nodes in Kubernetes.

   How to answer: A strong capacity plan for scarce resources involves understanding current utilization and growth trends, identifying all consumers and their priority, and establishing clear allocation policies. It requires robust monitoring, forecasting based on historical data and anticipated demand spikes, and a mechanism for resource requests and approvals. Implementing a tiered system for resource access, potentially with chargebacks or internal SLAs, can help manage demand and incentivize efficient use. Regular reviews and adjustments based on actual consumption and project timelines are crucial for maintaining balance.

8. Q8

   How would you plan shared capacity for batch and online workloads?

   Capacity PlanningMeta-specific

   Context: Production scenario: Batch processing related to messaging delivery pipeline steals CPU, cache, or I/O capacity from online traffic.

   How to answer: A strong answer would begin by identifying the core tension: batch workloads are typically latency-tolerant and resource-intensive, while online workloads are latency-sensitive and often bursty. The planning strategy should focus on isolation mechanisms, such as resource quotas (CPU, memory, I/O) and cgroups, to prevent batch from impacting online. Dynamic resource allocation and preemption for batch jobs during online peak hours, possibly leveraging a scheduler like Mesos or Kubernetes, would be key. Finally, the candidate should mention monitoring and feedback loops to continuously tune resource allocations and identify potential contention.

9. Q9

   How would you communicate capacity forecast uncertainty?

   Capacity PlanningMeta-specific

   Context: Production scenario: Growth projections for social feed ranking and fanout service vary widely because product plans and traffic mix are uncertain.

   How to answer: A strong answer would emphasize using probabilistic forecasts (e.g., P50, P90, P99) to quantify uncertainty, rather than single point estimates. Candidates should discuss visualizing this uncertainty through confidence intervals or ranges on graphs. They should also mention tailoring the communication based on the audience (e.g., engineers need specific percentiles, leadership needs high-level risk summaries) and clearly stating the assumptions and potential risks that could impact the forecast accuracy. Finally, a good answer would include a feedback loop to refine models based on actual usage.

10. Q10

    How would you handle an alert storm during a live incident?

    Incident ManagementMeta-specific

    Context: Production scenario: A monitoring bug pages every on-call rotation for symptoms related to cache-heavy multi-region architecture, obscuring the real issue.

    How to answer: A strong candidate would first emphasize the need to establish a communication channel and acknowledge the alert storm. The immediate next step is to identify the root cause or a primary indicator, often by looking for a 'parent' alert or a commonality among the alerts. They would then prioritize silencing or aggregating redundant alerts to reduce noise and allow the team to focus. Finally, they would discuss post-incident actions to prevent future alert storms, such as improving alert correlation, thresholds, or suppression rules.

11. Q11

    How would you make and document a change decision during an incident?

    Incident ManagementMeta-specific

    Context: Production scenario: social feed ranking and fanout service is degraded during a company-wide deploy freeze, but mitigation may require a risky config change.

    How to answer: During an incident, any change decision must prioritize incident resolution and stability. This involves assessing the change's potential impact (positive or negative) on the incident, ensuring it's a well-understood, low-risk, and ideally reversible fix or diagnostic. Documentation should be immediate and concise within the incident management tool (e.g., Slack channel, internal runbook), capturing the 'what,' 'why,' 'who,' and 'when' of the change, along with any observed effects. Post-incident, a more formal update to relevant change management systems or runbooks is necessary.

12. Q12

    When and how should an SRE escalate during an incident?

    Incident ManagementMeta-specific

    Context: Production scenario: The on-call engineer for social feed ranking and fanout service cannot identify root cause after 30 minutes, and impact is growing.

    How to answer: SREs should escalate when an incident's severity or scope exceeds their team's immediate capacity or expertise, when progress towards resolution stalls, or when business impact becomes critical. Escalation methods include using established on-call rotations and paging systems for technical experts, communicating clearly defined impact and actions to management, and leveraging internal incident management tools for broader awareness. Key information to convey includes current status, observed symptoms, business impact, actions taken so far, and specific resources or expertise needed. The goal is to bring in the right people at the right time to accelerate resolution and minimize impact.

13. Q13

    How would you coordinate an incident that may be both reliability and security related?

    Incident ManagementMeta-specific

    Context: Production scenario: A traffic surge against points of presence serving mobile and web clients might be abusive, but it also resembles a product launch spike.

    How to answer: A strong answer would emphasize early identification and immediate engagement of both SRE and Security teams. It would detail establishing a unified incident commander (potentially from SRE due to initial reliability impact) and a shared communication channel. The candidate should discuss parallel workstreams for reliability restoration and security investigation, ensuring data preservation and coordinated remediation. Finally, it's crucial to mention a joint post-mortem to capture lessons learned from both perspectives.

14. Q14

    How do you make good incident decisions under uncertainty?

    Incident ManagementMeta-specific

    Context: Production scenario: error-budget burn, cache hit rate, queue lag, and p99 latency point to multiple plausible causes, and every mitigation has downside risk.

    How to answer: A strong candidate would emphasize structured approaches like the OODA Loop (Observe, Orient, Decide, Act) or similar frameworks to navigate uncertainty. Key steps include rapidly gathering available information, prioritizing safety and service restoration, and making reversible decisions where possible. They should discuss leveraging expertise from others, escalating appropriately, and maintaining clear communication channels even when information is incomplete. Finally, they would highlight the importance of post-incident review to learn from decisions made under pressure.

15. Q15

    What does a good incident handoff include?

    Incident ManagementMeta-specific

    Context: Production scenario: A severe social feed ranking and fanout service incident spans multiple on-call shifts across time zones.

    How to answer: A good incident handoff should provide a clear, concise summary of the incident's current state, including its impact, affected systems, and a timeline of actions taken so far. It must detail the current mitigation strategies in place, any ongoing investigations, and critical next steps or outstanding tasks. Key information like the incident commander, communication channels, and relevant documentation (e.g., runbooks, dashboards) should be explicitly shared to ensure continuity and minimize context switching for the incoming team.

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