Meta Site Reliability Engineer (Senior Level) Interview Preparation Guide

Site Reliability Engineer (SRE)

Interview Rounds

Recruiter Screening

30 min3 focus topicsculture fit

What to Expect

Initial conversation with a Meta recruiter to discuss your background, career motivation, and alignment with the Senior SRE role. The recruiter will verify your understanding of SRE responsibilities, discuss compensation and equity expectations, confirm availability, and schedule subsequent technical interviews. This is also an opportunity to assess your communication skills and genuine interest in Meta's engineering challenges.

Tips & Advice

Prepare a concise 2-3 minute summary of your SRE career, highlighting scale of systems you've managed and key achievements. Research Meta's infrastructure and mention specific aspects that interest you. Be honest about your experience level and career goals. Ask meaningful questions about the team, projects, and growth opportunities. Show enthusiasm for solving reliability problems at massive scale. Have your calendar and availability ready for flexible scheduling.

Focus Topics

Motivation for Senior SRE Role

Articulate why you're attracted to SRE work specifically, what motivates you about building reliable systems, and why you're seeking a senior-level role at this point in your career. Connect your motivation to Meta's needs and culture.

Practice Interview

Study Questions

Meta-Specific Interest and Knowledge

Demonstrate research about Meta's infrastructure, engineering culture, and technical challenges. Reference Meta's public talks, engineering blogs, or known infrastructure at scale. Show specific interest in problems Meta solves rather than generic interest in 'big tech.'

Practice Interview

Study Questions

SRE Career Narrative

Develop a compelling narrative about your SRE journey. Highlight progression from junior responsibilities to senior-level work. Emphasize scale of systems managed, complexity of problems solved, and impact on reliability. For senior level, discuss how you've grown as a leader and mentor.

Practice Interview

Study Questions

Technical Phone Screen

60 min4 focus topicstechnical

What to Expect

Technical assessment conducted by a Meta engineer (typically an SRE or senior engineer) via video call. This round typically involves one or two coding problems to assess algorithmic thinking, problem-solving methodology, and code quality. Expect LeetCode-style medium to hard questions with emphasis on data structures and algorithms. You'll code in a shared collaborative editor while discussing your approach with the interviewer. The focus is on clear communication, systematic problem-solving, and writing clean, correct code.

Tips & Advice

Communicate your approach before writing code. Clarify problem requirements and constraints. Walk through your solution with examples. Discuss time and space complexity. For senior candidates, expect to optimize your initial solution and discuss scalability implications. Write production-quality code with proper variable naming and error handling. Test your code mentally. If stuck, think aloud and engage the interviewer in discussion. Demonstrate problem-solving process more than just arriving at the answer.

Focus Topics

Optimization and Scalability Thinking

After solving the basic problem, discuss optimizations and trade-offs. For senior candidates, automatically consider how solution scales and what improvements could make it more efficient. Discuss practical limits and how solution behaves under extreme conditions.

Practice Interview

Study Questions

Data Structures

Deep understanding of arrays, linked lists, trees, graphs, hash tables, heaps, queues, and stacks. Know when each data structure is appropriate, their performance characteristics, and how to implement them. Understand variants like balanced trees and graphs.

Practice Interview

Study Questions

Algorithms and Problem-Solving

Proficiency with common algorithms including sorting, searching, graph traversal (BFS, DFS), dynamic programming, and string manipulation. Ability to analyze problem structure, identify the right algorithmic approach, and implement clean solutions. Understanding of time and space complexity analysis.

Practice Interview

Study Questions

Code Quality and Communication

Write clean, readable code with meaningful variable names and proper structure. Communicate your thinking process throughout. Ask clarifying questions about requirements. Walk through examples to verify correctness. Handle edge cases explicitly. For senior candidates, discussion should include code maintainability and production considerations.

Practice Interview

Study Questions

Onsite Round 1: Coding and Algorithms

75 min4 focus topicstechnical

What to Expect

First onsite interview focused on advanced coding and algorithmic problem-solving. This round typically involves one or two complex coding problems, often with systems relevance (such as designing a rate limiter, cache, queue system, or handling concurrent access). You'll work on a laptop with access to any programming language and can compile/run code. The interview assesses algorithm design, code correctness, optimization thinking, and your ability to write robust, production-ready code with proper error handling and edge case consideration.

Tips & Advice

Start by asking clarifying questions about constraints and requirements. For systems-oriented problems, think about failure modes and edge cases from the start. Write code that handles errors gracefully. For senior candidates, demonstrate consideration of performance under load and how to test the code. Include logging and error handling as you would in production code. If problem involves concurrency or distributed aspects, discuss synchronization and race conditions. After getting a working solution, think about improvements and scalability.

Focus Topics

Code Testability and Verification

Write code that is testable. Discuss test strategy including unit tests and edge case coverage. Verify your implementation handles all important cases. For senior candidates, think about how code would be tested in production.

