Site Reliability Engineer interview questions and answers

Sample answer

I first identify the user journeys and what a successful outcome means. I would define indicators for successful requests and latency, then separately measure answer quality, groundedness or task completion, and safe fallback behavior. I set objectives over a stated window based on user and business needs, exclude only well-defined cases, and make sure the indicators can be segmented by dependency and release version. Infrastructure availability alone would not show whether the assistant was useful.

Sample answer

I verify the impact using end-to-end traces and the relevant latency objective, then protect users by bounding request time, queue depth, and concurrency. Depending on the product contract, I can serve a safe degraded response, route to a pre-evaluated fallback, or temporarily disable the expensive path. I communicate the incident and dependency status, avoid uncontrolled retries, and restore full traffic only after health signals recover and the fallback behavior is understood.

Sample answer

I identify which failures are transient and which should fail immediately, then use a small bounded retry count with exponential backoff and jitter for retryable operations. I set request deadlines, propagate cancellation, cap concurrency, and consider a circuit breaker or queue policy where it fits the dependency. Retries must not exceed the user's time budget or multiply load across several service layers. I test partial failures and recovery, not just a healthy dependency.

Sample answer

I use the rollout's stop conditions and compare the new version with the baseline, including affected users and dependencies. If impact exceeds the agreed threshold, I halt or reduce exposure and choose a verified rollback, roll-forward, or feature disablement based on data compatibility and side effects. I preserve release evidence, communicate status, and do not expand the rollout until the objective recovers and the failure mode has a tested correction.

Sample answer

I start with business impact, recovery-time and recovery-point objectives, regional dependencies, data residency, and the cost and operational skill required to run a second region. I compare multi-region failover with simpler measures such as backups, queueing, graceful degradation, or a documented recovery process. If failover is justified, I test data consistency, routing, capacity, quotas, and operator ownership instead of treating a second deployment as proof of resilience.

Sample answer

I build a shared timeline from system evidence, describe the impact and contributing conditions, and distinguish what responders knew at the time from what became clear later. Actions should address detection, containment, recovery, or prevention, each with an owner and verification method. I prioritize a few changes that reduce recurrence or impact, then check completion and measure whether the service actually became safer.