How to Prepare for a DevOps Engineer Interview

“A pod is in CrashLoopBackOff. Walk me through your diagnosis.”

What they're really asking: Do you have a systematic method, or do you guess at fixes until something works?

How to answer: Narrate an ordered process: describe the pod to read events, then read the container logs including the previous instance, then check the exit code. Branch from there — a non-zero application exit points at config or a missing dependency, exit code 137 points at the memory limit, an image pull failure points at registry credentials. Finish by saying what you would check to confirm the fix rather than assuming the restart means it is healthy.

“How does a code change get to production in your current environment?”

What they're really asking: Whether you have owned a real delivery path, and whether you can identify its weaknesses.

How to answer: Walk the path concretely from pull request to production, naming each gate and who approves it. Then volunteer the weakest link — perhaps a slow test suite, a manual approval that adds a day, or a rollback that requires a rebuild — and what you would change first. Interviewers value the critique more than the description.

“How would you handle a database migration in a zero-downtime deployment?”

What they're really asking: Whether you understand that the application and schema are deployed independently and can be out of step.

How to answer: Describe expand and contract: add the new column or table in a backwards-compatible change, deploy application code that writes to both and reads the old, backfill, switch reads, then remove the old field in a later release. Mention the operational details that bite — locking on large tables, migrations that must not run inside the app start-up path, and how you would roll back at each step.

“What would you automate first if you joined a team with a lot of manual work?”

What they're really asking: Whether you prioritise by impact and risk, or automate whatever is technically interesting.

How to answer: Say you would first measure — what tasks recur, how long they take, and which ones cause incidents when done by hand. Then prioritise the intersection of frequent, error-prone and low-risk to automate. Give an example of something you deliberately left manual because it was rare and dangerous to automate blindly.

“A deployment succeeded but error rates rose immediately afterwards. What do you do?”

What they're really asking: Whether you mitigate before you investigate, which is the core instinct of the role.

How to answer: State the order explicitly: restore service first by rolling back or shifting traffic away, then confirm error rates recover, then investigate with the deployment diff and traces in hand. Mention communication to affected teams during, not after. Close on the systemic point — whether a canary or a better health check would have caught this before full traffic.

“How do you decide what to alert on?”

What they're really asking: Whether you understand alert fatigue, which is the most common failure of a real on-call rota.

How to answer: Anchor on user-visible symptoms — error rate, latency, and whether the service is doing its job — rather than raw resource metrics that fire without meaning. Explain that every page should be actionable and tied to a documented response, and describe how you would prune an existing noisy rota by reviewing which alerts led to action over the last month.