Google Senior Site Reliability Engineer Interview Preparation Guide

Site Reliability Engineer (SRE)

Google

Senior

7 rounds

Updated 6/22/2026

Google's Senior SRE interview process typically consists of 7 rounds spanning 4-6 weeks. The process begins with a recruiter screening, followed by two technical phone screens assessing coding and systems knowledge, and concludes with four onsite interviews covering coding, system design, Linux/troubleshooting expertise, and behavioral/cultural fit. Google evaluates candidates on four main attributes: General Cognitive Ability (GCA), Role-Related Knowledge and Experience (RRKE), Coding proficiency, and Googleyness & Leadership. The interview emphasizes problem-solving in ambiguous situations, systems thinking, and the ability to design scalable, reliable infrastructure.

Interview Rounds

Recruiter Screening

45 min3 focus topicsculture fit

What to Expect

The initial recruitment phase combines the initial recruiter conversation and any follow-up recruiter touchpoints into a single round. This 30-45 minute call screens for basic qualifications, role fit, and motivation. The recruiter will verify your background, discuss your interest in the SRE role at Google, explain the interview process, and answer logistical questions. This is your opportunity to demonstrate enthusiasm for building reliable systems at scale and show alignment with Google's mission.

Tips & Advice

Be clear and concise about your SRE background and the specific reasons you're interested in Google's infrastructure work. Highlight projects where you improved system reliability or reduced operational toil. Prepare a compelling answer to 'Why Google?' that goes beyond brand recognition—mention specific products, infrastructure challenges, or Google's approach to reliability engineering. Ask thoughtful questions about the team, projects, and Google's SRE culture. For senior roles, mention your experience mentoring others and leading cross-functional initiatives.

Focus Topics

Google Products and Infrastructure Knowledge

Demonstrate familiarity with Google's scale, products, and infrastructure challenges. Understand Google's approach to reliability, SLOs, and error budgets. Show awareness of Google's open-source contributions like Kubernetes, Go language, or SRE practices documented in Google's SRE books.

Practice Interview

Study Questions

Career Motivation and Role Alignment

Articulate why you're drawn to the SRE role specifically and why Google is the right next step in your career. Discuss your passion for building scalable, reliable systems and reducing operational burden through automation. For senior level, emphasize your interest in shaping reliability culture across teams and mentoring the next generation of SREs.

Practice Interview

Study Questions

Background and Relevant Experience

Summarize your SRE/DevOps journey, highlighting key projects involving incident response, automation, monitoring systems, and infrastructure scaling. For senior level, emphasize leadership of reliability initiatives, cross-team influence, and measurable impact on system availability and performance.

Practice Interview

Study Questions

Phone Technical Screen - Coding and Algorithms

60 min3 focus topicstechnical

What to Expect

This 60-minute phone interview assesses algorithmic problem-solving and coding ability. You'll solve 1-2 coding problems of medium-to-hard difficulty, typically using LeetCode-style questions but with emphasis on the approach and communication rather than perfect syntax. For senior SREs, expect problems involving graph algorithms, tree traversal, dynamic programming, or problems that require optimization thinking. You'll code on a shared collaborative editor while explaining your thought process.

Tips & Advice

Start by understanding the problem completely—ask clarifying questions about constraints, input size, and edge cases. State your assumptions and approach before coding. Walk the interviewer through your solution verbally before implementing. For optimization-focused problems, discuss trade-offs between time and space complexity. Write clean, readable code even if you know it might not be perfect. Explain why you chose certain data structures. For senior level, interviewers expect you to think about scalability implications and optimize for maintainability. Practice explaining complex algorithms clearly—your communication matters as much as correctness.

Focus Topics

Problem-Solving Approach and Communication

Develop a systematic approach: understand the problem, ask questions, discuss approach, code, test edge cases, optimize. Practice explaining complex solutions clearly. For senior level, articulate trade-offs and architectural decisions confidently. Show awareness of maintainability and scalability beyond just correctness.

Practice Interview

Study Questions

Graph Algorithms and Tree Traversal

Master BFS and DFS algorithms, shortest path problems, graph connectivity, cycle detection, and tree problems. Understand when to use each approach. For senior level, be comfortable discussing trade-offs and suggesting optimizations. Know how to apply these concepts to infrastructure problems (e.g., dependency graphs, network topology).

Practice Interview

Study Questions

Data Structures and Optimization

Master hash tables, heaps, arrays, linked lists, and sets. Understand when to use each and their complexity trade-offs. Practice optimizing problems by selecting appropriate data structures. Example: designing a data structure to track max temperature in past 24 hours. For senior level, think about distributed versions of these structures.

Practice Interview

Study Questions

Phone Technical Screen - Systems and Troubleshooting

60 min4 focus topicstechnical

What to Expect

This 60-minute phone interview focuses on systems-level knowledge and troubleshooting methodology. You'll face a hypothetical systems problem—typically a scenario where a service is misbehaving and you need to diagnose the root cause. These problems test your understanding of networking (DNS, routing, connectivity), Linux internals, common failure modes, and systematic debugging approaches. For senior SREs, expect more ambiguous scenarios requiring deep analysis and consideration of distributed system complexities.

