DevOps Engineer screening interview questions

What a good devops engineer screen should establish

• Experience operating production infrastructure
• Automation mindset (CI/CD, infrastructure as code)
• Incident response and reliability practices
• Security and cost awareness
• Ability to support developers as internal customers

The questions, and what to listen for

1. 01

   Describe the deployment pipeline at your last company. What did you own?

   Listen for: Specific stages, tooling, and personal changes they made to it.

2. 02

   Tell me about an outage you were on call for. What happened and what changed afterwards?

   Listen for: Clear timeline, root cause, and a durable fix or process improvement.

3. 03

   How do you approach infrastructure as code? What tools have you used in production?

   Listen for: Real experience with Terraform, Pulumi, CloudFormation, or similar, plus review and state management.

4. 04

   How would you reduce a cloud bill that grew 40% in a quarter?

   Listen for: Measure first, right-size, spot/reserved capacity, tag and attribute costs.

5. 05

   What monitoring and alerting have you set up, and how do you avoid alert fatigue?

   Listen for: Actionable alerts tied to SLOs, not CPU thresholds.

6. 06

   How do you keep secrets and credentials secure in a pipeline?

   Listen for: Secret managers, short-lived credentials, least privilege, no secrets in repos.

7. 07

   Tell me about a time you made developers' lives easier.

   Listen for: Treats developers as customers; measurable improvements in build time or friction.

8. 08

   How do you roll back a bad deploy safely?

   Listen for: Blue/green, canaries, feature flags, database migration caution.

9. 09

   Which container and orchestration tools have you run in production?

   Listen for: Honest depth with Docker, Kubernetes, ECS, or similar.

10. 10

    What do you do when a request from a developer conflicts with a security policy?

    Listen for: Seeks a compliant path, explains the why, escalates appropriately.

Red flags

• Only lab or certification experience, no production ownership
• Manual, undocumented processes described as normal
• No examples of post-incident improvements