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 build a capacity forecast for this service?

   Capacity PlanningGoogle-specific

   Context: Production scenario: global search ranking service traffic is growing steadily and leadership asks when capacity will become unsafe.

   How to answer: A strong capacity forecast begins by identifying key resource metrics (CPU, memory, disk I/O, network bandwidth, QPS) and their current utilization patterns. Next, historical data for these metrics is collected and analyzed, looking for trends, seasonality, and growth rates. Future demand is then projected using statistical models like ARIMA, Prophet, or simple linear regression, incorporating business drivers and product roadmap changes. Finally, the forecast is validated against actual usage, refined iteratively, and used to drive procurement or scaling decisions, often with buffer capacity.

2. Q2

   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.

3. Q3

   How would you identify the true capacity bottleneck?

   Capacity PlanningGoogle-specific

   Context: Production scenario: global search ranking service scales unevenly: CPU is fine, but database connections, network egress, or disk IOPS saturate first.

   How to answer: Start by defining capacity and identifying key metrics for the service (e.g., QPS, latency, resource utilization). Implement load testing and stress testing methodologies, gradually increasing load until performance degrades or resources saturate. Analyze monitoring data (CPU, memory, network I/O, disk I/O, database connections) during these tests to pinpoint the first resource to hit its limit. Validate the bottleneck by attempting to scale that specific resource and observing if the overall capacity increases proportionally.

4. Q4

   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.

5. Q5

   How would you decide where capacity can be safely reduced?

   Capacity PlanningGoogle-specific

   Context: Production scenario: Finance asks Google to reduce infrastructure spend for global search ranking service without violating SLOs.

   How to answer: A strong candidate would first emphasize data-driven analysis, focusing on historical utilization patterns (CPU, memory, network, disk I/O) and identifying peak vs. average usage. They would then discuss the importance of understanding service-level objectives (SLOs) and error budgets, ensuring that any reduction doesn't compromise reliability targets. Next, they would propose identifying non-critical services or environments (e.g., staging, dev, low-priority batch jobs) as initial candidates. Finally, they would detail a phased rollout strategy with robust monitoring and rollback capabilities to validate the impact of reductions.

6. Q6

   How would you define healthy headroom for normal and failure conditions?

   Capacity PlanningGoogle-specific

   Context: Production scenario: global search ranking service runs at 65% CPU most days but incidents occur when a zone fails and traffic shifts.

   How to answer: Healthy headroom is the excess capacity a system maintains to handle anticipated load increases and unexpected events without performance degradation or outages. For normal conditions, this typically involves a buffer (e.g., 20-30%) above peak historical load, accounting for organic growth and minor spikes. For failure conditions, it means having enough surplus capacity to absorb the loss of one or more critical components (e.g., a zone, a cluster, or a significant number of machines) while still serving traffic at acceptable SLOs. This often requires N+1 or N+M redundancy planning, where 'N' is the minimum required capacity and 'M' is the additional capacity for failure tolerance.

7. Q7

   How would you design a realistic load test?

   Capacity PlanningGoogle-specific

   Context: Production scenario: A new version of global search ranking service needs capacity validation before millions of QPS across several regions.

   How to answer: A realistic load test requires defining clear objectives and identifying critical user journeys and their associated traffic patterns, including peak loads and growth projections. It's crucial to simulate realistic user behavior, including think times, varying request types, and data diversity, rather than just raw requests per second. The test environment must closely mirror production in terms of hardware, software, and network configuration. Finally, robust monitoring of both the system under test and the load generators is essential to identify bottlenecks and validate results, followed by iterative refinement based on findings.

8. Q8

   How would you plan regional capacity and traffic shifting?

   Capacity PlanningGoogle-specific

   Context: Production scenario: large-scale multi-region service mesh must serve traffic even if one region or edge location fails.

   How to answer: A strong answer would begin by outlining the need for a multi-region strategy for resilience and performance, then detail the process of forecasting demand per region based on user distribution and service growth. It would cover capacity allocation, considering buffer capacity, hardware lifecycle, and regional dependencies. The candidate should then discuss traffic shifting mechanisms, including DNS-based routing (e.g., GSLB), application-layer routing, and the importance of gradual, canary-style shifts with robust monitoring and rollback procedures. Finally, it would touch upon disaster recovery scenarios and regular capacity drills to validate the plan.

