Meta Site Reliability Engineer (Mid-Level) Interview Preparation Guide
While search results confirm that Meta conducts Site Reliability Engineer interviews, comprehensive details about Meta's official interview process structure, specific round sequence, and evaluation criteria were not available in the provided search results. This guide is based on industry-standard SRE interview practices at major tech companies and common interview patterns documented in community discussions. For the most current and accurate information, candidates are advised to consult Meta's official careers page, recent discussions on Levels.fyi and Blind, and feedback from recent interviewees.
Meta's Site Reliability Engineer interview process for mid-level candidates (2-5 years of experience) follows a comprehensive multi-stage evaluation designed to assess technical depth, systems thinking, operational knowledge, and cultural fit. The process combines initial recruiter engagement, technical phone screens evaluating coding and systems expertise, and intensive onsite interviews covering system design, advanced troubleshooting, coding problem-solving, and behavioral competencies. At mid-level, Meta evaluates your ability to own complex projects end-to-end, mentor junior colleagues, drive reliability improvements, and collaborate effectively across teams.
Interview Rounds
Recruiter Screening
What to Expect
Initial combined recruiter call covering both preliminary assessment and deeper background exploration. The recruiter reviews your resume, understands your career path, and assesses alignment with Meta's SRE role and team needs. They'll discuss your experience with system reliability, incident response, automation, and operational work. This is your opportunity to demonstrate genuine interest in Meta, understanding of the role's responsibilities, and enthusiasm for contributing to their infrastructure. The recruiter will also discuss logistics, compensation expectations, and answer initial questions about the team and role.
Tips & Advice
Research Meta's engineering culture, infrastructure scale (billions of users, global presence), and reliability challenges before the call. Prepare concise stories about your most impactful reliability projects—focus on business impact and what you learned. Articulate specifically why you're interested in Meta (beyond just the brand) and what attracted you to the SRE role. Be genuine and conversational; recruiters evaluate cultural fit and whether you'll thrive in Meta's environment. Ask thoughtful questions about the specific team, on-call rotation structure, incident response culture, and what success looks like in the role. Have your resume easily accessible and be ready to discuss specific technical decisions, challenges overcome, and metrics demonstrating your impact. If asked about salary expectations or current compensation, research market rates beforehand.
Focus Topics
Collaboration and cross-team communication
Provide examples of how you've worked effectively with product teams, backend/infrastructure teams, security teams, or other stakeholders. Discuss how you communicate about reliability tradeoffs, advocate for reliability investments, and handle situations where reliability and feature velocity conflict. Show that you're easy to work with and good at building relationships.
Practice Interview
Study Questions
Technical depth and relevant tool experience
Summarize your technical expertise: programming languages you're proficient in, monitoring and observability tools (Prometheus, Grafana, ELK, Datadog, etc.), container orchestration experience (Kubernetes, Docker), cloud platforms (AWS, GCP, Azure), automation frameworks, and incident response tooling. Be honest about your depth in each area—where are you expert, where are you competent, where are you still developing skills?
Practice Interview
Study Questions
Career motivation and Meta-specific interest
Articulate why you're interested in an SRE role and specifically why Meta attracts you. Demonstrate knowledge of Meta's scale (billions of users globally), technical challenges (maintaining reliability at scale, handling diverse platforms), and engineering culture. Connect your experience and goals to Meta's needs around building resilient, performant systems. Show you've thought about this opportunity seriously.
Practice Interview
Study Questions
Experience with incident response and on-call responsibilities
Prepare specific examples of incidents you've responded to: what failed, your role in diagnosis and resolution, timeline, and what you learned. Discuss your comfort with on-call rotations, pager duties, and emergency response. Explain your philosophy on balancing reactive incident response with proactive reliability improvements. Show that you understand on-call is challenging but essential to SRE work.
Practice Interview
Study Questions
Systems reliability improvements and measurable impact
Share 2-3 concrete examples of systems or services where you meaningfully improved reliability. For each, describe: the problem or gap you identified, your approach to solving it, what you implemented, and quantifiable results (e.g., reduced mean time to recovery by 60%, eliminated manual restarts, improved uptime from 99.5% to 99.95%, reduced on-call pages by 70%). This demonstrates your ability to deliver impact.
Practice Interview
Study Questions
Technical Phone Screen - Coding and Algorithms
What to Expect
First technical phone interview assessing your coding ability, algorithmic thinking, and problem-solving methodology. You'll work through one to two coding problems, typically at LeetCode medium difficulty or slightly harder, in a collaborative coding environment (Google Docs, CoderPad, or similar). Problems may include graph traversal, dynamic programming, data structure design, or optimization challenges. The interviewer evaluates your approach to problem-solving, code quality, ability to identify and handle edge cases, and capacity to optimize solutions. Communication and thinking aloud are as important as arriving at the correct answer.
Tips & Advice
Start by clarifying problem requirements and constraints before coding. State your assumptions and confirm them with the interviewer—this demonstrates systematic thinking. For each problem, briefly outline your approach and complexity analysis before writing code. Write clean, readable code with meaningful variable names and consistent indentation. Test your solution against provided examples and generate your own test cases, including edge cases (empty input, single element, large inputs, duplicates, boundary conditions). If you get stuck, explain your thinking and ask for hints rather than sitting silently. If you finish early, optimize your solution or discuss alternative approaches. For SRE-specific problems, expect scenarios around graph problems (network connectivity, dependency mapping), data structure design (metrics collection, time-windowed data), or practical problems around resource optimization. Be conversational; explain your reasoning as you code so the interviewer can follow your thought process and provide guidance if needed.
Focus Topics
Communication and collaboration during problem-solving
Verbalize your thinking as you solve problems. Explain your approach before coding. Ask clarifying questions. Accept feedback and adapt if the interviewer suggests an alternative direction. Show that you can work collaboratively and are open to learning from the interviewer.
Practice Interview
Study Questions
Edge case identification and thorough testing
Systematically think through edge cases: empty/null inputs, single elements, large inputs, duplicates, negative numbers, boundary conditions. Test your solution against these cases. This demonstrates that you think like a reliability engineer—you anticipate failure modes and guard against them.
Practice Interview
Study Questions
Time and space complexity analysis
Deeply understand Big O notation and be able to analyze your solution's complexity. Discuss time-space tradeoffs. When asked to optimize, identify the bottleneck and explain how your optimization improves complexity. Show that you make conscious decisions about complexity, not just write code that happens to work.
Practice Interview
Study Questions
Code quality and production-readiness
Write code that's clean, readable, and maintainable. Use descriptive variable names, add comments where clarity isn't obvious, handle error cases, and follow consistent conventions. Avoid hacky shortcuts that work but are fragile. Demonstrate that you think about edge cases and robustness, not just happy-path functionality. This reflects your engineering discipline.
Practice Interview
Study Questions
Algorithm design and problem-solving approach
Master ability to approach problems systematically: understand requirements, identify constraints, brainstorm approaches, evaluate tradeoffs, and implement efficiently. Practice LeetCode medium to hard problems focusing on graph traversal (BFS/DFS), dynamic programming, arrays, strings, trees, and sorting/searching. For SRE relevance, focus on problems that could appear in real systems (path finding, resource allocation, time-window queries).
Practice Interview
Study Questions
Technical Phone Screen - Systems and Operational Troubleshooting
What to Expect
Second technical phone interview focusing on systems knowledge, troubleshooting capabilities, and operational thinking. You'll face realistic scenarios where systems are experiencing problems—degraded latency, elevated error rates, resource exhaustion, connectivity issues, etc. Your task is to systematically diagnose the root cause and propose solutions. The interviewer evaluates your methodology, depth of systems knowledge, understanding of monitoring and observability, and ability to think through distributed system failure modes. This round directly assesses your core SRE competency: diagnosing and resolving production incidents.
Tips & Advice
Treat this like a real incident scenario. Start by clarifying symptoms, timeline, scope (which users/regions affected), and what monitoring/logs are available. Ask about recent changes, deployment history, traffic patterns, or dependency failures that might correlate. Propose a systematic troubleshooting approach: gather information, form hypotheses, test hypotheses, eliminate possibilities. Think out loud so the interviewer follows your reasoning. Be comfortable with Linux command-line tools and ask about tools you'd use to diagnose problems. Understand basic networking (DNS, routing, ports, connections) and how to debug connectivity issues. Discuss what metrics and logs would help you diagnose the problem. For distributed systems, consider failure modes at each layer: application, middleware, infrastructure, network. Show deep practical knowledge, not just theoretical understanding. If you don't know something, admit it and explain how you'd find the answer.
Focus Topics
Distributed system failure modes and resilience
Understand common failure patterns at scale: cascading failures, thundering herd, network partitions, resource exhaustion, retry storms, dependency failures. Discuss how systems can defend against these: circuit breakers, backpressure, graceful degradation, bulkheads. Think through how systems recover from partial outages. Understand eventual consistency and its implications.
Practice Interview
Study Questions
Systematic incident diagnosis and root cause analysis
Master a structured troubleshooting methodology: (1) understand symptoms and timeline, (2) gather system state and metrics, (3) form hypotheses about root cause, (4) test hypotheses systematically, (5) identify true root cause, (6) implement solutions. Practice diagnosing realistic scenarios: latency spikes, error rate increases, resource exhaustion, cascading failures. Think through what information you'd need at each step.
Practice Interview
Study Questions
Networking concepts and connectivity troubleshooting
Understand DNS resolution, routing, TCP/IP fundamentals, ports, connections, firewalls, and load balancing. Troubleshoot connectivity issues using tools like ping, traceroute, telnet, nc, netstat, ss, ifconfig, ip, dig, nslookup, and tcpdump. Diagnose DNS failures, routing problems, port conflicts, and connection timeouts. Understand common network failure modes in distributed systems.
Practice Interview
Study Questions
Monitoring interpretation and observability thinking
Understand what to monitor (SLIs like latency percentiles, error rate, throughput), how to interpret dashboards and metrics, and what signals indicate problems. Discuss alert design and how to avoid alert fatigue. Think about how to instrument systems for observability: what metrics, logs, and traces would help diagnose this problem? Understand correlation between metrics to identify root causes.
Practice Interview
Study Questions
Linux systems and command-line diagnostics
Demonstrate deep proficiency with Linux systems: process management (ps, top, kill, pgrep), memory analysis (free, vmstat, ps), CPU analysis (top, mpstat, iostat), disk I/O (iostat, iotop, df, du), file systems, permissions, system calls (strace), and system logs (/var/log). Understand how to identify bottlenecks and interpret performance metrics. Be comfortable navigating systems and gathering diagnostic information efficiently.
Practice Interview
Study Questions
Onsite Interview - System Design (Non-Abstract Large System Design)
What to Expect
Comprehensive system design interview emphasizing Non-Abstract Large System Design (NALSD)—designing systems that must actually work in production with operational realism. Unlike traditional system design focusing primarily on functional requirements and scalability, this round emphasizes operational concerns fundamental to SRE work: reliability and failure handling, deployment strategies, monitoring and alerting architecture, capacity planning, incident response procedures, and cost optimization. You'll design a complex system handling real-world constraints and prove you understand how to operate it. The interviewer expects you to incorporate observability, resilience, and operational simplicity into your design from the ground up.
Tips & Advice
Begin by clarifying requirements and constraints: QPS (queries per second), latency requirements, data volume, geographic distribution, consistency needs, availability targets (SLO/SLA), and cost constraints. Explicitly state assumptions and verify them with the interviewer. Design for failure from the start—discuss failure modes at each layer and how your system detects and recovers. Include monitoring and alerting in your design from the beginning, not as an afterthought. What metrics indicate health? What should trigger alerts? How will engineers understand what's happening? Discuss capacity planning: how will you predict resource needs and handle growth? Explain deployment strategies: canary deployments, gradual rollouts, rollback procedures, zero-downtime updates. For a mid-level SRE, operational concerns are as important as functional design. Draw clear diagrams showing architecture, data flow, and failure isolation. Discuss tradeoffs explicitly: strong vs. eventual consistency, synchronous vs. asynchronous, batch vs. real-time, centralized vs. distributed. Explain why you made specific architectural choices and what alternatives you considered. Be prepared to defend your choices and discuss different scenarios. Consider cost implications—at Meta's scale, small inefficiencies become huge costs.
Focus Topics
Capacity planning, resource optimization, and growth handling
Estimate resource requirements based on scale requirements. How will you predict future capacity needs and plan for growth? Consider headroom and overprovisioning strategies. Discuss cost implications of your architectural choices. If appropriate, discuss auto-scaling: how does it work, what are its benefits and limitations? How do you test capacity planning before hitting limits in production?
Practice Interview
Study Questions
Architecture tradeoff analysis and decision-making
Explicitly discuss tradeoffs in your design: strong consistency vs. eventual consistency, synchronous vs. asynchronous communication, batch processing vs. real-time, centralized vs. distributed systems. Explain how you'd decide which approach fits the requirements. Discuss technology choices and their operational implications. Show that you can reason about architectural decisions and understand their downstream effects.
Practice Interview
Study Questions
Monitoring, observability, and alerting architecture
Incorporate observability into your design from the start. Define Service Level Indicators (SLIs) aligned with user-facing outcomes (e.g., successful requests, latency percentiles). Propose how you'd instrument the system: what metrics at each layer? What logs are important? How would you trace requests through the system? Design your alerting: what signals indicate problems? How do you avoid alert fatigue? How would you run post-mortems after incidents? Explain how an on-call engineer would understand and diagnose problems.
Practice Interview
Study Questions
Operational simplicity and deployment procedures
Design systems that are operationally maintainable and don't require heroic manual effort. Discuss how to deploy updates safely: blue-green deployments, canary deployments, rolling deployments. How do you roll back if deployment fails? How do you handle zero-downtime updates? What operational tasks are manual vs. automated? What could go wrong during deployment? How is the system operationally different from the design diagram—what challenges emerge in practice?
Practice Interview
Study Questions
Designing for reliability and failure resilience
Incorporate redundancy, fault isolation, and graceful degradation throughout your design. For each component, discuss failure modes: what happens if it fails? Design detection mechanisms (health checks, timeouts, error rates). Design recovery strategies (retries with backoff, circuit breakers, bulkheads, failover). Discuss both single-region and multi-region architectures. Think about cascading failure prevention and how to limit blast radius of failures.
Practice Interview
Study Questions
Onsite Interview - Coding and Algorithms
What to Expect
Technical coding interview conducted during the onsite day, assessing your problem-solving ability, code quality, and technical thinking under interview pressure. You'll work through one to two coding problems, typically at LeetCode medium-hard difficulty, potentially with more depth or complexity than the phone screen. Problems may include algorithm optimization, data structure design, or practical scenarios relevant to systems work. The interviewer evaluates your problem-solving approach, code quality, ability to optimize and improve solutions, and communication during problem-solving. This round validates that your coding ability holds up under onsite interview conditions.
Tips & Advice
This round is similar in structure to the phone screen coding round but may involve slightly more complex problems or require deeper optimization. Be thorough and methodical. Start by fully understanding the problem before writing code. Think out loud so your interviewer can follow your reasoning and potentially offer guidance. Write clean code with good naming conventions and proper structure. Test your solution comprehensively with various test cases including edge cases. If you finish early or solve quickly, ask if the interviewer would like you to optimize further or solve additional problems. Stay calm and engaged if you get stuck—explain your thinking and work through the problem with the interviewer. Remember that your problem-solving process and communication are evaluated as much as your final solution. For SRE-specific problems, expect practical scenarios: optimizing data structures for high-throughput metrics collection, solving graph problems related to network topologies or dependency mapping, designing efficient algorithms for log processing or event correlation.
Focus Topics
Code quality, structure, and maintainability
Write production-quality code: proper error handling, edge case management, clear structure, and good naming. Code should be readable and maintainable, not clever. Add comments where helpful. Be able to trace through your code mentally and explain what it does. If the interviewer points out bugs, identify and fix them gracefully.
Practice Interview
Study Questions
Problem-solving communication and collaboration
Verbalize your thinking as you work. Explain your approach before coding. Discuss tradeoffs as you consider different solutions. Accept feedback and adapt if the interviewer suggests an alternative direction. Show intellectual humility by acknowledging uncertainty and openness to learning.
Practice Interview
Study Questions
Time and space complexity analysis and optimization
Deeply understand Big O notation and analyze your solution's complexity. Identify performance bottlenecks and understand how to optimize them. Discuss time-space tradeoffs and make conscious decisions about these tradeoffs. When asked to optimize, explain how your optimization improves complexity and what the new tradeoffs are. Show that you make deliberate decisions, not just write code that 'works.'
Practice Interview
Study Questions
Algorithm design for systems-relevant problems
Master algorithms commonly relevant to systems and SRE work: graph algorithms (BFS/DFS for dependency analysis and network routing), sorting and searching, dynamic programming for optimization, data structure design (e.g., designing efficient data structures for time-windowed metrics or event streams). Practice LeetCode medium to hard problems. Focus on problems that could realistically apply to SRE scenarios.
Practice Interview
Study Questions
Onsite Interview - Troubleshooting and Systems Deep Dive
What to Expect
Technical interview focusing on systems troubleshooting, operational knowledge, and your ability to handle production incidents under pressure. You'll face realistic scenarios where systems are degraded or failing (latency spikes, elevated error rates, resource exhaustion, cascading failures, etc.), and you need to diagnose root causes and propose solutions. This round is a direct assessment of your core SRE competency: handling production incidents. The interviewer evaluates how you ask questions, gather information, formulate hypotheses, eliminate possibilities systematically, identify root causes, and design solutions. This is where theory meets practice.
Tips & Advice
Treat this like a real incident scenario. Ask clarifying questions first: what symptoms are observed? When did it start? What's the scope (users, regions, services affected)? What changed recently? Gather information systematically: what do monitoring dashboards show? What do logs reveal? What resources are constrained? Work through hypotheses methodically—form a hypothesis, explain how you'd test it, and discuss what results would confirm or refute it. Show deep knowledge of Linux systems, networking, and operational concepts. Discuss what tools and information you'd use to diagnose problems. For a mid-level SRE, interviewers expect confidence and practical knowledge grounded in real experience. Acknowledge uncertainties honestly, but show your thought process for finding answers. Walk through your troubleshooting process so the interviewer can follow and potentially guide you toward the root cause if you're stuck.
Focus Topics
Root cause analysis and systematic improvement
Distinguish between symptoms and root causes. Think about why the problem occurred at a fundamental level. Discuss systemic improvements to prevent recurrence. Explain how you'd design systems to be more robust against similar failures. Show that you think about long-term reliability improvement, not just firefighting.
Practice Interview
Study Questions
Monitoring data interpretation and alerting
Read and interpret monitoring dashboards and metrics effectively. Understand what different metrics indicate about system health. Discuss what information you'd collect and how you'd correlate it to identify root causes. Discuss alert design: what should trigger alerts? How do you avoid false positives? How would you set up monitoring to catch this type of problem in the future?
Practice Interview
Study Questions
Network troubleshooting and connectivity diagnosis
Diagnose network problems: DNS failures, routing issues, connectivity problems, port conflicts, firewall blocks, and connection timeouts. Master tools: ping, traceroute, dig, nslookup, telnet, nc, netstat, ss, tcpdump. Understand TCP/IP basics, DNS resolution process, and common network failure modes in distributed systems.
Practice Interview
Study Questions
Linux systems and performance diagnostics
Deep proficiency with Linux systems: process management, file systems, permissions, system calls, memory management, and CPU scheduling. Master diagnostic tools: top, ps, iostat, vmstat, netstat, ss, strace, tcpdump, and others. Understand how to identify resource bottlenecks (CPU, memory, disk I/O, network). Be able to interpret system behavior from monitoring data.
Practice Interview
Study Questions
Production incident diagnosis and response
Master the incident response mindset and methodology: understand the timeline and scope, gather system data systematically, formulate hypotheses about root cause, test hypotheses methodically, identify the true root cause, propose and implement solutions. Practice diagnosing realistic scenarios: latency spikes, error rate increases, resource exhaustion, memory leaks, dependency failures, cascading failures. Discuss how you'd communicate during an incident and what information you'd track.
Practice Interview
Study Questions
Onsite Interview - Behavioral and Leadership
What to Expect
Behavioral and culture-fit interview assessing your values, collaboration style, leadership potential, and how you handle challenges. For a mid-level SRE, interviewers specifically evaluate: your ability to own projects end-to-end (not just execute tasks), mentoring and developing junior colleagues, collaboration across team boundaries, incident leadership and decision-making under pressure, learning from failures and continuous improvement, and alignment with Meta's engineering culture and values. You'll be asked about past experiences, decision-making processes, conflict resolution, and your philosophy on reliability.
Tips & Advice
Prepare 4-5 strong STAR-format stories (Situation-Task-Action-Result) demonstrating key mid-level competencies: (1) owning a project end-to-end, from conception to production, (2) mentoring or helping junior colleagues grow, (3) leading or significantly contributing to incident resolution, (4) driving process improvements or efficiency gains, (5) learning from failure and improving. At mid-level, emphasize ownership and impact—this differentiates you from junior level. Be specific with metrics when possible (e.g., reduced on-call load by 70%, mentored 3 junior engineers, improved deployment frequency from weekly to daily). Discuss your philosophy: how do you balance reliability and velocity? When do you invest in reliability vs. shipping features? Discuss your approach to on-call work and incident response culture. Show that you value learning, continuous improvement, and psychological safety for the team. Prepare thoughtful questions about the team's challenges, how SREs are valued, growth opportunities, and the incident response culture. Be authentic—share genuine challenges you've faced and what you learned. If asked about failures, discuss honestly what went wrong, what you learned, and how you improved. Meta values intellectual humility and honesty about challenges.
Focus Topics
Learning from failure and growth mindset
Discuss a significant failure, mistake, or setback you experienced. Be honest and vulnerable about what went wrong. Explain what you learned and how you improved as a result. Show that you view failures as learning opportunities, not sources of shame. Demonstrate resilience and commitment to continuous improvement.
Practice Interview
Study Questions
Cross-functional collaboration and influence without authority
Share examples of working effectively with product teams, infrastructure teams, and other stakeholders. Discuss how you advocate for reliability improvements and communicate about tradeoffs. Show your ability to influence others' decisions and build consensus around your ideas without having direct authority over them.
Practice Interview
Study Questions
Incident leadership and decision-making under pressure
Discuss your role in major incidents: did you lead incident response, contribute significantly to diagnosis, make critical decisions? Explain your approach: how do you stay calm under pressure? How do you communicate with stakeholders? What information drives your decisions? Discuss your philosophy on blameless post-mortems and learning from failures. Share examples of incidents where you drove resolution or subsequent improvements.
Practice Interview
Study Questions
Project ownership and end-to-end impact
Describe projects you've owned from conception through production and maintenance. Share what problems you identified, your approach to solving them, implementation challenges you overcame, and measurable impact (improved reliability, reduced toil, faster response time, etc.). Demonstrate your ability to drive initiatives independently, make decisions, and see projects through to completion. Show that you don't just execute tasks but own outcomes.
Practice Interview
Study Questions
Mentoring and developing junior team members
Share examples of how you've helped junior engineers or colleagues grow: code reviews, pairing sessions, teaching them new tools or concepts, guiding them through complex problems. Discuss your philosophy on mentoring. Show that you're invested in developing others and creating a learning culture. Describe the impact: how did they improve?
Practice Interview
Study Questions
Frequently Asked Site Reliability Engineer (SRE) Interview Questions
Sample Answer
Sample Answer
Sample Answer
import time
import threading
from enum import Enum
class State(Enum):
CLOSED = 1
OPEN = 2
HALF_OPEN = 3
class CircuitBreaker:
def __init__(self, window_seconds=60, buckets=6, failure_threshold=0.5,
min_requests=20, open_duration=30):
self.window = window_seconds
self.buckets = buckets
self.bucket_size = window_seconds // buckets
self.failure_threshold = failure_threshold
self.min_requests = min_requests
self.open_duration = open_duration
# buckets: list of (start_ts, requests, failures)
now = int(time.time())
self._buckets = [(now - i*self.bucket_size, 0, 0) for i in range(buckets)][::-1]
self._lock = threading.Lock()
self.state = State.CLOSED
self.open_until = 0
self.half_open_trial_in_flight = False
def _current_bucket_index(self):
return int(time.time()) // self.bucket_size % self.buckets
def _rotate_and_get_buckets(self):
# Ensure buckets represent last window; called under lock
now = int(time.time())
for i in range(self.buckets):
start, reqs, fails = self._buckets[i]
if now - start >= self.window:
# stale bucket -> reset to current aligned window slice
aligned_start = now - ((self.buckets - 1 - i) * self.bucket_size)
self._buckets[i] = (aligned_start, 0, 0)
return self._buckets
def _aggregate(self):
# sum requests and failures over buckets; called under lock
total_reqs = sum(b[1] for b in self._buckets)
total_fails = sum(b[2] for b in self._buckets)
return total_reqs, total_fails
def allow_request(self):
"""Return True if caller may proceed (trial allowed), False to short-circuit."""
with self._lock:
now = time.time()
if self.state == State.OPEN:
if now >= self.open_until:
self.state = State.HALF_OPEN
self.half_open_trial_in_flight = False
else:
return False
if self.state == State.HALF_OPEN:
if not self.half_open_trial_in_flight:
# allow single trial
self.half_open_trial_in_flight = True
return True
else:
return False
# CLOSED
return True
def _increment_bucket(self, success: bool):
idx = self._current_bucket_index()
start, reqs, fails = self._buckets[idx]
aligned_start = int(time.time()) - (int(time.time()) % self.bucket_size)
if start != aligned_start:
# reset this bucket to current slice
self._buckets[idx] = (aligned_start, 0, 0)
start, reqs, fails = self._buckets[idx]
reqs += 1
if not success:
fails += 1
self._buckets[idx] = (start, reqs, fails)
def record_success(self):
with self._lock:
# record
self._rotate_and_get_buckets()
self._increment_bucket(success=True)
if self.state == State.HALF_OPEN:
# success on trial -> close and reset
self.state = State.CLOSED
self.half_open_trial_in_flight = False
# reset buckets
now = int(time.time())
self._buckets = [(now - i*self.bucket_size, 0, 0) for i in range(self.buckets)][::-1]
def record_failure(self):
with self._lock:
self._rotate_and_get_buckets()
self._increment_bucket(success=False)
total_reqs, total_fails = self._aggregate()
# if trial failed in half-open -> reopen
if self.state == State.HALF_OPEN:
self.state = State.OPEN
self.open_until = time.time() + self.open_duration
self.half_open_trial_in_flight = False
return
if total_reqs >= self.min_requests:
if total_fails / total_reqs > self.failure_threshold:
self.state = State.OPEN
self.open_until = time.time() + self.open_durationSample Answer
Sample Answer
Sample Answer
Sample Answer
# python
import subprocess, sys, time
def rollout_watch(ns, deploy, timeout=300):
start=time.time()
while time.time()-start < timeout:
s=subprocess.run(["kubectl","rollout","status","deploy/"+deploy,"-n",ns], capture_output=True, text=True)
out=s.stdout+s.stderr
if "successfully rolled out" in out:
print("Rolled out")
return True
if "progress deadline exceeded" in out:
subprocess.run(["kubectl","rollout","undo","deploy/"+deploy,"-n",ns])
print("Rolled back")
return False
time.sleep(5)
subprocess.run(["kubectl","rollout","undo","deploy/"+deploy,"-n",ns])
print("Timed out -> rolled back")
return FalseSample Answer
Sample Answer
Sample Answer
Recommended Additional Resources
- LeetCode (focus on medium to hard problems, especially graph traversal, dynamic programming, and data structure design)
- Designing Data-Intensive Applications by Martin Kleppmann (essential for understanding distributed systems)
- The Site Reliability Engineering Workbook by Google (covers SRE fundamentals and practices)
- Systems Design Interview by Alex Xu and Shuyi Liao (practical system design patterns)
- TCP/IP Illustrated Vol. 1 by W. Richard Stevens (comprehensive networking reference)
- Understanding the Linux Kernel by Daniel P. Bovet and Marco Cesati (deep Linux knowledge)
- Levels.fyi (compensation, interview experiences, company insights)
- Blind (anonymous employee feedback and interview discussions)
- Meta Engineering Blog and Infrastructure posts (understand Meta's tech stack and challenges)
- Practice mock interviews on Pramp or Interviewing.io with experienced interviewers
- Linux man pages and documentation (master command-line tools)
- Incident postmortem templates and blameless culture resources
- Production Readiness Checklist (research and understand what operational readiness means)
Search Results
Google Site Reliability Engineer (SRE) Interview (questions, process ...
You should expect questions around networking concepts, such as connectivity checks, DNS resolution, port conflicts, and routing. Example Google ...
50 Site Reliability Engineer (SRE) Interview Questions 2025
Most asked Site Reliability Engineering (SRE) interview questions · Q1. Differentiate between DevOps and SRE. · Q2. Why do you want to do a job in ...
Site Reliability Engineering Interview Questions - MentorCruise
Study Mode · 1. How do you deal with on-call emergency issues · 2. Which programming languages are you most comfortable working with? · 3. What steps would you ...
Top 25 SRE Interview Questions and Answers for 2025 - YouTube
Want to crack your SRE (Site Reliability Engineer) interview fast? This video covers the most commonly asked SRE interview questions and ...
Meta Site Reliability Engineer Interview Questions - NodeFlair
Utilizing advanced AI, our tool generates tailored interview questions based on your industry, role, and experience. Practice and receive feedback on your ...
Site Reliability Engineer (SRE) Interview Preparation Guide - GitHub
A collection of questions to practice with for SRE interviews · SRE Interview Questions · Sysadmin Test Questions · Kubernetes job interview questions · DevOps ...
Meta (Facebook) Site Reliability Engineer Interview Questions
Review this list of Meta (Facebook) site reliability engineer interview questions and answers verified by hiring managers and candidates.
This interview preparation guide was generated using AI-powered research from the sources listed above. While we strive for accuracy, we recommend verifying critical information from official company sources.
Want to create your own tailored preparation guide using our deep research?
Get Started for FreeInterview-Ready Courses
Visual-first, interactive, structured learning paths
Browse Site Reliability Engineer (SRE) jobs
AI-enriched listings across hundreds of company career pages
Explore Jobs