Google Site Reliability Engineer Interview Questions (2026)

1. 1Recruiter screen30 minEasy

   Background, level calibration, and process walkthrough with a recruiter.

2. 2Technical phone screen45 minHard

   One or two DSA problems solved live in a shared editor with emphasis on optimal complexity and clean code.

3. 3Coding round (onsite)45 minHard

   Harder DSA with follow-up constraint changes; interviewer scores GCA and RRK on a rubric.

4. 4System design round45 minHard

   Design a planet-scale system (e.g. a piece of Search or YouTube) with explicit capacity estimates and tradeoffs.

5. 5Googleyness & Leadership45 minMedium

   Behavioral round on collaboration, ambiguity, and user-first judgment scored against Google's structured rubric.

6. 6Hiring Committee review30 minMedium

   No candidate interaction; the written feedback packet is reviewed and the hire/no-hire decision is made, followed by team matching.

1. Q1

   How would you prepare capacity for a known peak?

   Capacity PlanningGoogle-specific

   Context: Production scenario: Google expects a major traffic spike for global search ranking service during a launch, holiday, or media event.

   How to answer: A strong answer would first identify the known peak and its characteristics (e.g., duration, magnitude, historical data). Then, it would detail the process of forecasting demand, considering growth trends and historical peak multipliers. The candidate should discuss how to translate this forecast into resource requirements for all critical components and the strategy for acquiring or provisioning these resources, including lead times and buffer capacity. Finally, they should mention validation through load testing and a monitoring/rollback plan for the actual peak.

2. Q2

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

   Capacity PlanningGoogle-specific

   Context: Production scenario: Kubernetes clusters hosting multi-tenant Kubernetes platform powering user-facing products show low average utilization but frequent pod scheduling failures.

   How to answer: A strong answer would go beyond basic CPU/memory to discuss resource types like ephemeral storage (emptyDir, logs), network bandwidth (inter-pod, ingress/egress), and I/O operations (disk throughput/IOPS). It would also cover less obvious but critical resources such as API server QPS limits, etcd capacity, and node port availability. The candidate should mention considering burst capacity, workload-specific resource profiles (e.g., CPU-bound vs. I/O-bound), and the impact of system daemons (kubelet, containerd) on available resources. Finally, they should touch on using metrics, forecasting, and admission controllers to manage these diverse capacities.

3. Q3

   How would you plan and operate shard capacity?

   Capacity PlanningGoogle-specific

   Context: Production scenario: A shard for global search ranking service becomes hot while overall fleet utilization is moderate.

   How to answer: A strong answer would begin by defining sharding and its purpose in capacity planning. It would then detail the process of forecasting demand for each shard, considering both data growth and request load, and how to allocate resources (CPU, memory, storage, network I/O) per shard. The candidate should discuss strategies for dynamic rebalancing and hot shard detection, including automated tooling and manual intervention. Finally, they should cover operational aspects like monitoring shard health, utilization, and error rates, and planning for shard-level failures and disaster recovery.

4. Q4

   How would you triage the incident in the first 10 minutes and decide severity?

   Incident ManagementGoogle-specific

   Context: Production scenario: At Google, alerts fire for global search ranking service: p99 latency, saturation, error-rate, and brownout alerts, but dashboards disagree on whether users are impacted.

   How to answer: A strong candidate would immediately focus on establishing communication and gathering initial symptoms. This involves checking dashboards for red signals (e.g., latency, error rates, resource saturation), reviewing recent changes, and confirming user impact. Concurrently, they would attempt to reproduce the issue and identify the affected service or component. Severity would be determined based on user impact, blast radius, and business criticality, using a predefined rubric (e.g., P0 for critical user-facing outage, P1 for significant degradation).