Tips & Advice

Approach troubleshooting systematically: first, establish the scope and symptoms clearly by asking probing questions. Use a logical framework to isolate the problem (application layer vs infrastructure, single service vs systemic). Discuss relevant tools and commands (ping, traceroute, netstat, strace, etc.). For senior level, think holistically about distributed systems—consider load balancing, caching, database replication issues, and inter-service communication. Document your thought process and ask for additional information as you diagnose. Avoid jumping to conclusions; validate hypotheses. Show familiarity with common failure modes in production systems.

Focus Topics

Monitoring and Observability Concepts

Understand metrics, logs, and traces. Know how to use these signals to diagnose problems. Discuss alert design and how to avoid false positives/negatives. For senior level, think about distributed tracing, correlation IDs, and structured logging. Understand the relationship between SLOs and alerting.

Practice Interview

Study Questions

Systematic Troubleshooting Methodology

Develop a structured approach: gather symptoms, form hypotheses, test systematically, and iterate. Know how to isolate problems (is it code, infrastructure, external dependency?). For senior level, think about distributed systems troubleshooting—eventual consistency, cascading failures, and cross-service debugging. Understand tracing and observability for complex issues.

Practice Interview

Study Questions

Linux Networking Fundamentals

Deep understanding of TCP/IP stack, DNS resolution process, network interfaces, routing tables, and connection states. Know how to diagnose connectivity issues, port conflicts, and network configuration problems. Understand concepts like NAT, firewalls, and load balancers. For senior level, understand how these apply at scale in cloud environments.

Practice Interview

Study Questions

Linux Internals and Process Management

Understand processes, threads, file descriptors, memory management, and CPU scheduling. Know tools like top, ps, lsof, and strace for process inspection. Understand signals, zombie processes, and resource limits. For senior level, think about performance tuning, resource contention, and how to diagnose performance issues.

Practice Interview

Study Questions

Onsite Interview Round 1 - Coding

75 min3 focus topicstechnical

What to Expect

The first onsite round is a 60-75 minute coding interview, similar in structure to the phone screen but with a slightly higher difficulty bar since you're meeting in person with more opportunity for discussion. You'll solve 1-2 coding problems, typically medium-to-hard LeetCode-style questions with emphasis on algorithmic thinking and optimization. For senior SREs, interviewers may include additional considerations like parallelization, distributed computing, or real-world system design implications.

Tips & Advice

Treat this similarly to the phone screen but with opportunity for deeper collaboration. The interviewer will want to see your thought process in detail. Don't hesitate to think out loud and discuss multiple approaches. For senior candidates, showing awareness of how an algorithm scales to distributed systems is valuable. Discuss complexity analysis thoroughly. Test edge cases comprehensively. Be confident but open to feedback—if the interviewer suggests a different approach, show you can adapt. For this in-person round, handwriting or whiteboard clarity matters if doing live coding.

Focus Topics

Communication and Collaboration

Explain your approach clearly before coding. Engage the interviewer in discussion about trade-offs. Ask clarifying questions if the problem seems ambiguous. For senior level, be comfortable leading the conversation and confidently defending your design decisions while remaining open to alternatives.

Practice Interview

Study Questions

Optimization and Trade-Off Analysis

Beyond getting a working solution, optimize for time/space complexity. Discuss trade-offs explicitly—when is O(n log n) acceptable vs needing O(n)? For senior level, consider practical constraints like memory limits, cache efficiency, and parallelization potential. Discuss real-world trade-offs like implementation complexity vs performance.

Practice Interview

Study Questions

Advanced Algorithm Patterns

Master complex patterns including dynamic programming, recursion with memoization, backtracking, and greedy algorithms. Understand when each is applicable. Practice problems involving multiple dimensions of complexity. For senior level, think about how algorithms scale and can be optimized further.

Practice Interview

Study Questions

Onsite Interview Round 2 - System Design (NALSD)

75 min5 focus topicssystem design

What to Expect

This 60-75 minute interview focuses on designing a complex, large-scale system (Non-Abstract Large System Design). You'll receive a vague, ambiguous problem (e.g., 'Design a system for monitoring and alerting across Google's global infrastructure' or 'Design a file distribution system for deploying to millions of servers'). You must ask clarifying questions to understand requirements, propose an architecture, discuss trade-offs, and defend your design. For senior SREs, interviewers expect deep consideration of reliability, scalability, disaster recovery, and operational concerns.

Tips & Advice

Start by asking clarifying questions—don't assume requirements. Discuss scale explicitly: how many requests per second? How much data? Geographic distribution? For system design, focus on components, data flow, and trade-offs. For senior SREs specifically, emphasize operational aspects: How would you monitor this? How would you recover from failures? What's the SLO? How would you handle incidents? Discuss multiple approaches and why you chose yours. Be prepared to defend your design and adapt if questioned. Draw diagrams on the whiteboard or use collaborative tools. For senior level, think about real Google systems—Kubernetes, distributed configuration systems, incident management platforms—and how they solve similar problems. Discuss failure modes and resilience patterns.