Practice Interview

Study Questions

Systems-Oriented Coding Problems

Solve complex coding problems with systems relevance such as rate limiting, caching with eviction policies, distributed queuing, concurrent access patterns, stream processing, or connection pooling. These problems are more realistic than pure algorithms and directly relevant to SRE automation work.

Practice Interview

Study Questions

Concurrency and Synchronization

Understanding of concurrent programming, race conditions, mutual exclusion, deadlocks, and synchronization primitives. Ability to write thread-safe code. Understanding of how to handle concurrent access to shared resources. For senior candidates, deep understanding of memory models and synchronization semantics.

Practice Interview

Study Questions

Error Handling and Robustness

Write code that handles edge cases, invalid inputs, and error conditions gracefully. Include proper exception handling and validation. Think about failure modes and how your code behaves under adverse conditions. For senior level, implement defensive programming practices.

Practice Interview

Study Questions

Onsite Round 2: System Design - Monitoring and Observability

75 min4 focus topicssystem design

What to Expect

This system design round focuses on designing core SRE infrastructure systems, specifically monitoring, observability, and alerting. You might be asked to design a metrics collection and alerting system, a log aggregation and search system, a distributed tracing system, or an anomaly detection system. The interviewer assesses your ability to architect systems for reliability, think about operational concerns, understand trade-offs, and design solutions that are actually operational at scale. Emphasize SLO/SLI concepts, preventing alert fatigue, and ensuring observability doesn't become a bottleneck.

Tips & Advice

Start by understanding requirements and constraints. Ask about scale, retention requirements, query patterns, and accuracy requirements. Draw clear architecture diagrams showing data flow and major components. Discuss trade-offs explicitly (e.g., accuracy vs. cost, completeness vs. latency). For senior candidates, demonstrate deep understanding of observability philosophy, SLI selection, SLO definition, and error budget implications. Discuss how to prevent alert fatigue while maintaining coverage. Think about operational challenges like scaling, maintenance, and troubleshooting the monitoring system itself.

Focus Topics

Distributed Systems Tracing and Debugging

Design system to trace requests through distributed systems. Understand distributed tracing architecture, span collection, storage, and visualization. Discuss how to debug latency and failures using trace data. Balance trace volume with cost.

Practice Interview

Study Questions

Alerting and Anomaly Detection

Design alerting system that detects significant problems while minimizing false positives. Understand threshold-based alerting, statistical anomaly detection, and complex rule evaluation. Discuss how to prevent alert fatigue and ensure high-priority alerts are noticed. Implement feedback mechanisms to tune alert quality.

Practice Interview

Study Questions

Metrics Collection and Time-Series Storage

Design system to collect, store, and query metrics at massive scale. Understand time-series database design, compression techniques, retention policies, and query patterns. Discuss different aggregation levels and retention strategies. Consider how to handle high-cardinality metrics and avoid storage explosion.

Practice Interview

Study Questions

SLI, SLO, and Error Budget Design

Understanding of Service Level Indicators (what to measure), Service Level Objectives (targets), and error budgets (how much unreliability is acceptable). Design monitoring that connects to SLOs. Discuss how error budgets guide decisions. Implement SLO tracking and budgeting.

Practice Interview

Study Questions

Onsite Round 3: System Design - Infrastructure and Deployment

75 min4 focus topicssystem design

What to Expect

Second system design round focused on designing complex infrastructure systems. You might design a deployment and release management system, service discovery system, configuration management system, load balancing infrastructure, or handling resilience at scale. Assess ability to design for reliability through architectural patterns, handling failure scenarios, gradual rollout strategies, and operational safety. For senior SREs, expect deep probing into operational implications, testing strategies, and how to validate system behavior.

Tips & Advice

Start with clear requirements and assumptions. Draw architecture with all components. Discuss data flow and failure scenarios explicitly. For senior candidates, dig deep into operational concerns: how would you debug issues? How do you test this system? What could go wrong? Design for observability and debuggability. Discuss trade-offs between speed and safety. Think about capacity planning and scaling. Be prepared to go deep into specific technical areas based on interviewer questions.

Focus Topics

Operational Validation and Testing Infrastructure

Design systems and processes to validate system behavior safely. Understand chaos engineering, load testing, failure injection, and staged rollout validation. Discuss how to test disaster recovery and failure scenarios without impacting production.

Practice Interview

Study Questions

Resilience Patterns and Graceful Degradation

Design systems that degrade gracefully under failure. Understand circuit breakers, bulkheads, fallback strategies, and cascading failure prevention. Design for operating in degraded mode and recovering when dependencies heal. Discuss trade-offs between availability and consistency.

Practice Interview

Study Questions

Service Discovery and Configuration Management

Design system for service discovery at scale. Understand consistency models, failure handling, and client-side caching. Design configuration management that handles updates across thousands of services without downtime. Discuss consistency guarantees and eventual consistency implications.