5. Q5

   What should an effective incident update contain, and how often should it be sent?

   Incident ManagementGoogle-specific

   Context: Production scenario: An outage in global search ranking service affects external users and internal stakeholders are asking for updates every few minutes.

   How to answer: An effective incident update should succinctly convey the current status, impact, and next steps. Key elements include a clear incident ID, current severity, affected services/users, a brief summary of what's known, recent actions taken, and the immediate plan. It should also include a clear 'next update by' timestamp. Frequency depends on incident severity and progress, but a good rule of thumb is every 15-30 minutes for critical incidents, extending to hourly or less frequent for lower severity or slower-moving issues, always with a clear expectation for the next communication.

6. Q6

   How would you manage an incident caused by a dependency outage?

   Incident ManagementGoogle-specific

   Context: Production scenario: global search ranking service depends on an external or shared internal service that is degraded, and your team cannot fix that dependency directly.

   How to answer: A strong answer would emphasize immediate detection and verification of the dependency outage, followed by clear communication to stakeholders and the dependency provider. Concurrently, the team should focus on mitigation strategies like failover to a redundant dependency, caching stale data, or gracefully degrading functionality. Post-incident, the focus shifts to a thorough root cause analysis, improving monitoring, enhancing resilience patterns (e.g., circuit breakers, bulkheads), and strengthening vendor relationships and SLAs.

7. Q7

   How would you run a blameless postmortem that leads to meaningful reliability improvement?

   Incident ManagementGoogle-specific

   Context: Production scenario: Google's multi-tenant Kubernetes platform powering user-facing products had a 90-minute incident with multiple contributing causes and some human mistakes.

   How to answer: A blameless postmortem focuses on system and process failures, not individual blame. It starts with a detailed timeline of events, including detection, diagnosis, and resolution. Key steps involve identifying contributing factors (technical, human, process), determining root causes, and proposing concrete, actionable improvements with owners and deadlines. The output should be a shared document, communicated widely, with follow-up to ensure actions are completed and effective.

8. Q8

   How would you handle an incident where availability and data integrity are both at risk?

   Incident ManagementGoogle-specific

   Context: Production scenario: During global search ranking service recovery, engineers discover possible data corruption or duplicate writes.

   How to answer: Prioritize data integrity over availability, especially in a Google SRE context where data loss is often catastrophic. Immediately isolate the affected system or data to prevent further corruption, even if it means taking a service offline. Focus on understanding the scope of data corruption and developing a recovery plan, which might involve restoring from a known good backup. Only after data integrity is secured and validated should efforts shift to restoring availability, potentially with a degraded but safe service.

9. Q9

   How would you keep a war room effective as incident participation grows?

   Incident ManagementGoogle-specific

   Context: Production scenario: Twenty people join the incident bridge for global search ranking service, making debugging slower.

   How to answer: To keep a war room effective with growing participation, establish clear roles and responsibilities early, such as Incident Commander, Communications Lead, and Scribe, to manage information flow and decision-making. Implement a structured communication strategy, utilizing a primary communication channel for core updates and secondary channels for parallel investigations or deep dives, ensuring only critical information is shared broadly. Leverage tooling for real-time documentation, task tracking, and metric visualization to maintain a single source of truth and avoid redundant efforts. Regularly review and adapt the war room process through post-incident reviews to identify bottlenecks and improve efficiency for future incidents.

10. Q10

    How would you diagnose Kubernetes control-plane performance issues?

    KubernetesGoogle-specific

    Context: Production scenario: Deploys for global search ranking service slow down because Kubernetes API server latency and etcd commit latency spike.

    How to answer: A strong candidate would start by identifying the core components of the control plane: API Server, etcd, Controller Manager, and Scheduler. They would then describe how to monitor the health and performance of each component using Prometheus metrics and logs. Specific metrics like API server latencies, etcd request duration, and scheduler queue depth would be mentioned. Finally, they would discuss correlating these metrics with application-level symptoms and using tools like `kubectl get events` for initial triage.

