DevOps interviews test breadth across infrastructure, CI/CD, observability, security, and incident response. The candidates who stand out can talk about specific production fires they handled and the systemic changes that came out of those incidents.
DNS → CDN edge → load balancer → ingress / service mesh → application pod → database. Mention TLS termination, where caching happens, and where you would add observability. Strong answers also flag failure points at each hop.
Pipeline gates (tests, security scan, manual approval if needed). Deploy strategy: blue-green, canary, or rolling. Health checks. Auto-rollback on metric regression. Feature flags decouple deploy from release. Discuss what you actually use, not theory.
Start with the four golden signals: latency, traffic, errors, saturation. Look at p95/p99, not the mean. Trace one slow request end-to-end. Check downstream dependencies (DB, cache, external API). Most production slowness is one of: lock contention, slow query, GC pause, or noisy neighbor.
A secrets manager (AWS Secrets Manager, Vault, GCP Secret Manager). Short-lived credentials via IAM roles or workload identity. No secrets in env files committed to git. Rotation policy. Audit access. Strong answers cite a real near-miss.
Specific incident, your role, the timeline, the customer impact, and — most importantly — the systemic change. Tooling change > process change > "we communicated more". Blameless framing is expected at this point.
Reserved capacity for steady workloads, spot/preemptible for fault-tolerant batch, right-size instances based on actual utilization, S3 lifecycle policies, retire orphaned resources. Reliability comes from chaos testing the cheaper config, not from over-provisioning.
Have a concrete production story ready that covers detection, diagnosis, mitigation, and post-incident change. Practice drawing system diagrams on a whiteboard — many DevOps interviews are visual and candidates who can sketch fluidly stand out immediately.