Focus Topics

Technology Choices and Trade-Offs

Discuss why you'd use specific technologies: relational vs NoSQL databases, message queues vs RPC, caching strategies. Understand trade-offs (consistency, performance, operational complexity). For senior level, align choices with team expertise, operational burden, and long-term maintainability.

Practice Interview

Study Questions

Reliability, Fault Tolerance, and Disaster Recovery

Design for failures: redundancy, failover mechanisms, data durability, backup strategies. Discuss recovery time objectives (RTO) and recovery point objectives (RPO). For senior SREs, think about multi-region deployments, graceful degradation, and circuit breakers. Understand observability requirements for incident response.

Practice Interview

Study Questions

SRE-Specific Operational Considerations

Design with operations in mind: monitoring and alerting strategy, runbooks for common failures, deployment procedures, incident response process. Define SLOs and error budgets. For senior level, discuss how to reduce toil, automate operational tasks, and measure reliability. Think about on-call burden and how design impacts ops.

Practice Interview

Study Questions

Distributed System Fundamentals

Understand CAP theorem, consistency models (strong, eventual), replication strategies, and consensus algorithms. Know when to use synchronous vs asynchronous communication. For senior SREs, apply these to design decisions—replication for reliability vs consistency trade-offs.

Practice Interview

Study Questions

Scalability and Performance Architecture

Discuss horizontal vs vertical scaling, load balancing strategies, caching layers, database sharding, and async processing. Understand bottlenecks and how to identify/address them. For senior level, think about capacity planning, growth projections, and long-term scalability.

Practice Interview

Study Questions

Onsite Interview Round 3 - Linux Internals and Infrastructure

75 min5 focus topicstechnical

What to Expect

This 60-75 minute interview goes deep into Linux systems knowledge and infrastructure troubleshooting. Expect a mix of theoretical questions about kernel concepts and practical troubleshooting scenarios. Example topics: process scheduling, memory management, filesystem operations, container internals, kernel networking stack, or a scenario like 'Your containerized application is experiencing high latency—how would you diagnose?' For senior SREs, expect complex scenarios involving performance tuning at scale, distributed system challenges, or Kubernetes/container orchestration issues.

Tips & Advice

Demonstrate deep Linux knowledge through specific examples and hands-on understanding. When discussing kernel concepts, explain the practical implications. For troubleshooting scenarios, think systematically about layers—hardware, kernel, application. For senior level, discuss how to measure and profile systems, think about performance tuning at scale, and consider trade-offs between throughput and latency. Show familiarity with container technologies and Kubernetes since these are core to modern infrastructure. Discuss monitoring strategies for complex infrastructure. Be prepared to debug real problems—even if you don't know the exact answer, show strong diagnostic methodology.

Focus Topics

Storage, Filesystems, and I/O

Understand different filesystem types (ext4, btrfs), I/O schedulers, write-ahead logging, and data durability. Know how to diagnose I/O bottlenecks. For senior level, understand implications for databases and distributed systems. Know about eventual consistency implications of different storage strategies.

Practice Interview

Study Questions

Performance Profiling and Tuning

Master profiling tools: perf, flame graphs, top, iostat, vmstat. Understand CPU profiling, memory profiling, and I/O analysis. Know how to identify bottlenecks and optimize. For senior level, discuss systematic tuning methodology, trade-offs (e.g., CPU vs memory), and how tuning impacts reliability.

Practice Interview

Study Questions

Container Technologies and Kubernetes

Understand container internals: cgroups for resource limiting, namespaces for isolation (network, PID, IPC), overlayfs for filesystem. Know Kubernetes architecture, pod lifecycle, service discovery, persistent volumes. For senior SREs, understand networking in Kubernetes, CNI plugins, and how to troubleshoot container issues. Be aware of security implications.

Practice Interview

Study Questions

Linux Kernel and Process Management

Deep dive into process creation, scheduling, context switching, memory management (virtual memory, page tables, swapping), and file descriptors. Understand system calls and how user space interacts with kernel. For senior level, understand performance implications—CPU affinity, NUMA, and memory locality. Know how to profile and optimize.

Practice Interview

Study Questions

Networking at the Kernel Level

Understand TCP/IP stack in the kernel, socket operations, connection states, buffer management. Know tools like tcpdump, netstat, ss for network debugging. For senior level, understand performance optimization—TCP tuning, network card tuning, and how to diagnose packet loss or latency.

Practice Interview

Study Questions

Onsite Interview Round 4 - Behavioral and Leadership

75 min6 focus topicsbehavioral

What to Expect

This 60-75 minute behavioral interview assesses your fit with Google's culture (Googleyness), leadership style, collaboration, and decision-making. You'll answer questions about past experiences, team conflicts, failures, and how you approach challenges. For senior SREs, expect deep discussion of how you've mentored others, influenced cross-functional projects, and shaped team direction. Interviewers will assess whether you embody Google's values: bias for action, collaboration, humility, and drive for impact.

Tips & Advice

