What You'll Learn
Before You Read This
You are 5+ years into your career and interviewing for a Senior or Staff SRE role. The bar shifts from "can you operate a system" to "can you design, defend, and own the reliability of a system under real business constraints." Interviewers expect you to state SLOs before drawing diagrams, quantify blast radius before proposing a fix, and defend trade-offs under pushback. Tier 1 is your readiness gate. Tier 2 is 24 fully-answered senior-level questions. Tier 3 is 10 live production scenarios with no single correct answer. The Behavioral Round is 15 STAR-format questions on incident ownership, technical leadership, and cross-team conflict.
Tier 1 - Senior Fundamentals Checklist
No answers given below. If you cannot answer these cold across Linux, Kubernetes, distributed systems, databases, SRE practice, networking, and observability, study first before moving to Tier 2. * What is the difference between TIME_WAIT and CLOSE_WAIT, and which side of a connection enters each? * What does a process's oom_score represent and how is it calculated? * What is the difference between a process's soft and hard ulimit? * How does the CFS scheduler decide which process runs next? * What is CPU steal time and when does it matter? * What is the difference between cgroups v1 and v2? * What does /proc/<pid>/status show that ps aux does not? * What is a zombie process and how do you actually clear one? * What is the SYN queue versus the accept queue? * What does iostat's util column actually measure? * What is head-of-line blocking and how does HTTP/2 partially fix it? * What is deadline propagation and why does a per-hop timeout not achieve the same thing? * What is the difference between a liveness and a readiness probe? * What happens inside the kernel when resources.limits.memory is set on a pod? * Why can a pod be OOMKilled while the host has free RAM? * What is the difference between PodFailure and PodKill in a chaos testing context? * What causes a PVC to be stuck Pending after a node failure? * What does kube-proxy actually do, and how does its behavior differ between iptables and IPVS mode? * Why does a gRPC service need a dedicated probe type instead of a TCP probe? * State the CAP theorem in one sentence without naming a specific database. * What is split-brain and how does Raft's majority-vote rule prevent it? * Why does a 5-node cluster tolerate the loss of only 2 nodes, not more? * What is the difference between full jitter and equal jitter in retry backoff? * What is a bulkhead pattern and what specific failure does it prevent? * Why is "timeout" not the same as "confirmed failure" for a retried operation? * What does an idempotency key actually protect against? * What does PostgreSQL's WAL underlie besides crash recovery? * What is transaction ID wraparound and why is it a hard stop, not a warning? * What is the difference between PgBouncer's session, transaction, and statement pool modes? * Why can a database show near-zero CPU while every request times out? * What is the difference between RDB and AOF persistence in Redis? * When should you choose Redis Cluster over Redis Sentinel? * What two things does point-in-time recovery actually require? * What are the six defining characteristics of toil? * Why should a team's toil target never be set to exactly 0%? * What is the toil-elimination decision tree, in order? * What is the difference between an SLI, an SLO, and an error budget? * Why should DORA metric improvement be described as something that "can" happen, not something that automatically does? * What is the USE Method and what three things does it check per resource? * What is a blast radius and why should a first chaos experiment minimize it? * What does EADDRNOTAVAIL on an outbound connection almost always indicate? * Why does lowering a DNS TTL before a migration not by itself speed up propagation? * What is a DNS cache stampede? * What does a certificate's notAfter expiry cause, versus a gradual warning? * What is the difference between a SYN queue overflow and an accept queue overflow? * What does net.core.somaxconn control, and why can raising it alone do nothing? * What are the four Golden Signals? * Why is "the SLO held" not sufficient to call a chaos experiment fully successful? * What is the difference between Detection, Resilience, and Recovery in a chaos experiment? * Why should incident response usually not be automatically classified as toil? * What should a toil-reduction report include beyond the percentage reduction alone?
Tier 2 - Real Interview Questions (Q1-Q15)
Q1. Designing an SLO for a Checkout API With No Existing Target The Prompt Design an SLO for a checkout API that currently has none. Walk through your reasoning. Clarifying Questions A strong candidate asks what "checkout" means end to end, whether latency or availability matters more to the business, and what current error rates look like before proposing a number. The Ideal Solution Start with the SLI, not the target: percentage of checkout requests completing under 800ms with a non-error status, since that is what a user actually experiences, rather than a raw uptime metric nobody can act on. SLI: % of checkout requests < 800ms, non-error SLO: 99.9% over a rolling 28-day window Budget: ~43 min of full-downtime-equivalent / 28 days Policy: 50% burned in any 7-day window -> deploy freeze on checkout-adjacent services Set the target based on real business tolerance, not a round number. State it explicitly: "99.9%, not 99.99%, because the cost of chasing the next nine is exponential and the business can tolerate a small, bounded rate of failed checkouts more than it can tolerate the engineering cost of near-perfect availability." > 💡 Green Flag: the candidate names the error budget policy - what happens when it burns - before being asked, and closes on the rate of change of budget burn rather than just the fixed threshold, since a small but climbing burn rate is a much earlier signal. > 🔴 Red Flag: proposing 99.99% by default without asking what the business actually tolerates, or defining a target with no stated consequence for breaching it. Q2. Diagnosing a Healthy-Looking Service Returning 503s The Prompt A service is "active (running)" per systemctl, CPU and memory look fine, but it's returning 503s. What's your first hypothesis and how do you confirm it? The Ideal Solution File descriptor exhaustion in an upstream dependency, not the service itself, is the leading hypothesis. Confirm with ls /proc/<pid>/fd | wc -l against /proc/<pid>/limits. bash Compare open FDs against the process's own limit ls /proc/<pid>/fd | wc -l cat /proc/<pid>/limits | grep "open files" When a process hits its FD ceiling, every new socket call fails including accept() on new connections, while the process stays alive and every basic health signal stays green - this is exactly why systemctl status and top can both report healthy while the service is functionally down. > ⚠️ Warning: do not stop at "the process is running" as a health confirmation. A process can be alive and structurally unable to accept new work at the same time. Q3. Explaining an OOMKill With Free Host Memory The Prompt Explain why a pod can be OOMKilled while free -h on the host shows gigabytes free. The Ideal Solution Kubernetes writes the pod's memory limit into its own cgroup (memory.max in v2, memory.limit_in_bytes in v1). When usage crosses that number, the kernel's OOM killer fires inside that specific cgroup, killing the largest process in it, entirely independent of host-wide memory state. bash Check the pod's actual cgroup memory ceiling, not the host's overall memory state cat /sys/fs/cgroup/memory.max The fix is raising the pod's own memory limit in its resource spec, never adding RAM to the node or tuning host-level swappiness - neither touches the actual enforcement boundary. Q4. Round Robin vs Least-Connections Under Uneven Load The Prompt Round robin load balancing sends a new request to a pod already processing a 10-second report query. What's the failure mode, and does switching to least-connections fully fix it? The Ideal Solution Round robin is blind to current load - it sends work in strict rotation regardless of how busy a backend already is. Least-connections improves this but is not a full fix: "fewest connections" is not the same as "least busy." A pod with 2 connections each stuck in a 30-second query can look less loaded than a pod with 50 connections serving 5ms cache reads, and least-connections can therefore keep routing more traffic toward the pod that is actually struggling. > 📌 Remember: the fully correct answer names a latency-aware or outlier-detection-based balancing strategy as the actual fix, not just "least-connections is better than round robin." Q5. Diagnosing Quorum Loss in a Partitioned etcd Cluster The Prompt A 5-node etcd cluster splits into groups of 2, 2, and 1 during a network partition. What happens, and why? The Ideal Solution No group has a majority - a majority of 5 requires 3. All three groups stop accepting writes, even though every individual node is technically still alive. 5 nodes -> partition -> [2] [2] [1] majority needed = 3 no group has 3 -> no leader anywhere -> all writes halt This is Raft correctly protecting against split-brain: quorum loss is not only about nodes crashing, a pure network partition can strand every node "up" while leaving no side with enough votes to safely elect a leader. Q6. Timeout Is Not Failure: Retry Safety The Prompt Why is "the request timed out" not the same as "the request failed," and why does this distinction matter for retry safety? The Ideal Solution A timeout means no response was received in time - it says nothing about whether the operation completed server-side. The original write may have succeeded and only the response was lost. Retrying a non-idempotent operation under this assumption, such as a payment charge, can produce a duplicate side effect. > ⚠️ Warning: never present a retry-on-timeout policy without an idempotency key or equivalent guard. This is the single most common gap that fails a senior SRE candidate on this question. This is why every retry pattern in production assumes idempotency as a precondition, not an optional nicety. Q7. The Cost of Disabling Autovacuum During a Bulk Import The Prompt A team disables autovacuum "temporarily" during a bulk import to improve write throughput. What risk does this introduce, and how would you monitor for it? The Ideal Solution Transaction ID wraparound. PostgreSQL identifies every transaction with a 32-bit ID that can wrap after roughly 2 billion transactions; autovacuum is what keeps the oldest unfrozen transaction ID (datfrozenxid) bounded. sql -- Monitor how close a database is to forced shutdown SELECT datname, age(datfrozenxid) AS xid_age FROM pg_database ORDER BY xid_age DESC; Left disabled long enough, the database eventually refuses all new writes as a last-resort protection against silent data corruption - not a bug, but the database protecting itself. Alert well before the ~200 million warning threshold, since the real failure already happened when autovacuum was disabled, not when the hard stop triggers. Q8. The Invisible Bottleneck: Connection Pool Exhaustion The Prompt Every dashboard - database CPU, memory, disk - looks calm, but the application is timing out on every request to the database. What do you check that isn't on those dashboards? The Ideal Solution Connection pool utilization, specifically PgBouncer or equivalent sitting in front of PostgreSQL. A slow downstream call can hold connections open longer than usual, filling the pool's fixed slot count while PostgreSQL itself sits idle with plenty of spare capacity it was simply never asked to use. > 🔴 Red Flag: spending the first 20 minutes staring at DB CPU graphs instead of checking the pool - precisely because every standard database dashboard looks completely normal during a pool exhaustion event. Q9. Why a First Chaos Experiment Should Minimize Blast Radius The Prompt Why should a first chaos experiment always target the smallest blast radius in the lowest-risk environment? The Ideal Solution To validate the tooling, the rollback process, and the team's understanding of the steady-state hypothesis before any real user impact is possible. staging, 1 pod -> staging, wider radius -> production, 1 pod -> production, wider radius Progression should move from staging to production and from a single pod to a wider blast radius - never both changes at once - so that a mistake in either the experiment design or the tooling itself is caught cheaply rather than during a production-wide test. Q10. Staging Automation Is Not a Substitute for a Game Day The Prompt A team's staging chaos automation has run cleanly for weeks with tested abort conditions, but they've never run a Game Day. Should they move straight to continuous production chaos? The Ideal Solution No. Staging automation proves the system-side tooling works; a Game Day proves the human-side incident response process works - whether the incident commander structure, runbooks, and communication cadence actually function under a live scenario. Skipping that stage removes the operational muscle needed to safely run automated production chaos, risking real incidents instead of controlled learning. Q11. Ephemeral Port Exhaustion From Per-Request Connections The Prompt A Node.js service opens a fresh outbound connection per request. Under load, new outbound calls start failing with EADDRNOTAVAIL. Diagnose it. The Ideal Solution Ephemeral port exhaustion from connections stuck in TIME_WAIT. Each short-lived connection consumes a unique local source port, which sits unusable for roughly 60 seconds after close. bash Count sockets currently stuck in TIME_WAIT ss -tan state time-wait | wc -l At a high enough request rate, the ~28,000-port default range fills faster than TIME_WAIT drains it, leaving the kernel with no local port to assign for a new outbound connection. The durable fix is connection pooling at the application layer, not just widening the ephemeral port range or enabling tcp_tw_reuse, both of which only buy headroom rather than removing the cause. Q12. CoreDNS CPU Pressure Masquerading as a Downstream Outage The Prompt CoreDNS pods are near their CPU limit during a traffic surge, and application latency spikes even though every downstream service reports healthy. Explain the connection. The Ideal Solution A DNS lookup taking seconds instead of milliseconds under CoreDNS CPU throttling looks, from the calling application's point of view, identical to a slow downstream dependency - because the delay happens before the request even reaches any actual downstream service. Since every real downstream reports healthy, the bottleneck has to be introduced earlier in the path, at name resolution, which is exactly what CoreDNS CPU pressure produces. Q13. Why Raising somaxconn Alone Can Do Nothing The Prompt Why can raising net.core.somaxconn alone fail to fix connection timeouts under load? The Ideal Solution The kernel uses the smaller of two values: the application's own listen() backlog argument and the kernel-level somaxconn setting. If the application framework still passes a low backlog (many default to 128), raising only the sysctl value changes nothing, because the smaller application-level number remains the binding constraint on accept queue depth. > 📌 Remember: always ask what backlog value the application itself is passing before recommending a sysctl change. This is the detail that separates a correct answer from a half-correct one. Q14. Full Jitter vs Equal Jitter in Retry Backoff The Prompt What is the difference between full jitter and equal jitter in retry backoff, and why does it matter at scale? The Ideal Solution Equal jitter still guarantees a minimum wait time by only randomizing half the delay, which under a thundering-herd scenario can leave enough synchronization that retries still cluster. Full jitter randomizes the entire delay range from zero to the computed backoff, which spreads retries far more evenly and is the stronger default for any service recovering from a shared outage. Q15. The Bulkhead Pattern and Idempotency Keys The Prompt What is a bulkhead pattern, and what specific failure does it prevent? What does an idempotency key actually protect against? The Ideal Solution A bulkhead isolates resource pools (thread pools, connection pools) per dependency, so a single slow or failing downstream cannot exhaust the resources every other call path also depends on. Without it, one misbehaving dependency can starve unrelated request paths of the same shared thread pool, turning a single-dependency failure into a total outage. An idempotency key protects against duplicate side effects from a retried non-idempotent operation - the server can recognize a repeated request carrying the same key and return the original result instead of re-executing the operation, which matters most for anything with a real-world effect like a payment charge or an inventory decrement.
Tier 2 - Real Interview Questions (Q16-Q24)
Q16. PgBouncer Pool Modes The Prompt What is the difference between PgBouncer's session, transaction, and statement pool modes? The Ideal Solution Session mode holds a backend connection for the client's entire session, which is safest but scales worst. Transaction mode releases the backend connection back to the pool after each transaction, which is the common production default and scales well but breaks session-level features like advisory locks or SET statements that must persist across transactions. Statement mode releases after every single statement and is the most aggressive, but is incompatible with multi-statement transactions entirely. Q17. Redis Persistence and Cluster vs Sentinel The Prompt What is the difference between RDB and AOF persistence in Redis, and when would you choose Redis Cluster over Sentinel? The Ideal Solution RDB takes point-in-time snapshots, which is fast to restore from but can lose the last few minutes of writes on a crash. AOF logs every write operation and can be replayed for near-zero data loss, at the cost of a larger file and slower restart. Choose Redis Cluster when you need horizontal sharding across nodes for capacity beyond a single instance; choose Sentinel when a single dataset fits on one primary and you only need automated failover, not sharding. > 🔴 Common Mistake: recommending Redis Cluster purely for high availability when Sentinel alone would satisfy the requirement - Cluster adds sharding complexity that is only justified by an actual capacity need. Q18. USE Method vs the Four Golden Signals The Prompt What is the difference between the USE Method and the four Golden Signals? The Ideal Solution The USE Method (Utilization, Saturation, Errors) is resource-centric - applied per resource like CPU, disk, or network, useful for infrastructure-level triage. The four Golden Signals (latency, traffic, errors, saturation) are service-centric - applied per user-facing service, useful for SLO-level triage. A senior engineer reaches for USE when diagnosing a specific host or resource, and Golden Signals when diagnosing a specific service's user-facing health. Q19. Why Certificate Expiry Should Never Be Purely Reactive The Prompt How do you decide when a certificate expiry incident should have been prevented versus reacted to? The Ideal Solution A certificate's notAfter expiry causes a hard failure with no gradual warning - TLS handshakes simply start failing the instant the clock crosses that timestamp, unlike a slowly degrading resource. This is why cert expiry should never be purely a reactive incident: it is fully predictable in advance, so the correct posture is automated renewal (ACME-style) plus an alert firing weeks ahead of expiry, not a runbook for handling the outage after it happens. Q20. SYN Queue Overflow vs Accept Queue Overflow The Prompt What is the difference between a SYN queue overflow and an accept queue overflow? The Ideal Solution The SYN queue holds half-open connections during the TCP handshake before the final ACK; overflow here typically indicates a SYN flood or handshake-layer problem. The accept queue holds fully-established connections waiting for the application to call accept(); overflow here means the application itself is too slow to pull new connections off the queue, which is an application-layer bottleneck, not a network-layer one. Q21. Why Incident Response Should Not Be Automatically Classified as Toil The Prompt Why should incident response usually not be automatically classified as toil? The Ideal Solution Toil is repetitive, automatable, and lacks enduring value - but incident response, even when repetitive in structure, generates the diagnostic knowledge and postmortem action items that reduce future incidents. Classifying every incident response hour as pure toil risks under-investing in the judgment-heavy parts of on-call that automation cannot yet replace, and conflates "this is tiring" with "this has no lasting value." Q22. Detection, Resilience, and Recovery in a Chaos Experiment The Prompt A chaos experiment kills a pod, the SLO holds, but no alert fired and nobody noticed. Was the experiment successful? The Ideal Solution No - or at least, not fully. This is exactly why chaos experiments validate three separate categories: Resilience (did the SLO hold), Detection (did monitoring notice), and Recovery (did the system self-heal or need a runbook). The system was resilient here, but the silent failure of detection is the more valuable finding - a real-world version of this failure, possibly worse, could have gone completely unnoticed. > 🔴 Red Flag: calling this experiment a "pass" because the SLO held, without flagging the missing alert. Q23. The Toil-Elimination Decision Tree The Prompt What is the toil-elimination decision tree, in order, and why should a team's toil target never be set to exactly 0%? The Ideal Solution Root cause fix first (why is the pod crash-looping at all), then rejecting or reducing the demand, then a self-service option that removes the need for a human, then automation, then human-in-the-loop with measurement. Automation is deliberately the fourth or fifth option, not the first, because it introduces a new system that itself needs monitoring and maintenance. A toil target of 0% ignores the structural floor any on-call rotation creates. A six-person rotation running one primary and one secondary week per cycle already has roughly a 33% floor before any additional toil is counted - setting a 0% target chases a number that was never reachable. Q24. Why DORA Metric Improvement Is Not Automatic The Prompt Why should DORA metric improvement be described as something that "can" happen, not something that automatically does? The Ideal Solution Adopting a practice associated with high-performing teams (trunk-based development, feature flags, smaller batch sizes) creates the conditions for better DORA metrics, but the metrics themselves only move if the team's actual behavior changes and the underlying bottleneck the practice was meant to address was the real constraint. Claiming automatic improvement overstates causation - a team can adopt the practice on paper and see no change if the real bottleneck was elsewhere, such as a slow, manual approval step the new practice never touched.
Tier 3 - Scenario Round
Scenario 1: The 3 AM Timeout Mystery The Prompt It's 3 AM. API pods are healthy, CPU is calm, memory is fine. Every request still times out. The database answers SELECT 1 in milliseconds. Walk through your first ten minutes. Clarifying Questions A strong candidate asks whether reads are served from a replica, whether any migration or bulk job ran recently, and whether the timeout is uniform across all endpoints or isolated to a subset. The Ideal Solution Do not trust the surface-level health signals - a database that answers a trivial query fast can still be functionally unreachable for real traffic. Check connection pool utilization first, since pool exhaustion produces exactly this signature: the bottleneck sits in a layer no standard database dashboard reports on. In parallel, check replication lag if reads are being served from a replica, and check for a stuck autovacuum or a long-running transaction holding locks that block everything behind it. Communicate early that the database itself is not yet ruled in or out - premature certainty here wastes the most time. Scenario 2: The Automation Shortcut The Prompt You are asked to reduce a service's toil by automating a recurring pod-restart task. The team wants to skip straight to writing a self-healing operator. What do you push back with? The Ideal Solution Walk the toil-elimination decision tree in order before reaching for automation: can the root cause be fixed, can the request simply be rejected or reduced, is there a self-service option that removes the need for a human without adding a new automated system to maintain. Automation is deliberately the fourth or fifth option, not the first - if the actual root cause (say, a memory limit set too low) can simply be fixed, that is stronger leverage than automating around it. Scenario 3: The Too-Perfect Operator The Prompt A self-healing operator you inherited restarts every CrashLoopBackOff pod with a 100% success rate and zero escalations, ever. Is this a good sign? The Ideal Solution No - it is a red flag that classification is too permissive. An operator restarting blindly without checking the termination reason can mask a genuine root cause, such as a bad image or a missing secret, behind a loop of "successful" but pointless restarts while user impact never actually goes away. > 🔴 Red Flag: taking "100% success rate" at face value without asking what "success" is actually measuring. Scenario 4: iowait vs Disk Saturation The Prompt During a live incident, you see iostat -x showing 85% util and climbing await on one disk, while top shows only 20% iowait. A colleague says "iowait is low, so it's not the disk." How do you respond? The Ideal Solution iowait only accumulates when the CPU has nothing else to run and is specifically waiting on I/O - if other processes keep the CPU busy, iowait can stay low even while the disk itself is genuinely saturated. util is the actual disk saturation signal, and combined with climbing await, 85% util is real evidence regardless of what iowait reports. Redirect the investigation to the disk, not away from it. Scenario 5: The Stale kube-proxy Rule The Prompt A pod cannot reach a Kubernetes Service, but kubectl get endpoints shows a healthy, populated list. What's your next step, and why not just restart the pod? The Ideal Solution Confirm kube-proxy itself is healthy and has synced recently, then inspect the actual NAT rule or IPVS entry it wrote for that specific Service. A Service IP is virtual - nothing listens on it directly, so a stale or missing kernel-level rule means kube-proxy hasn't synced correctly even though the Kubernetes API object looks correct. Restarting the destination pod doesn't touch that rule, so the same failure would likely recur. Scenario 6: The Monolith Migration The Prompt Your team is migrating a monolith with no containerization history onto Kubernetes. What's the single biggest risk you'd surface before writing a single Dockerfile? The Ideal Solution Stateful local files and in-memory session state. Containers are ephemeral by design - if the monolith writes logs, uploads, or session data to local disk or process memory, all of that disappears on restart or when traffic is split across multiple replicas. mermaid flowchart LR A[Monolith: local disk logs] --> B{Containerize as-is?} B -->|Yes| C[Logs lost on restart] B -->|No: fix first| D[Logs to stdout] D --> E[Uploads to object storage] E --> F[Sessions to shared Redis] F --> G[Safe to containerize] Move logs to stdout, uploads to object storage, and sessions to a shared store like Redis before attempting the container-to-Kubernetes move, and decouple containerization from the Kubernetes migration itself rather than doing both at once. Scenario 7: The DNS Stampede The Prompt A short-TTL DNS record for a payments database causes a synchronized burst of client failures every time it expires under peak load, even though the database never went down. Diagnose and fix. The Ideal Solution A DNS cache stampede - many clients' cached entries expire in the same narrow window and hit the resolver simultaneously, and if the resolver has even a brief hiccup at that exact moment, all of them fail together in a pattern that looks identical to a backend outage. The fix is not raising database capacity, which does nothing for a DNS-layer event; it's addressing resolver capacity or staggering TTL expiry so lookups don't cluster into synchronized waves. Scenario 8: The tcp_tw_recycle Trap The Prompt You need to permanently resolve TIME_WAIT-driven port exhaustion on an outbound-heavy service. A teammate suggests enabling tcp_tw_recycle. Why is that the wrong answer, and what is? The Ideal Solution tcp_tw_recycle was removed from modern kernels because it breaks connections from clients behind NAT, silently rejecting legitimate users who share a public IP. Kernel-level mitigations like tcp_tw_reuse or a wider ephemeral port range buy headroom but don't stop the service from opening one connection per request in the first place. The actual fix is connection pooling at the application layer, removing the root cause instead of tolerating the symptom. Scenario 9: The Zone-Pinned Volume The Prompt A pod is stuck Pending after a node failure, and the on-call engineer is checking resource requests and taints. What are they missing? The Ideal Solution A PersistentVolume is frequently pinned to a specific availability zone because the underlying block storage physically lives there. If the pod is rescheduled to a node in a different zone, Kubernetes cannot attach a zone-A volume to a zone-B node, and the pod stays Pending for a reason that isn't obvious from pod events alone. bash Confirm the PV's actual zone before spending more time on generic scheduling checks kubectl get pv <name> -o jsonpath='{.spec.nodeAffinity}' Scenario 10: The Toil Report The Prompt Leadership asks for a report on a toil-reduction automation project that cut a task from 15 minutes to 30 seconds across 12 incidents a month - a 96.7% reduction. What do you include beyond the percentage? The Ideal Solution Baseline toil, residual human review time, and the escalation rate together, not the percentage in isolation. A high reduction paired with a healthy, nonzero escalation rate is a genuine win; the same percentage with zero escalations ever is worth re-auditing rather than celebrating, since it can indicate the automation's classification logic is too permissive and is silently absorbing cases it shouldn't.
Behavioral Round
Q1. Tell me about an incident you handled that went badly. What did you change afterward? Strong Answer Framework: Use STAR and close on a durable, verifiable change - not "we were more careful after that." Example shape: a migration caused a 40-minute checkout outage from underestimated lock contention; you made the call to roll back rather than ride it out; afterward you wrote a pre-migration checklist requiring a lock-duration estimate on any migration touching a large table, used on 30+ migrations since with zero repeat incidents of that type. Q2. Describe a time you disagreed with a technical decision a more senior engineer had already made. Strong Answer Framework: State your disagreement once, clearly and with specific technical reasoning, then commit fully to executing the decision if it stands. Half-hearted execution after losing a disagreement is the outcome interviewers are screening against. Q3. Tell me about a time you owned a system nobody else understood well. Strong Answer Framework: Focus on how you built understanding safely - reading logs and configs first, documenting as you went, avoiding changes until you had a real mental model - rather than jumping straight into "improvements" on a system whose failure modes you didn't yet understand. Q4. How do you decide what to automate versus what to leave manual? Strong Answer Framework: Reference the decision tree: root-cause fix first, then rejection or batching of low-value requests, then self-service, then automation, then human-in-the-loop with measurement. Q5. Tell me about a time you had to communicate a technical risk to a non-technical stakeholder. Strong Answer Framework: Strong answers translate the risk into business terms (dollars, downtime minutes, customer impact) without dumbing down the underlying mechanism, and describe a concrete decision that resulted from that conversation. Q6. Describe a postmortem you wrote that changed how the team operated. Strong Answer Framework: The differentiator is a specific, adopted process change with evidence it stuck - a new alert, a new checklist item, a new guardrail added to an automation - not just "we discussed it and moved on." Q7. Tell me about a time you pushed back on a proposed automation because it lacked safety guardrails. Strong Answer Framework: A strong example: an operator proposal that would restart any CrashLoopBackOff pod regardless of cause, and your pushback to add termination-reason classification, a restart cap, an audit log, and explicit escalation for unrecognized cases before it touched production. Q8. How do you prioritize reliability work against feature deadlines? Strong Answer Framework: Use error budget status as the deciding signal rather than gut feeling: a service comfortably within its budget can tolerate some toil for now, while a service actively burning budget should preempt unrelated feature work regardless of deadline pressure. Q9. Tell me about a time you mentored a junior engineer through a production incident. Strong Answer Framework: Focus on how you let them drive while you guided the triage order, rather than taking over - and on a specific piece of judgment they demonstrably carried into future incidents afterward. Q10. Describe the most technically complex system you've owned end-to-end. Strong Answer Framework: Cover the failure modes you designed for explicitly - not just the happy-path architecture - and name one design decision you'd defend again under direct pushback. Q11. Tell me about a time you had to say no to a request from a stakeholder because it would have hurt reliability. Strong Answer Framework: The strongest answers show you offering an alternative, not just a refusal - for example, rejecting an urgent unreviewed production change but offering a fast-tracked, still-reviewed path instead. Q12. How do you handle being paged for something that turns out to be a false alarm, repeatedly? Strong Answer Framework: Treat repeated false alarms as a signal the alert itself needs fixing, not something to just tolerate - reference tightening the alert's duration threshold or its underlying query. Q13. Tell me about a time your on-call rotation structure itself was part of the problem. Strong Answer Framework: Reference the structural toil floor concept directly - recognizing that a too-small rotation was creating an unsustainable baseline of interrupt work, and what you did about the rotation size or coverage model itself. Q14. Describe a time you had to make a judgment call under incomplete information during an active incident. Strong Answer Framework: Be explicit about what you knew, what you didn't, and why you chose to act anyway (or chose to wait) given the blast radius. Q15. Where do you want to be in three years as an SRE? Strong Answer Framework: A senior-level answer names a specific area of technical depth to go deeper on (distributed consensus, capacity planning, chaos engineering maturity) and a specific form of broader organizational impact, rather than a vague title progression.
Skills You'll Master
Curriculum Index
Before You Read This
You are 5+ years into your career and interviewing for a Senior or Staff SRE role. The bar shifts from "can you operate ...
Tier 1 - Senior Fundamentals Checklist
No answers given below. If you cannot answer these cold across Linux, Kubernetes, distributed systems, databases, SRE pr...
Tier 2 - Real Interview Questions (Q1-Q15)
Q1. Designing an SLO for a Checkout API With No Existing Target The Prompt Design an SLO for a checkout API that current...
Tier 2 - Real Interview Questions (Q16-Q24)
Q16. PgBouncer Pool Modes The Prompt What is the difference between PgBouncer's session, transaction, and statement pool...
Tier 3 - Scenario Round
Scenario 1: The 3 AM Timeout Mystery The Prompt It's 3 AM. API pods are healthy, CPU is calm, memory is fine. Every requ...
Behavioral Round
Q1. Tell me about an incident you handled that went badly. What did you change afterward? Strong Answer Framework: Use S...
Salary Reference
Level Salary Band L4 - Senior SRE Rs 30L - Rs 55L L5 - Staff SRE Rs 55L - Rs 90L L6+ - Principal SRE Rs 90L - Rs 150L Th...
Career Impact
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.
Troubleshooting & Lab Guides
Next Modules
Frequently Asked Questions
Yes - every Tier 2 and Tier 3 question is drawn from the shape of real senior SRE screens at companies like Razorpay, Zerodha, and Swiggy, not invented from general Kubernetes or Linux trivia.
5-10 years, targeting Senior and Staff SRE roles. Tier 1 assumes you can already answer fundamentals cold; if not, revisit the underlying concept before Tier 2.
Roughly 2 hours end to end, including the fundamentals checklist, all Tier 2 and Tier 3 answers, and the behavioral round.