9. Q9

   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.

10. Q10

    How would you capacity-plan connection pools and downstream concurrency?

    Capacity PlanningGoogle-specific

    Context: Production scenario: global search ranking service has enough compute, but database connection limits are exhausted during spikes.

    How to answer: Capacity planning for connection pools involves understanding the application's request rate, average request latency, and the downstream service's QPS limits and latency characteristics. Key metrics include concurrent connections needed, average connection lifetime, and peak connection demand. It's crucial to consider the impact of retries and timeouts, as these can significantly inflate effective concurrency. The goal is to size the pool to handle peak load efficiently without overwhelming the downstream service or introducing excessive queuing.

11. Q11

    How would you plan cache capacity and eviction policy?

    Capacity PlanningGoogle-specific

    Context: Production scenario: Cache eviction rate for global search ranking service rises, causing origin saturation and higher latency.

    How to answer: A strong answer outlines a data-driven approach, starting with identifying key metrics like QPS, latency, and cache hit ratio. It then details how to estimate cache size based on object size distribution, access patterns (e.g., Zipfian), and desired hit ratio, often using historical data and load testing. For eviction, it discusses common policies (LRU, LFU, FIFO, ARC) and how to select one based on workload characteristics (e.g., LRU for temporal locality, LFU for frequency). Finally, it emphasizes continuous monitoring, iterative refinement, and considering cache-specific failure modes.

12. Q12

    How would you calculate whether the system can drain backlog before violating freshness targets?

    Capacity PlanningGoogle-specific

    Context: Production scenario: multi-tenant Kubernetes platform powering user-facing products accumulates a large queue backlog during a partial outage.

    How to answer: To calculate backlog drain, first quantify the current backlog size (items/bytes/time). Next, determine the system's current processing rate (items/second or bytes/second) and the rate at which new backlog is being generated. Calculate the net drain rate by subtracting the generation rate from the processing rate. Finally, compare the time required to drain the existing backlog at the net drain rate against the freshness target deadline, considering any potential for increased processing capacity or reduced generation during the drain period.

13. Q13

    How would you capacity-plan edge or CDN infrastructure?

    Capacity PlanningGoogle-specific

    Context: Production scenario: global front-end load balancers and regional backends must absorb a sudden regional traffic shift while keeping global search ranking service latency low.

    How to answer: A strong capacity plan for edge/CDN infrastructure starts with understanding traffic patterns, including peak loads, geographic distribution, and content types. Key metrics like requests per second (RPS), bandwidth (Gbps), and connection counts (CPS/concurrent) are essential. The plan must account for redundancy, failover scenarios, and a safety margin (e.g., N+1, N+2, or percentage buffer) to handle unexpected spikes or outages. Finally, it requires a feedback loop of continuous monitoring, forecasting, and regular adjustment based on actual usage and projected growth.

14. Q14

    How would you capacity-plan bandwidth and protect critical traffic?

    Capacity PlanningGoogle-specific

    Context: Production scenario: Replication, logs, and customer traffic share network links for global search ranking service.

    How to answer: A strong answer would start by defining critical traffic and identifying its characteristics (e.g., low latency, high availability). It would then detail a multi-pronged capacity planning approach, including historical data analysis, forecasting (growth, peak events), and stress testing. Protection mechanisms would involve traffic prioritization (QoS, separate networks), admission control, and dynamic scaling strategies. Finally, the answer should emphasize continuous monitoring, alerting, and regular review cycles to adapt to changing demands.

15. Q15

    How would you plan storage capacity and retention?

    Capacity PlanningGoogle-specific

    Context: Production scenario: Storage for global search ranking service grows faster than forecast because retention and indexing changed.

    How to answer: A strong answer outlines a data-driven approach, starting with identifying critical metrics like current usage, growth rate (daily/weekly/monthly), and data types. It then details forecasting methodologies (e.g., linear regression, exponential smoothing) considering business growth and new feature launches. Retention policies, including legal/compliance requirements, data aging, and tiered storage strategies, are crucial. Finally, the plan must include regular review cycles, alerting for thresholds, and a buffer for unexpected spikes.

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