Prepare specific, detailed stories using the STAR method (Situation, Task, Action, Result). For senior roles, focus on examples showing leadership: mentoring junior engineers, leading cross-functional initiatives, influencing team strategy, or driving major reliability improvements. Discuss incidents honestly—Google values learning from failure and intellectual humility. When discussing setbacks, explain what you learned and how you improved. Show genuine passion for reliability engineering and building systems that serve billions of users. Discuss your philosophy on SRE practices: error budgets, toil reduction, blameless postmortems. Be authentic about disagreements you've navigated. For Google specifically, show familiarity with their culture and values. Ask thoughtful questions about the team and how they operate.

Focus Topics

Google Cultural Fit and Values Alignment

Demonstrate familiarity with and alignment to Google's values: bias for action, user focus, collaboration, innovation, and integrity. Show understanding of Google's scale and unique challenges. For senior level, discuss how you'd contribute to Google's culture and mentor others to embody these values.

Practice Interview

Study Questions

Problem-Solving and Adaptability

Show how you've approached ambiguous problems, adapted to changing priorities, and learned new technologies. For senior level, discuss complex problems you've solved, how you've managed technical debt, or how you've navigated organizational change. Show flexibility and growth mindset.

Practice Interview

Study Questions

Collaboration and Cross-Functional Work

Show examples of working effectively with product teams, infrastructure teams, security, and other disciplines. Discuss how you've balanced competing priorities and needs. For senior SREs, demonstrate ability to navigate complex organizational dynamics, influence without authority, and build consensus. Show cultural awareness and ability to work with diverse perspectives.

Practice Interview

Study Questions

Passion for Reliability and Operational Excellence

Articulate your philosophy on SRE—why operational excellence matters, how you think about error budgets and SLOs, your approach to toil reduction. Show genuine enthusiasm for building systems that work reliably at scale. For senior level, discuss how you've improved reliability in past roles and your vision for building exceptional SRE practices.

Practice Interview

Study Questions

Incident Response and Learning Culture

Discuss how you've managed critical incidents—your decision-making under pressure, coordination with teams, communication. Focus on blameless postmortems and learning from failures. For senior level, discuss how you've built incident response culture, improved process, or mentored others on incident response. Show ownership and accountability.

Practice Interview

Study Questions

Leadership and Influence

Demonstrate how you've led projects or influenced decisions without formal authority. For senior SREs, discuss how you've shaped team direction, championed reliability initiatives, or influenced architectural decisions across teams. Show examples of mentoring junior engineers, teaching reliability practices, or building SRE culture. Discuss your philosophy on building high-performing teams.

Practice Interview

Study Questions

Frequently Asked Site Reliability Engineer (SRE) Interview Questions

Blameless Postmortem and Organizational LearningEasyTechnical

40 practiced

What constitutes a 'near-miss' incident in production, and how would you run a lightweight blameless postmortem to capture actionable learnings without overburdening teams? Describe the minimum artifact you would expect from such a review.

Performance Profiling and OptimizationHardTechnical

27 practiced

Write a code snippet in your preferred language that implements a bounded object pool to reduce allocation churn for frequently allocated short-lived objects. Explain how you'd measure its impact on GC pause time and throughput in a production-like workload.

Sample Answer

To reduce allocation churn for short-lived objects in Go (common in services), use a bounded pool that reuses objects up to a capacity to avoid unbounded memory growth.

Approach: keep a fixed-size channel as the pool; Get tries to pop, otherwise allocates; Put returns to pool if not full. This limits memory and avoids excessive allocations while bounding retained objects.

package pool

// BoundedPool is a simple bounded object pool for buffers.
type BoundedPool struct {
    ch chan []byte
    size int // standard buffer size
}

func NewBoundedPool(capacity, bufSize int) *BoundedPool {
    return &BoundedPool{
        ch: make(chan []byte, capacity),
        size: bufSize,
    }
}

// Get returns a buffer from the pool or allocates a new one.
func (p *BoundedPool) Get() []byte {
    select {
    case b := <-p.ch:
        return b[:p.size] // reset length
    default:
        return make([]byte, p.size)
    }
}

// Put returns buffer to the pool if not full; else discard.
func (p *BoundedPool) Put(b []byte) {
    if cap(b) < p.size { return } // incompatible
    select {
    case p.ch <- b[:p.size]:
    default:
        // pool full -> drop, let GC collect
    }
}

Measuring impact (production-like workload):- Create a representative load test (concurrent clients, request sizes) and two runs: with and without pool.- Collect: - GC pause metrics (runtime/metrics or /debug/vars): total pause NS, pause count, and percentiles. - Throughput: requests/sec, latency P50/P95/P99. - Alloc/cycle and heap-alloc using pprof (heap, allocs) and runtime.ReadMemStats. - CPU profiles to ensure no contention in pool path.- Tools: go test + bench, vegeta/wrk for load, pprof, Prometheus exporters for gc_pause_seconds, process_resident_memory_bytes, and trace (runtime/trace).- Evaluate: reduction in heap allocations/sec, reduced GC pause time and lower tail latencies. Also verify no increased CPU or lock contention by checking mutex wait times and contention profiling.

