Senior SRE Interview Questions

They are realistic senior-level questions, not a verified list from any named company. They are built from the skills senior SRE job postings keep asking for and from well-known failure patterns: connection pool exhaustion, retry storms, certificate expiry, noisy alerts and unsafe automation. Use them to practise the reasoning interviewers want, and never tell an interviewer that a specific company is known to ask a specific question.

At senior level you are expected to diagnose quickly, name the mechanism behind a failure, and own the fix. At staff level you are also expected to set the SLO and error budget policy, argue trade-offs across teams, and change how the organisation operates. This pack covers both, and the scenarios and behavioral round are where staff candidates should push hardest on organisational impact.

The mechanisms (cgroups, TCP queues, Raft quorum, WAL, SLO maths) are stable, but defaults and versions are not. Kernel defaults, PgBouncer features, Kubernetes probe types, certificate lifetime rules and DORA's metric set have all changed in recent years. Where a number appears, treat it as illustrative and say in an interview that you would confirm it for your kernel, distro or version.

Run a local cluster with kind or minikube, set a tight memory or CPU limit on a pod and watch it get OOMKilled or throttled, and use `stress-ng` or a small load generator to create pressure. Run PostgreSQL and PgBouncer in containers to reproduce pool exhaustion, and use `tc netem` to add latency or packet loss. Practising failures first-hand gives you the specific details interviewers listen for.

Do the Tier 1 checklist cold and mark anything you cannot explain in two or three sentences. For Tier 2 and the scenarios, speak your answer aloud before reading ours, and compare your diagnostic order rather than your wording. Do the hands-on round on a timer, and write your behavioral stories from your own history using the templates provided.

They are teaching examples. Output samples are illustrative, config snippets assume common setups, and values such as burn-rate multipliers come from published guidance that you should adapt to your own SLO window. Before using anything in production, check it against your tool's current documentation and test it somewhere safe.