Practice Interview

Study Questions

Safe Deployment and Release Strategies

Design system for deploying software to production safely. Understand canary deployments, blue-green deployments, feature flags, gradual rollout strategies, and rapid rollback mechanisms. Design for minimizing blast radius of bad deployments. Discuss how to detect issues early during rollout.

Practice Interview

Study Questions

Onsite Round 4: Operational Troubleshooting

60 min4 focus topicstechnical

What to Expect

This round assesses ability to troubleshoot complex production issues systematically. You'll be presented with hypothetical production problems or scenarios where systems behave unexpectedly. Use systematic methodology to diagnose root cause by asking questions, gathering data, forming hypotheses, and testing them. Scenarios might involve performance degradation, connectivity issues, data inconsistencies, or cascading failures. Interviewers assess troubleshooting approach, depth of systems knowledge, ability to handle ambiguity, and communication clarity.

Tips & Advice

Use structured troubleshooting: clearly define the problem, establish baseline and what changed, gather data, form hypotheses, test them. Ask about symptoms, timeline, scope, and affected components. Draw diagrams of system components. Use knowledge of Linux, networking, databases, and infrastructure to narrow possibilities. For senior candidates, demonstrate sophisticated systems thinking across multiple layers. Consider infrastructure, OS, application, and dependencies. Communicate findings clearly. Discuss how you'd escalate and involve other teams.

Focus Topics

Database and Storage Troubleshooting

Common database issues: slow queries, connection pool exhaustion, lock contention, replication lag, data consistency problems. Ability to investigate query performance, check replication status, understand transaction behavior, and diagnose data issues. Knowledge of database-specific tools and metrics.

Practice Interview

Study Questions

Incident Diagnosis and Root Cause Methodology

Systematic approach to diagnosing incidents. Understand difference between symptom and root cause. Process for gathering data, forming hypotheses, and testing them. Understanding common categories of production issues: resource exhaustion, configuration errors, dependency failures, concurrency issues, and cascading failures.

Practice Interview

Study Questions

Networking Concepts and Troubleshooting

Understanding of OSI model, TCP/IP, DNS, routing, network interfaces, and packet flow. Ability to diagnose connectivity problems, DNS issues, port conflicts, packet loss, latency, and network-level failures. Knowledge of firewalls, NATs, load balancers, and their impact. Use tools like ping, traceroute, netstat, ss, tcpdump, and dig.

Practice Interview

Study Questions

Linux Systems and Performance Analysis

Deep understanding of Linux including process management, memory management, CPU scheduling, I/O subsystems, and kernel networking. Proficiency with tools: ps, top, htop, iostat, vmstat, netstat, ss, strace, ltrace, and perf. Understand performance metrics and how to identify bottlenecks. Knowledge of kernel parameters and tuning.

Practice Interview

Study Questions

Onsite Round 5: Behavioral and Leadership

45 min4 focus topicsbehavioral

What to Expect

Final onsite round assesses cultural fit with Meta and leadership capabilities at senior level. Interviewers explore your work history, decision-making approach, conflict resolution, collaboration style, and alignment with Meta's leadership principles including Move Fast, Be Direct, and Focus on Impact. For senior SRE candidates, expect questions about how you've influenced technical direction, mentored team members, driven reliability initiatives, and balanced competing priorities. Interviewers assess strategic thinking about systems reliability, ability to lead across boundaries, and communication effectiveness.

Tips & Advice

Prepare 5-7 concrete examples using STAR format (Situation, Task, Action, Result) that demonstrate impact at scale. For senior level, focus on examples showing leadership influence, mentorship, or driving significant reliability improvements. Discuss failures honestly and what you learned. Understand Meta's leadership principles and align your examples. Be genuine, direct, and specific. For SRE context, prepare examples of incidents handled well, building reliability culture, balancing reliability with velocity, and mentoring junior SREs. Be ready to discuss your approach to difficult conversations and how you handle disagreement about reliability vs. speed trade-offs.

Focus Topics

Cross-Functional Collaboration and Stakeholder Management

Working effectively with developers, product managers, and infrastructure teams. Examples of resolving conflicts between reliability and velocity goals. How you've communicated technical concerns to non-technical stakeholders. Experience influencing prioritization across organizational boundaries.

Practice Interview

Study Questions

Incident Response and Blameless Culture

How you've handled production incidents under pressure. Your approach to postmortems and psychological safety. Examples of building blameless incident culture. Systemic improvements implemented based on incidents. How you balance rapid response with thorough investigation and learning.

Practice Interview

Study Questions

Technical Leadership and Influence

Examples of influencing technical decisions without direct authority. Leading reliability initiatives or architectural improvements. Experience driving adoption of new tools, practices, or approaches. How you've influenced teams to prioritize reliability. Examples of mentoring junior SREs or engineers.