Edge cases & tradeoffs:- Too-large capacity wastes memory; too-small yields frequent allocs.- Ensure Put happens in defer/cleanup paths; avoid holding pooled objects across goroutine boundaries incorrectly.- For languages with stop-the-world GC (older JVM), measure safepoint pauses and consider object pooling may be less effective; use escape analysis to tune allocation instead.

Reliability, Observability, and Incident ResponseEasyTechnical

65 practiced

Explain the difference between a Service Level Indicator (SLI), a Service Level Objective (SLO), and a Service Level Agreement (SLA). For a public HTTP JSON API propose a concrete SLO (metric, measurement window, and threshold), define an error budget and an example enforcement action when the budget is exhausted. Explain how you would compute the SLI from raw request metrics and which corner cases (traffic sinks, low-sample services) you would consider.

Sample Answer

SLI / SLO / SLA — short definitions- SLI (Service Level Indicator): a measurable signal of user-perceived service health (e.g., fraction of successful HTTP responses, p95 latency).- SLO (Service Level Objective): the target bound on an SLI over a defined measurement window (e.g., 99.95% success over 30 days).- SLA (Service Level Agreement): a formal contract with customers that typically links SLO breach to business consequences (credits, penalties).

Concrete SLO for a public HTTP JSON API- Metric: Request success rate = count(HTTP responses with 2xx) / count(all production user requests excluding planned maintenance and known health-checks).- Measurement window: 30-day rolling window.- Threshold: >= 99.95% success (equivalently <= 0.05% allowed failed requests).

Error budget and enforcement- Error budget = 1 - SLO = 0.0005 of requests in the window. If 1M requests/month → allowed failures = 500.- Enforcement action when exhausted: 1. Immediately pause non-essential releases and feature rollouts. 2. Require a postmortem and dedicate an incident squad until budget is restored to a safe level (e.g., 80% of budget remaining). 3. Throttle experimental traffic and increase alerting/observability for riskier components.

Computing the SLI from raw metrics- Collect per-request metrics: status_code, timestamp, route, user_agent, service_instance.- Compute numerator and denominator via time-windowed counts: numerator = sum_over_window(1 for status_code in 200..299 and not excluded) denominator = sum_over_window(1 for requests considered production user traffic) SLI = numerator / denominator (use sliding-window or fixed-day buckets and aggregate).- Implementation notes: use high-resolution counters (Prometheus counters + recording rules or streaming aggregation) and compute the rolling-window ratio server-side to avoid division-of-rates pitfalls.

Corner cases to handle- Traffic sinks / bots / probes: exclude synthetic health-checks, internal monitoring, or obvious bot user-agents from denominator so they don’t distort SLI.- Retries & duplicates: count only the original client request when possible, or deduplicate by request-id; otherwise, retries can falsely inflate denominator.- Low-sample services: if total denominator < min_samples (e.g., 1k requests over window), treat SLI as “insufficient data” and either lengthen window (90 days) or switch to latency-based SLOs or combine with related endpoints.- Partial failures and client errors: choose whether 4xx should be considered failures (usually yes if user-visible). For some APIs, differentiate between user-caused 4xx and server 5xx, and possibly have separate SLOs.- Clock skew, aggregation gaps: use monotonically-increasing counters and compute deltas; guard against counter resets.- Maintenance windows: exclude scheduled maintenance windows from denominator and clearly mark them.

Why this approach- Success-rate SLO is intuitive for public APIs and maps directly to user experience.- Rolling 30-day window balances responsiveness and statistical stability.- Error budget enforces trade-offs between velocity and reliability and gives concrete operational actions when exceeded.

Problem Solving and Communication ApproachHardTechnical

26 practiced

As an SRE lead, you are responsible for ensuring post-incident remediation. Some engineers resist the required changes due to perceived low priority. Explain how you would influence the team to complete remediations, how you would measure progress, and how you would maintain psychological safety during enforcement.

Sample Answer

Situation: After a Sev2 outage, our post-incident review identified five remediation tasks; several engineers pushed back saying they were low priority compared to feature work.

Task: As SRE lead I needed to ensure remediations were completed without damaging team morale or creating adversarial enforcement.

Action:- I translated each remediation into risk terms and business impact (likelihood × blast radius) and mapped them to SLO/error‑budget exposure so the team could see concrete harm.- Created a prioritized remediation backlog in the same tracker we use for product work, with clear owners, acceptance criteria, and timeboxes (e.g., quick mitigation within 2 weeks, long-term fix in 8 weeks).- Reduced friction: removed blockers (test infra, access), paired an SRE with an app engineer for knowledge transfer, and allocated a small % of each sprint to reliability work so it wasn’t an “extra.”- Measured progress with a dashboard: remediation backlog size, % remediations with owner, mean time to remediate (MTTRem), percent closed on schedule, and error‑budget impact reduced.- To enforce without blame: ran blameless postmortems, invited engineers to reprioritization decisions, recognized contributors publicly, and set clear escalation rules (manageral follow-up only after repeated missed commitments with documented blockers).- If resistance persisted, I made remediation completion part of team OKRs and individual goals tied to career development conversations — not punishment, but expectations aligned to business risk.

