A reusable bank of interview questions for Senior DevOps and Platform Engineer candidates. Organized by domain — pick 8-12 total, mixing technical depth with behavioral. Adjust emphasis based on the role’s focus areas.

Kubernetes / Container Platform

  1. Walk me through a complex Kubernetes migration you’ve participated in. What were the most painful breaking changes, and how did you handle stateful workloads?
  2. Describe a real situation where you debugged a pod scheduling failure that wasn’t obvious from kubectl describe.
  3. How do you handle secret rotation in a Kubernetes environment without causing downtime?
  4. What’s your approach to resource requests/limits? How do you right-size them in practice, not just in theory?
  5. Describe a time a Kubernetes cluster degraded in production. How did you detect it, contain it, and run the post-mortem?

CI/CD Architecture

  1. Walk me through a CI/CD platform migration you’ve led or contributed to. What did you learn that you’d do differently if you did it again?
  2. How do you handle pipeline secrets across environments (dev/staging/prod) without duplicating credentials everywhere?
  3. What made your most recent pipeline design inadequate compared to the one before it? What drove the iteration?
  4. How do you test pipeline changes without breaking the delivery chain for other teams?
  5. Describe a custom automation tool you built to solve a gap in your CI/CD platform. What made it non-trivial?

Infrastructure as Code

  1. What’s your strategy for managing Terraform state across teams to avoid conflicts?
  2. How do you handle drift between what Terraform says exists and what’s actually in the cloud?
  3. Describe a Terraform module you’re particularly proud of. What made it reusable rather than a one-off?
  4. How do you test infrastructure changes before applying them to production?

Observability & Custom Tooling

  1. Walk me through a custom observability or log-routing tool you built. Why did off-the-shelf tooling fall short? Why did you choose the language/stack you did?
  2. You’ve likely used multiple observability stacks (ELK, Datadog, Dynatrace, New Relic, etc.). How do you decide which tool fits which problem?
  3. How do you approach alerting design to avoid alert fatigue? Walk me through a real example.
  4. Describe a time your monitoring failed to catch an incident before users did. What changed afterward?

Security & Reliability

  1. You mention catching a high percentage of vulnerabilities before production. How did you measure that? What slipped through, and why?
  2. How do you handle a situation where a security scan blocks a release but the business is pushing to ship?
  3. Describe your approach to zero-downtime deployments. What’s the hardest failure mode you’ve had to design around?

Behavioral / Collaboration

  1. Tell me about a time you had competing priorities — a live release at risk and a broken pipeline simultaneously. How did you triage?
  2. Tell me about a time a development team resisted a DevOps practice you were pushing. How did you handle it?
  3. Have you worked with globally distributed teams? What broke down in that context and how did you adapt?
  4. Describe a handoff that went badly — either one you gave or one you received. What would you do differently?

Probing Depth / Verifying Claims

These are useful when a resume has quantified claims. Ask for the “how” behind the number.

  1. Your resume mentions [metric, e.g., “99.8% release success rate”]. How did you define and measure that?
  2. [Improvement claim, e.g., “reduced deployment time by 70%”] — how did you baseline and track that improvement?
  3. What’s something on your resume that you’d flag as “I contributed to this, but I wasn’t the primary driver”?
  4. What’s the most significant outage you’ve caused or contributed to, and what changed afterward?
  5. What’s a technology on your resume that you’ve listed but would be uncomfortable being the team’s primary expert on?

Tips for Use

  • Depth over breadth: Pick fewer questions and go deeper with follow-ups rather than covering everything.
  • Follow the claim: When a candidate gives a strong answer, ask “what went wrong?” — it reveals whether they actually owned the work.
  • Red flags: Vague metrics, inability to name specific failure modes, or “we did it as a team” with no personal contribution details.
  • Green flags: Unprompted mention of trade-offs, specific failure stories, opinions on when not to use a technology.