Practice Interview

Study Questions

SLO and Error Budget Thinking

Deep understanding of SLOs, SLIs, SLAs, and error budgets. Ability to explain how error budgets guide trade-off decisions between reliability and feature development. Examples of how you've communicated trade-offs between innovation and stability. Experience using error budgets to influence prioritization decisions.

Practice Interview

Study Questions

Frequently Asked Site Reliability Engineer (SRE) Interview Questions

Incident Leadership and PostmortemsMediumTechnical

27 practiced

You are responsible for customer-facing incident status pages. Create a short template for a status update that balances transparency and legal/PR risk, and explain why each section (impact, mitigation in progress, next update) is included and where to avoid speculation.

Networking Fundamentals and TroubleshootingMediumSystem Design

30 practiced

Compare L4 (transport) and L7 (application) load balancing. For HTTP API traffic at scale, when would you choose L4 vs L7? Discuss what metrics and failure modes are visible at each layer, and tradeoffs related to performance, visibility, sticky sessions, and header-based routing.

Sample Answer

Requirements and decision rule:- We’re balancing large-scale HTTP API traffic. Main tradeoffs: performance/latency, observability/control, routing features (cookies/headers), and session affinity.

L4 (transport - TCP/UDP) summary:- Operates on IP/TCP level (no HTTP parsing). Very high throughput, low latency and low CPU per connection.- Good when you need raw performance, TLS passthrough, or want a simple L3–L4 fleet behind NAT.- Visible metrics: TCP connection counts, accept/sec, bytes/sec, socket errors, TCP retransmits, TLS handshake failures (if terminated upstream), backend TCP health (connect success/failure).- Failure modes visible: connection exhaustion, SYN floods, backend port closed, degraded network MTU issues. Application errors (HTTP 5xx) are opaque.- Sticky sessions: possible via source-IP hashing or consistent hashing on 4-tuple, but unreliable for clients behind NAT/proxies.- Header-based routing: impossible.

L7 (application - HTTP) summary:- Terminates/parses HTTP(S), can inspect headers, URL, method, cookies, and do smart routing, retries, rate-limit, auth, and advanced health checks.- Visible metrics: request latency, per-route QPS, HTTP status codes, error rates, request/response sizes, header-based anomalies.- Failure modes visible: high 5xx rates, slow handlers, malformed requests, retry storms; plus L4-like connection issues if terminating TLS.- Sticky sessions: robust via cookies or application session tokens.- Header-based routing: full capability (A/B tests, canary by header, tenant routing).

When to choose which:- Choose L4 when maximum throughput and minimal latency matter, or when you need end-to-end TLS passthrough and the app handles routing/observability. Use for internal mesh east-west traffic or simple stateless APIs with client IP affinity.- Choose L7 for public HTTP APIs requiring routing, observability, per-route SLOs, authentication, WAF, retries, or traffic shaping. Use when you need per-endpoint metrics, adaptive retries, or header/cookie sticky sessions.

Operational recommendations:- Combine both: front L4 LB for high-performance TLS passthrough to edge gateways, then L7 proxies (ingress or API gateway) for routing and observability. Instrument both layers: collect L4 metrics (conn counts, accept latency) and L7 traces/metrics (p95/p99 latencies, per-route error rates). Implement health checks at both layers (TCP + HTTP 200/health), set circuit breakers, and monitor for cross-layer failure patterns (e.g., rising TCP retries + downstream 5xx => overloaded app).

Cross Functional Collaboration and CoordinationHardTechnical

43 practiced

Create a stakeholder mapping for a multi-quarter reliability program spanning networking, storage, and platform teams. Identify influencers, decision makers, and potential blockers, propose an executive sponsorship strategy, describe the cadence and content of exec-level updates, and explain how you would handle conflicting priorities across business units.

Sample Answer

Framework: I’ll use a RACI + influence/impact matrix across networking, storage, platform, dev teams, product/BU owners, security, ops, finance, and execs.

Stakeholder mapping (summary):- Executive sponsors (Decision Makers): VP Engineering, CTO — set funding, prioritize cross-BU programs.- Program Owner (Decision/Approve): Head of SRE — accountable for roadmap, SLOs, error budgets.- Influencers: Platform leads, Networking lead, Storage lead, Head of Product for major BUs — technical authority, shape scope.- Implementers (Responsible): SRE squads, NetEng, Storage Eng, Platform Infra teams.- Governance/Compliance: Security, Legal — can add constraints and approval gates.- Support/Users: Product teams, Customer Ops — consume outputs, provide requirements/alerts.- Potential blockers: Individual team capacity constraints, competing BU roadmaps, vendor contracts, legacy change control boards.