11. Q11

    How would you troubleshoot Kubernetes pod networking and DNS issues?

    KubernetesGoogle-specific

    Context: Production scenario: Pods in one namespace cannot resolve or reach global search ranking service after a CNI upgrade.

    How to answer: A strong candidate would start by checking the pod's `kubectl describe pod` output for events and IP assignment, then inspect the pod's `resolv.conf` to verify correct `nameserver` and `search` entries. Next, they would use `kubectl exec` to run `ping` or `curl` to external services and other pods, and `nslookup` or `dig` to test DNS resolution from within the pod. If issues persist, they would investigate the CNI plugin status, CoreDNS logs (`kubectl logs -n kube-system -l k8s-app=kube-dns`), and network policies, escalating to node-level `ip route` and `iptables` checks if necessary.

12. Q12

    How would you operate batch jobs on a shared Kubernetes platform without harming user-facing services?

    KubernetesGoogle-specific

    Context: Production scenario: Kubernetes CronJobs for data processing related to multi-tenant Kubernetes platform powering user-facing products backlog and compete with online workloads.

    How to answer: A strong answer would focus on resource isolation and prioritization. Key strategies include using dedicated node pools for batch jobs, applying resource requests and limits effectively, and implementing Pod priority and preemption. Additionally, network policies and careful use of Kubernetes QoS classes (e.g., `Burstable` or `BestEffort` for batch) are crucial. Monitoring resource utilization and setting up alerts for potential contention complete the operational picture.

13. Q13

    Walk through how you would debug this Linux host issue from first alert to mitigation

    LinuxGoogle-specific

    Context: Production scenario: At Google, global search ranking service shows a sudden p99 latency spike while CPU user time is normal but softirq and system time rise on a subset of Linux hosts running dense containerized workloads.

    How to answer: A strong candidate would start by identifying the alert type and scope, then use `journalctl` or `dmesg` to check recent system logs for errors. Next, they would use `top`, `htop`, or `` to identify resource bottlenecks (CPU, memory, disk I/O, network). Based on the bottleneck, they would drill down with tools like `iostat`, `vmstat`, `netstat`, or `lsof` to pinpoint the specific process or resource contention. Finally, they would propose a mitigation strategy, such as restarting a service, killing an errant process, or escalating to a specialized team, while also considering root cause analysis for a permanent fix.

14. Q14

    Which kernel and application backlog settings would you inspect, and how would you tune them safely?

    LinuxGoogle-specific

    Context: Production scenario: Google's global front-end load balancers and regional backends sees connection timeouts after traffic doubles, and SYN backlog plus listen queue drops rise on Linux hosts.

    How to answer: A strong candidate would identify `net.core.somaxconn` (system-wide maximum backlog) and `net.ipv4.tcp_max_syn_backlog` (SYN queue size) as key kernel settings. For applications, they'd look at the `listen()` backlog argument. Tuning involves increasing these values incrementally, starting with `somaxconn` and the application's `listen()` backlog, then `tcp_max_syn_backlog` if SYN floods are suspected. Monitoring `netstat -s` (listen overflows) and application logs is crucial for safe, iterative adjustments.

15. Q15

    What does uninterruptible sleep mean, and how would you handle this host during an incident?

    LinuxGoogle-specific

    Context: Production scenario: A critical process on multi-tenant Kubernetes platform powering user-facing products stops responding; strace hangs, restart does not complete, and ps shows D state.

    How to answer: Uninterruptible sleep (D state) means a process is waiting for a low-level I/O operation to complete and cannot be killed or interrupted by signals. This often indicates a problem with underlying hardware (disk, network, HBA) or a kernel driver bug. During an incident, the primary goal is to identify the root cause by checking system logs (dmesg, journalctl), I/O statistics (iostat, vmstat), and hardware health. If the issue persists and impacts critical services, a controlled reboot is often the only immediate resolution, followed by deeper investigation post-mortem.

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

Master DSA and communicate your thinking out loud; use Google's structured Explain-Clarify-Improve approach; prepare for Googleyness/behavioral

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

Other roles at Google

Site Reliability Engineer interviews at other companies