Result: Within two quarters the backlog declined 80%, MTTRem dropped from 21 days to 7 days, and error‑budget burn from similar incidents fell by 60%. Team feedback showed higher trust in the post‑incident process because they had input, support, and clear metrics.

This approach balances influence (data + remove friction + shared ownership), measurable progress, and preservation of psychological safety through transparency, partnership, and non‑punitive accountability.

Container Orchestration and Kubernetes OperationsEasyTechnical

75 practiced

As an SRE, explain the relationship between a Pod, ReplicaSet, and Deployment in Kubernetes, including how a Deployment controls rollouts and rollbacks. Describe what happens when you scale a Deployment from 3 to 10 replicas, how ReplicaSets are created or retained during a rolling update, and how ownership metadata is used to garbage collect old ReplicaSets.

Sample Answer

A concise relationship:- Pod: the smallest deployable unit (one or more containers).- ReplicaSet (RS): ensures a desired number of identical Pods are running (self-healing).- Deployment: a higher-level controller that manages ReplicaSets to provide declarative updates (rollouts/rollbacks), scaling and history.

How Deployments control rollouts and rollbacks:- You declare a new Pod template in the Deployment. For a rolling update (default strategy), the Deployment creates a new ReplicaSet for that template, then gradually increases the new RS and decreases the old RS according to strategy parameters (spec.strategy.rollingUpdate: maxSurge, maxUnavailable).- Rollback: Deployment retains previous ReplicaSets (revision history). To roll back, the controller scales the chosen old RS up and scales the current RS down, restoring the previous Pod template and replica counts. revisionHistoryLimit controls how many old RSs are kept.

Scaling from 3 to 10 replicas:- If you scale the Deployment (kubectl scale deployment/myapp --replicas=10) the Deployment controller updates the active ReplicaSet’s .spec.replicas to 10. The ReplicaSet creates 7 additional Pods to reach 10, using its Pod template and selector.

ReplicaSet creation/retention during rolling updates:- On update, a NEW ReplicaSet is created for the new Pod template. The old ReplicaSet(s) are retained by default (not deleted) so you can roll back. The controller shifts traffic by scaling the new RS up and old RS down per maxSurge/maxUnavailable. Old RSs remain with their Pod objects until scaled to zero or removed by GC (or manually).

Ownership metadata and garbage collection:- ReplicaSets created by a Deployment include ownerReferences with controller=true pointing to the Deployment (and a deployment-managed label/revision annotation). Kubernetes garbage collector uses ownerReferences: when the Deployment is deleted with default propagation, its owned ReplicaSets are garbage-collected. Separately, the Deployment’s revisionHistoryLimit determines how many old RSs to keep; the controller will delete oldest RSs beyond that limit (using ownership/labels to identify them).

Operational notes for SREs:- Watch maxSurge/maxUnavailable to control availability during rollouts.- Monitor ReplicaSet and Pod events and rollout status (kubectl rollout status/deployment) to detect stuck rollouts.- Use revisionHistoryLimit to conserve resources but keep enough history for safe rollbacks.

Observability Fundamentals and AlertingEasyTechnical

93 practiced

Compare metric types: counter, gauge, histogram, and summary (Prometheus semantics). For each type give one practical example metric (for example total_requests, cpu_usage, request_latency_histogram) and explain when you would choose that type in a production service.

Blameless Postmortem and Organizational LearningEasyTechnical

39 practiced

When should an SRE team run a postmortem? Define thresholds or criteria (e.g., severity, customer impact, SLO breach, near-miss frequency, repeated failures) you would use at enterprise scale, and explain why those criteria balance learning effort versus noise.

Performance Profiling and OptimizationMediumTechnical

35 practiced

Explain how you would design production-safe profiling hooks that can be toggled per-service and per-host, ensure low overhead by default, and capture richer data on demand. Describe API design, security, rate limits, and how you would integrate these hooks with an alerting system.

Sample Answer

Requirements & goals:- Toggle profiling per-service and per-host- Low overhead by default; richer capture on demand- Secure, rate-limited, auditable- Integrates with alerting and incident workflows

Design overview:- Lightweight in-process hooks: always-compiled thin probes (cpu, heap, eBPF if kernel), but idle by default (sampling=0.1%).- Remote controller + local agent: central control plane stores toggles; agents poll or subscribe via secure channel to apply per-service/per-host configs.

API design (REST + gRPC for realtime):- GET /config?service=svc-name&host=host-id -> returns {enabled:bool, mode: "low"/"burst"/"continuous", sample_rate:0.001, duration_sec:60, allowed_profiles:[cpu,alloc,trace]}- POST /request-profile -> {service, host, mode, duration, reason, requester} returns job-id; controller validates and issues short-lived token to agent for richer capture.- Webhook/gRPC stream to push immediate toggles for on-call overrides.

Modes:- low: continuous ultra-low overhead sampling (statistical summaries)- burst: higher-rate for short window (e.g., 60s) for troubleshooting- continuous: sustained profiling allowed only for non-prod or with strict quotas