Executive sponsorship strategy:- Secure a single executive sponsor (VP Eng or CTO) and a co-sponsor in Product/Revenue to align reliability with business KPIs (revenue impact, uptime SLAs).- Charter with clear asks: budget, priority window, temporary resource reallocation, and authority to enforce cross-team timelines.- Tie program outcomes to business metrics (revenue-at-risk, MTTR reduction, reduction in SEV count) so execs can defend trade-offs.

Cadence & content for exec-level updates:- Monthly exec steering (30–45m) + weekly 1-page status email.- Status email structure: headline (red/amber/green), topline metric delta (availability, MTTR, error budget burn), 1-line blocker with owner and ask, progress vs milestones, near-term risks and mitigation, budget/variance.- Monthly meeting: 10m topline metrics + business impact, 15m milestone demos/decisions, 10m risk register & escalations, 5m actions and owner commitments. Include dashboards and one customer story.

Handling conflicting BU priorities:- Use a prioritization framework: business impact × technical/operational risk × cost/time to fix. Score proposed work and present to exec sponsor for arbitration.- Protect a portion of SRE capacity (~20%) as “reliability runway” for cross-cutting work; the rest is negotiable with BUs.- Negotiate trade-offs: offer phased deliverables, quick wins for high-impact low-effort, and defer lower-impact items.- If stalemate, escalate to exec sponsor with an impact analysis comparing outcomes of competing priorities.- Maintain transparency: publish roadmap, decisions, and rationale so BUs trust the process.

Governance & success measures:- Governance board (monthly) with leads + exec sponsor for approvals.- KPIs: availability by service, MTTR, number of SEVs, percentage of SLOs met, and business impact avoided. Use these to re-evaluate priorities each quarter.

Deployment and Release StrategiesHardTechnical

70 practiced

Design a plan to integrate chaos engineering into the release pipeline so that resilience tests run regularly without blocking releases unnecessarily. Include types of experiments, failure injection points, scheduling, and gating logic that informs but does not unduly delay deployments.

Sample Answer

Situation: We want resilience testing to run regularly as part of the release pipeline but not become a hard blocker that slows delivery. The plan below balances automated early feedback, controlled production experiments, observability, and gating logic tied to SLOs/error budgets.

High-level approach:- Shift-left chaos in CI and staging for fast feedback.- Progressive, low-blast-radius experiments in canary/production after deployment.- Automated experiment orchestration + strong observability + safety controls.- Gating decisions based on predefined health signals and error-budget thresholds.

Types of experiments (examples):- Infrastructure: instance termination, AZ failover, node CPU/IO pressure- Network: packet loss, latency, DNS failures, blackhole service-to-service paths- Platform: kube control-plane API throttling, pod eviction, scheduler latency- Application: latency injection (sleep), DB connection errors, saturating threadpools, rate limit misconfig- Dependency: downstream service timeouts, degraded cache (cache miss storm)- Security/Config: rotated certs, degraded auth service responses

Failure-injection points & tools:- CI/staging: unit/microservice-level fault injection via test harnesses and mocks- Kubernetes: chaos-operator (litmus, chaos-mesh) to evict pods, inject network faults- Service mesh: Istio fault injection to introduce latency or aborts per route- Cloud provider: API-based instance termination, network ACLs- Edge/load-balancer: simulate connection spikes, 5xx responses- DB layer: proxy (toxiproxy) to inject latency/errors

Scheduling and cadence:- CI: deterministic, test-suite-level fault scenarios on every PR (fast, <5m added)- Nightly staging: broader scenario matrix that runs full-system experiments (longer, 1–2 hours)- Canary: run targeted low-blast experiments automatically during canary window (first 5–10% traffic) for each deploy- Production: continuous small experiments (non-business hours or limited blast radius) and a weekly “blast day” run by SREs for wider scenarios- Business-hour policy: avoid high-risk test windows during peak traffic unless authorized

Blast-radius control:- Limit experiments to specific namespaces, node pools, AZs, or canary traffic buckets- Use percent-based traffic shaping (e.g., Istio subsets)- Run experiments with liveness/abort hooks and timeouts

Observability & instrumentation:- Required telemetry: latency p50/95/99, error rates, SLI/SLO dashboards, tracing spans, resource metrics (CPU, mem, I/O), synthetic user journeys- Per-experiment dashboard with baseline vs experiment curves, real-time anomaly detection- Correlate logs/traces with experiment IDs and tags

Gating logic (inform-but-not-unduly-block):- Stage-dependent policy: - CI & Staging: failures are blocking for PR merges if tests for that service fail. - Canary: automated rollback if canary health checks (error rate increase > X% absolute or SLO breach) hit thresholds within canary window. - Production (post-canary): experiments are non-blocking by default but generate high-priority alerts.- Error-budget-driven automation: - If service error budget remaining < Y% (e.g., 20%), automatically restrict production experiments and require explicit SRE/PM approval to run further tests. - If an experiment causes SLO breach beyond threshold for Z minutes, auto-abort experiment and trigger rollback/runbook.- Severity tiers: - Informational: minor degradations logged and emailed to owners. - Warning: sustained error increase → page on-call and create incident. - Critical: SLO violation or customer-visible impact → immediate rollback/traffic shift.- Human-in-the-loop: experiments that escalate beyond warning require on-call acknowledgement before continuing.

Safety & governance:- Kill-switch API to abort/cancel experiments instantly- RBAC/approval flow to schedule high-risk tests- Audit logs and experiment metadata stored for postmortems- Pre-approved runbooks for each experiment type with recovery steps and rollback playbooks

Metrics to evaluate practice:- Mean time to detection and recovery for injected failures- % of releases with canary anomalies- Number of experiments run per service per month- Correlation of experiments to reduced incident recurrence

Example workflow:1. Dev pushes PR → CI runs unit + lightweight chaos tests (simulated failures) → PR passes.2. Merge → staging nightly runs expanded chaos matrix; failures block promotion.3. Deploy to canary (5% traffic) → automated canary experiments (pod evictions, small latency injection). If canary health OK, promote; else rollback.4. Post-promotion, low-blast production experiments run continuously (limited scope) with strict SLO-based abort rules. Weekly SRE-managed blast-day runs deeper scenarios.

This plan ensures resilience tests give meaningful, actionable feedback at the right stage: blocking when developer feedback is most valuable (CI/staging), protecting users via canary gating, and exercising production resilience without creating unnecessary release friction.

Algorithmic Problem SolvingMediumTechnical

88 practiced

Implement the Disjoint Set Union (Union-Find) data structure in Python with path compression and union by rank. Provide methods find(x), union(x, y), and connected(x, y). Explain amortized time complexity per operation and a scenario in SRE where DSU is useful.

Sample Answer

To implement DSU with path compression and union by rank, we keep parent and rank arrays. find compresses the path recursively/iteratively; union attaches the smaller-rank tree under the larger-rank tree. connected checks if roots match.

python

class DisjointSet:
    def __init__(self, n):
        # parent[i] = parent of i; rank approximates tree height
        self.parent = list(range(n))
        self.rank = [0] * n

    def find(self, x):
        # Path compression: make nodes point directly to root
        if self.parent[x] != x:
            self.parent[x] = self.find(self.parent[x])
        return self.parent[x]

    def union(self, x, y):
        rx, ry = self.find(x), self.find(y)
        if rx == ry:
            return False  # already connected
        # Union by rank: attach smaller rank under larger
        if self.rank[rx] < self.rank[ry]:
            self.parent[rx] = ry
        elif self.rank[ry] < self.rank[rx]:
            self.parent[ry] = rx
        else:
            self.parent[ry] = rx
            self.rank[rx] += 1
        return True

    def connected(self, x, y):
        return self.find(x) == self.find(y)

Key points:- Path compression flattens trees during find; union by rank keeps heights small.- Amortized time per operation is effectively inverse-Ackermann α(n), which is practically constant (< 5) for realistic n.

SRE scenario:- Use DSU to track connectivity in a dynamic service mesh or network topology: when links/nodes fail or recover, union/union-find helps quickly determine whether two services remain reachable through available hops (e.g., during automated failover or building cluster partition detection). It's also useful for grouping affected hosts in incident blast-radius analysis.

Dependency Failures and Graceful DegradationMediumSystem Design

26 practiced

Design a cache fallback and 'stale read' strategy for a multi-region microservice that serves user profiles. Requirements: tolerate regional outages, minimize user-perceived errors, and bound staleness to 5 minutes for most fields but 30 seconds for presence. Describe cache hierarchy, TTLs, and invalidation across regions.

Sample Answer

Requirements clarification:- Serve user profiles across regions with tolerance for regional outages.- Minimize user-visible errors; prefer serving slightly stale data over errors.- Bound staleness: presence ≤30s, other profile fields ≤5min for most fields.

High-level approach:- Multi-level cache with aggressive local serving and controlled stale-while-revalidate + cross-region fallback. Use versioned writes and async invalidation to keep staleness bounded.

Cache hierarchy and components:1. L1: in-process or per-node local cache (hot items, TTL short). Fastest reads, very small.2. L2: regional distributed cache (e.g., Redis cluster / ElastiCache) with data partitioned by user-id. Primary source for region.3. L3: cross-region read replica or global cache (replicated asynchronously) used only when regional services are degraded.4. Origin: primary datastore (multi-region writes handled by a single-writer-per-user or CRDTs; prefer single-writer per user (owner region) to avoid conflicts).

TTL and stale policies:- Presence: live TTL = 30s, with stale-while-revalidate window = 60s. On read if TTL expired, serve stale presence up to 60s only if origin/regional cache unavailable; otherwise trigger async refresh.- Profile fields: TTL = 5 minutes, stale-while-revalidate window = 10 minutes (serve stale up to extra 10m only under outage).- Add small random jitter to TTLs to avoid thundering herd.