Security & audit:- AuthN: mTLS + service accounts; RBAC on controller (who can request burst/continuous)- AuthZ: fine-grained policies: only devs for their service, SREs for production, emergency role for on-call- Tokens: short TTL per profiling job- Audit logs: every toggle/request recorded with requester, reason, timestamps, and job-id; integrate with SIEM.

Rate limiting & safety:- Global and per-host quotas: e.g., max 4 burst jobs per host per 24h; circuit-breaker if CPU or latency impact > threshold- Profiler enforces runtime guardrails: if profiling raises CPU/latency beyond X% of baseline, automatically reduce sampling or abort and emit metric- Backpressure: controller denies requests when cluster-wide profiling load high

Data capture & storage:- Sampled flamegraphs, stack traces, allocation traces; metadata: service, host, git-revision, build-id, correlation-id (job-id)- Upload to secure object store with TTL and retention policies; sensitive data scrubber for secrets in stacks

Integration with alerting:- Emit metrics: profiling.active_jobs, profiling.cpu_overhead, profiling.aborts, profiling.requests_denied- Alert rules: - High profiling overhead -> page SRE runbook and auto-disable profiling on impacted hosts - Unusual profiling requests (e.g., from unexpected principal or high frequency) -> security alert to on-call + audit - Excessive denied requests -> ops alert- On incident runbook: from alert, on-call can trigger POST /request-profile with mode=burst; controller attaches job-id and auto-links profile artifacts to the incident ticket (e.g., PagerDuty/Slack link).

Operational considerations:- Canary rollout of profiler to subset of hosts; measure overhead before broader enablement- Simulate load & failure modes; ensure profiler self-throttles- Provide SDK for apps to annotate traces and to opt-out specific code regions

Example config JSON returned by controller:{ "enabled": true, "mode": "low", "sample_rate": 0.001, "burst_quota_remaining": 3}

This design prioritizes safety by default, gives controlled escalation for deeper diagnostics, enforces policy & quotas, and ties profiling events and metrics into alerting and incident workflows for fast, auditable response.

Reliability, Observability, and Incident ResponseEasyTechnical

51 practiced

For a typical stateless RESTful web API, list and prioritize 6–8 observability metrics you would instrument (SLIs and internal metrics). For each metric, explain why it matters for reliability, whether you'd expose it as an SLO or internal health metric, and how you would tag/dimension it (e.g., by region, endpoint, client). Consider latency percentiles, error rates, throughput, saturation, and business metrics.

Sample Answer

1) Request latency (p50/p90/p99) per endpoint — Why: latency affects user experience and surfaces performance regressions; p99 catches tail latency. SLO or internal: Expose p90/p99 as SLOs (user-facing), keep full histogram internally for debugging. Tags: endpoint, HTTP method, region, deployment/version, client-id.

2) Error rate (5xx and client-visible errors) — Why: indicates functional failures and regressions. SLO or internal: 5xx rate as primary SLO (e.g., % of successful requests), 4xx monitored internally (may indicate client issues). Tags: endpoint, error-code, region, instance, client-id.

3) Throughput (requests/sec) — Why: capacity and traffic pattern visibility, correlates with cost and scaling. SLO or internal: internal (supports capacity planning, alerting on spikes/drops). Tags: endpoint, region, zone, deployment/version.

4) Saturation (CPU, memory, thread pool/utilization, connection pool usage) — Why: shows resource exhaustion leading to latency/errors. SLO or internal: internal health metrics and alerting. Tags: host/instance, node-pool, region, container-id.

5) Queue/backlog length (request queue, worker queue) — Why: early indicator of overload and increased latency. SLO or internal: internal alerting (auto-scale/mitigation). Tags: worker-type, region, queue-name.

6) Error budget burn rate / remaining error budget — Why: operational decision-making for launches/rollbacks. SLO or internal: exposed to SRE/PM dashboards (not public). Tags: SLO-name, time-window, team.

7) Business metric tied to API (e.g., checkout success rate, orders/sec) — Why: aligns reliability with business impact. SLO or internal: surface as SLO if critical business flow; otherwise internal. Tags: customer-segment, region, product-id.

8) Latency by downstream dependency (DB, cache, external API) — Why: isolates root cause of slow requests. SLO or internal: internal (used in runbooks). Tags: dependency-name, region, operation.

For each metric, collect as high-cardinality timeseries minimally; use rollups and cardinality limits. Combine alerts: symptom-first (latency/error rate) then cause (saturation/dependency).

Problem Solving and Communication ApproachHardTechnical

23 practiced

Thousands of containers exhibit large CPU spikes simultaneously. You're asked to find the root cause within two hours. Describe a prioritized data collection and sampling strategy, which signals to collect, how to triage noisy data, and how to coordinate multiple teams to execute the plan.

Sample Answer

Situation/goal: Within two hours I must identify the root cause of simultaneous large CPU spikes across thousands of containers, isolate whether it's platform-wide (node/kernel/cluster) or application-level, and enable targeted remediation.