Read flow:1. Check L1. If fresh -> return.2. Else check L2 regional cache. If fresh -> populate L1 and return.3. If L2 miss or expired: - Non-outage: synchronous fetch from regional read-replica DB or origin, update L2, return. - If regional DB/cache degraded or high latency: fall back to L3 cross-region cache (serve slightly stale within allowed stale window) and asynchronously request a refresh from origin.4. If origin unreachable and stale window exceeded: return best-effort cached data with a flag indicating staleness for UX; only if no cached data at all return an error.

Write and invalidation:- Writes go to authoritative owner (single-writer per user). After commit: - Synchronously invalidate/update local L2 in the owner's region. - Publish an invalidation/update event to a cross-region pub/sub (Kafka / Pulsar / SNS) with user-id and new version/token. - Regional caches subscribe and either invalidate or pull updated profile. Use version numbers (monotonic sequence or vector timestamp) to avoid applying older updates.- Use fan-out batching and rate limit invalidations to protect under heavy write storms.

Consistency bounding:- Enforce versioned reads (ETag or sequence) so consumers can detect how stale a cached copy is.- For presence, prefer eventual strong freshness: clients can subscribe to a presence stream for critical paths, otherwise rely on 30s TTL.

Operational concerns:- Circuit breakers and adaptive timeouts when calling other regions; fail open to serve stale reads rather than error.- Observability: metrics for stale-serving rate, cache hit ratio, cross-region latency, backlog in pub/sub; SLOs for maximum stale-serving percentage.- Security: sign/authorize pub/sub events; validate ownership to avoid poisoning cache.

Trade-offs:- Serving stale data increases availability and UX but may surface slightly outdated info — mitigated by short bounds and explicit staleness flags.- Async invalidation reduces write latency but may allow small windows of staleness; versioning limits inconsistency.- Single-writer-per-user simplifies conflict resolution but requires routing writes consistently to owner region.

Edge cases:- Network partition: rely on stale-while-revalidate windows and extend only under outage; ensure automatic rollback of extended stale windows when region recovers.- High write rates: coalesce invalidations and use TTL = 0 + push updates for hot profiles (push model).- Cache poisoning: validate events and use signed versions.

This design favors availability and controlled staleness, with clear TTLs (presence 30s, profile 5min) and bounded stale windows, while using async cross-region invalidation and versioning to keep data reasonably fresh across regions.

Incident Leadership and PostmortemsMediumTechnical

30 practiced

Many action items from past postmortems remain open. Propose a process to increase action-item closure rates, including ownership assignment, visibility, prioritization, integration with engineering workflows, and metrics to demonstrate improvement.

Networking Fundamentals and TroubleshootingMediumTechnical

56 practiced

Explain the difference between stateful and stateless firewall rules and how connection tracking (conntrack) interacts with NAT and firewall performance. For a high-throughput edge firewall, what operational practices reduce rule-evaluation overhead and improve throughput?

Sample Answer

Stateful vs stateless rules- Stateless rules evaluate each packet independently: match on IP, port, protocol, direction. They’re simple and fast but require explicit allow rules for return traffic (every flow direction).- Stateful rules track connection/session state: once a flow is allowed, return packets are permitted based on connection state (e.g., ESTABLISHED, RELATED). This simplifies policies and blocks spoofed/unsolicited traffic more effectively.

Conntrack, NAT, and performance- Conntrack maintains a per-flow entry (5-tuple + state, timers, metadata). NAT updates packet headers and conntrack entries so return traffic maps correctly.- NAT and conntrack are tightly coupled: creating a new connection requires conntrack allocation and possibly NAT translation — extra CPU/memory work and memory pressure with many flows.- Performance impact: conntrack lookups are constant-time but creating entries (new flows) is more expensive than matching established flows. High churn (many short-lived connections) increases CPU and memory churn and can cause lookups to spill to slower paths or cause table exhaustion.

Operational practices to reduce rule-evaluation overhead and improve throughput- Minimize rule count and complexity: consolidate rules, use broad allow/deny where safe, order rules by frequency (hot rules first).- Use stateful defaults: allow ESTABLISHED/RELATED early so return packets bypass expensive checks.- Offload and accelerate: enable hardware offload (NICs, eBPF/XDP, SmartNICs) for fast-path filtering and NAT; use kernel-level conntrack helpers tuned for high performance.- Reduce conntrack pressure: increase table size and timeout tuning for expected workloads; disable conntrack for known stateless traffic (e.g., routing-only or high-volume UDP where safe).- Use connection rate-limiting and SYN cookies to protect from floods while avoiding excessive conntrack creation.- Split control/data plane: use lightweight stateless ACLs at the ingress and delegate deeper inspection to dedicated stateful firewalls or middleboxes.- Monitor and automate: instrument conntrack table usage, rule hit rates, and CPU; alert on high churn; automate rule cleanup and apply CI for ACL changes.- Test at scale: run load tests with realistic connection churn and measure latency, CPU, and conntrack exhaustion; iterate rules and timeouts.