Prioritized data-collection & sampling plan (first 0–30 minutes)- Triage hypothesis quickly: platform vs app vs external load. Start broad then narrow.- Global signals (collect immediately, high-frequency 10–15s): node CPU utilization, per-container CPU (cgroup cpuacct), node load, OOM/kubelet logs, kube-scheduler/controller logs, cluster autoscaler events, recent deploys/rollouts from CI/CD, network policy changes, and external traffic surge (LB metrics).- Sampling strategy: don't pull full traces for every container. Use multi-stage sampling: 1. Aggregate level: compute percentiles (P50/P95/P99) across containers and nodes to find clusters of abnormality. 2. Top-N sampling: identify top 1% containers by CPU and collect detailed traces (profiles, stack traces). 3. Stratified random sampling: if top-N only hits several services, sample additional containers across services/namespaces to ensure coverage.- Lightweight probes first: ps/top in batch, cgroup stats, container-level process list, and metrics from Prometheus. If available, enable eBPF to capture syscalls/CPU hot paths for sampled hosts.

Detailed diagnostics (30–90 minutes)- For sampled containers/nodes: collect perf/FlameGraph, pprof (if app exposes), thread dumps, GC stats (JVM/Go runtime), and strace/eBPF syscall histograms. Capture kernel scheduler/migration events.- Correlate time series: overlay CPU spikes with deploy timestamps, cron jobs, backup windows, batch jobs, autoscaler events, and network spikes.- Check resource throttling: CPU shares vs limits causing throttling loops; inspect cgroup throttling counters.- Verify noisy neighbor/affinity: check bin-packing changes, DaemonSet updates, or node-level processes (kube-proxy, kubelet, containerd).

Triage noisy/voluminous data- Reduce noise via aggregation and scoring: - Score containers by impact = CPU*duration*request-rate and prioritize high-score ones. - Use change detection (derivative) to pick entities with sudden deltas vs baseline. - Apply deduplication: group by image, command line, or stack trace signature. - Shift heavy profiling to sampled top-N; use stack-signature hashing to dedupe repeated traces.- Keep retention short — stream profiles to ephemeral storage and delete after analysis.

Immediate mitigations (parallel)- If platform saturation: cordon/evict non-critical nodes, scale out nodes, or increase node pool if autoscaling not reacting.- If a runaway process pattern identified: kill/rollback affected deployments or throttle CPU via QoS.- If suspected external traffic: rate-limit at ingress/LB.

Coordination & execution- Incident lead (SRE) assigns roles within first 5 minutes: monitoring lead, profiling lead, platform lead, app-owner liaisons, comms.- Use fixed communication: dedicated Slack channel + 10-minute checkpoints; post a runbook with data-collection commands and safe mitigation steps.- Engage service owners for sampled services to provide app-specific telemetry and confirm safe rollbacks.- Log actions in timeline; gate any global remediation by impact assessment.

Expected deliverables within 2 hours- Root-cause hypothesis supported by sampled profiles and correlated events (deploy, cron, traffic).- Short mitigation implemented (scale/cordon/rollback) or action plan for next 24h.- Post-incident: full capture of representative profiles, proposed systemic fixes (autoscaler tuning, resource requests/limits, CI gating), and a short postmortem runbook.

This approach prioritizes high-signal, low-cost collection, progressive sampling to focus deep diagnostics where it matters, deduplication to cut noise, and tight cross-team coordination to enable fast, safe remediation.

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

Google Senior Site Reliability Engineer Interview Preparation Guide

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Google Products and Infrastructure Knowledge

Practice Interview

Study Questions

Career Motivation and Role Alignment

Practice Interview

Study Questions

Background and Relevant Experience

Practice Interview

Study Questions

Phone Technical Screen - Coding and Algorithms

What to Expect

Tips & Advice

Focus Topics

Problem-Solving Approach and Communication

Practice Interview

Study Questions

Graph Algorithms and Tree Traversal

Practice Interview

Study Questions

Data Structures and Optimization

Practice Interview

Study Questions

Phone Technical Screen - Systems and Troubleshooting

What to Expect

Tips & Advice

Focus Topics

Monitoring and Observability Concepts

Practice Interview

Study Questions

Systematic Troubleshooting Methodology

Practice Interview

Study Questions

Linux Networking Fundamentals

Practice Interview

Study Questions

Linux Internals and Process Management

Practice Interview

Study Questions

Onsite Interview Round 1 - Coding

What to Expect

Tips & Advice

Focus Topics

Communication and Collaboration

Practice Interview

Study Questions

Optimization and Trade-Off Analysis

Practice Interview

Study Questions

Advanced Algorithm Patterns

Practice Interview

Study Questions

Onsite Interview Round 2 - System Design (NALSD)

What to Expect

Tips & Advice

Focus Topics

Technology Choices and Trade-Offs

Practice Interview

Study Questions

Reliability, Fault Tolerance, and Disaster Recovery

Practice Interview

Study Questions

SRE-Specific Operational Considerations

Practice Interview

Study Questions

Distributed System Fundamentals

Practice Interview

Study Questions

Scalability and Performance Architecture

Practice Interview

Study Questions

Onsite Interview Round 3 - Linux Internals and Infrastructure

What to Expect

Tips & Advice