These practices balance security and throughput for a high-throughput edge firewall while keeping conntrack and NAT resource use predictable.

Cross Functional Collaboration and CoordinationEasyTechnical

42 practiced

You are onboarding a new SRE into rotation for a service that suffers occasional high-latency incidents. Describe the concise runbook and handoff checklist you would create, what must be included for quick triage, and how you would measure runbook effectiveness after two weeks of rotation.

Deployment and Release StrategiesMediumTechnical

76 practiced

Describe how you would implement progressive rollouts by region for a global service. Include routing strategies, geographic traffic splitting, canary sizing per region, and monitoring that respects regional baselines and seasonality.

Sample Answer

Situation: We need to safely roll a new service release across global regions while limiting blast radius and respecting regional traffic patterns.

Approach (high level):- Use a progressive, region-by-region canary controlled by traffic routing and feature flags; automate rollouts and rollbacks.

Routing & geographic traffic splitting:- At edge: geo-aware DNS + CDN + global LB (GSLB) to route users to nearest region by latency/POPs.- Within region: L7 load balancer or service mesh (Envoy/Istio) to perform weighted routing (canary vs stable).- Implement per-region traffic weights via centralized config (GitOps) so each region’s weight is independent.

Canary sizing per region:- Determine canary percentage based on region traffic volume and SLO/error budget. Example strategy: - Low-volume regions: start at 10% of regional traffic (min 50–200 rps) - High-volume regions: start at 1–5% but cap absolute requests to observe meaningful signals (e.g., 500–2000 requests/min)- Phases: smoke (1–5%), small canary (10%), ramp (25%, 50%), global (100%). Pause between phases with automated checks.

Monitoring that respects regional baselines & seasonality:- Maintain per-region baselines for key metrics (latency P50/P95/P99, error rate, traffic, resource utilization) using rolling windows (7, 28 days) and business-hour vs off-hour buckets to account for seasonality.- Use anomaly detection (seasonal ETS/Prophet or ML-based) to compare canary signals against regional expected ranges, not global averages.- Define automated guardrails: - Hard abort thresholds (e.g., error rate >2x baseline or CPU >85% sustained) - Soft warnings for deviations that require manual review- Correlate logs/traces per region and sample traces from canary requests for debugging.

Automation & safety:- Orchestrate rollout with CI/CD pipeline + feature flag service + runbook. Pipeline triggers weighted routing changes via API; each step waits for monitoring checks.- Use circuit breakers, rate limits, and automatic rollback if thresholds crossed.- Post-rollout: promote metrics into baseline and run postmortem for any anomalies.

Why this works:- Localized routing minimizes cross-region noise.- Per-region weights and absolute request caps ensure statistical significance while limiting blast radius.- Regional baselines and seasonality-aware detection reduce false positives and surface real regressions quickly.

Practice Site Reliability Engineer (SRE) questions across all topics

Additional Information

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

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

Meta Site Reliability Engineer (Senior Level) Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Motivation for Senior SRE Role

Practice Interview

Study Questions

Meta-Specific Interest and Knowledge

Practice Interview

Study Questions

SRE Career Narrative

Practice Interview

Study Questions

Technical Phone Screen

What to Expect

Tips & Advice

Focus Topics

Optimization and Scalability Thinking

Practice Interview

Study Questions

Data Structures

Practice Interview

Study Questions

Algorithms and Problem-Solving

Practice Interview

Study Questions

Code Quality and Communication

Practice Interview

Study Questions

Onsite Round 1: Coding and Algorithms

What to Expect

Tips & Advice

Focus Topics

Code Testability and Verification

Practice Interview

Study Questions

Systems-Oriented Coding Problems

Practice Interview

Study Questions

Concurrency and Synchronization

Practice Interview

Study Questions

Error Handling and Robustness

Practice Interview

Study Questions

Onsite Round 2: System Design - Monitoring and Observability

What to Expect

Tips & Advice

Focus Topics

Distributed Systems Tracing and Debugging

Practice Interview

Study Questions

Alerting and Anomaly Detection

Practice Interview

Study Questions

Metrics Collection and Time-Series Storage

Practice Interview

Study Questions

SLI, SLO, and Error Budget Design

Practice Interview

Study Questions

Onsite Round 3: System Design - Infrastructure and Deployment

What to Expect

Tips & Advice

Focus Topics

Operational Validation and Testing Infrastructure

Practice Interview

Study Questions

Resilience Patterns and Graceful Degradation

Practice Interview

Study Questions

Service Discovery and Configuration Management

Practice Interview

Study Questions

Safe Deployment and Release Strategies

Practice Interview

Study Questions