How to Pass a DevOps Interview

Most advice on DevOps interviews is a list of definitions: what is CI/CD, what is a pod, what does Terraform do. You should know those, but they rarely decide the outcome. The hard rounds hand you a broken system or a risky decision and watch how you think.

This guide covers what each round tests, then walks through five common scenarios with a weak answer and a strong answer side by side. It ends with a 4-week plan and a checklist for the day before.

What a DevOps interview loop looks like

There is no standard loop. Titles vary (DevOps, SRE, platform, cloud engineer), and so do the rounds. Published accounts, mostly from larger companies and SRE roles, describe some mix of these:

Round	Typical length	What it tests
Recruiter screen	20-30 min	Background, motivation, sometimes a few simple technical questions
Technical screen	Varies	Short Linux, networking and tooling questions, often pass or fail
Scripting or coding	About 45 min	Parse a log, call an API, handle errors
Live troubleshooting	45-60 min	Fix a broken system while explaining your thinking
Design	About 60 min	A CI/CD pipeline or service design, with a focus on how it fails
Behavioral or incident	About 45 min	Ownership, blameless framing, what changed afterward

These lengths come from write-ups by techinterview.org and LinkedIn Engineering (the LinkedIn post is from 2017), so treat them as a guide. One candidate described an Apple loop as "4 rounds scheduled. Coding, DevOps focus rounds and behavioral round". Smaller companies often compress all of this into one or two conversations.

Ask the recruiter which rounds you will have, how long each one is, and whether any of them is hands-on. It is a normal question, and the answer tells you where to spend your time.

What interviewers are actually judging

The shift from junior to senior is the shift from "do you know this tool" to "can you reason when you do not know what is wrong yet". LinkedIn's SRE hiring post says it deliberately leaves out "trivia, whiteboard coding, in-depth kernel knowledge".

No company publishes its real rubric, so the table below is drawn from published interviewer descriptions, including PracHub's SRE guide. Use it as a guide to the signals, not an official standard.

Area	Strong signal	Weak signal
Troubleshooting	Ranks hypotheses and says what each command result would prove	Lists commands without saying why
Incidents	Protects users first, then finds the cause	Chases the root cause while users are still affected
Design	Asks about requirements and failure modes first	Starts drawing boxes straight away
Trade-offs	Names what the choice costs	Calls one tool or approach "best"
Pushback	Changes position for a good reason, holds it otherwise	Folds at the first challenge, or gets defensive

The incident row catches a lot of people. As techinterview.org puts it: "The single most common way to fail this is to start diagnosing root cause immediately."

Worked scenarios: weak answer vs strong answer

These five prompts cover the shapes you are most likely to meet. Read the strong answers out loud. Saying them is a different skill from recognizing them.

"The disk is 100% full and the app is down"

Weak answer: "I would delete the old logs in /var/log and restart the service."

It might work. It also destroys evidence, can break services that expect those files, and may not free any space, because a process holding a deleted file keeps that space allocated.

Strong answer: "First I want to know which filesystem is full and what is filling it, because deleting blindly could make this worse."

df -h                  # which filesystem is full
df -i                  # or is it out of inodes, not bytes
du -xsh /* | sort -h   # what is using the space
lsof +L1               # deleted files still held open by a process

"If du looks small while df says full, I suspect a deleted file that is still open, so I would restart or signal the process holding it. To get the service back quickly I would truncate an active log with truncate -s 0 rather than rm it, and clear known-safe caches. Then I would fix why it happened: log rotation, size limits, and an alert that fires well before 100%."

The trade-off to name: growing the volume buys time, but it does not explain what filled the disk. Argue this one through in the full-disk challenge.

"This pod is in CrashLoopBackOff"

Weak answer: "I would give it more CPU and memory, or delete the pod so it restarts."

CrashLoopBackOff is a symptom: the container keeps exiting and Kubernetes keeps backing off before restarting it. Neither change tells you why it exits.

Strong answer: "I would find out why the container is exiting before changing anything."

kubectl describe pod <pod>      # Last State, Reason, Exit Code, Events
kubectl logs <pod> --previous   # logs from the container that just died
kubectl get events --sort-by=.lastTimestamp

"The exit code points me somewhere. A 137 with reason OOMKilled means the memory limit was hit, so I would compare the limit to real usage. An exit code of 1 usually means the app itself failed, often on missing config or a bad secret. If it restarts while looking healthy, I would check whether the liveness probe is killing it during a slow start. And since this started after a deploy, rolling back is my first mitigation if users are affected."

The trade-off to name: rolling back restores service quickly, but you still need to find the cause before shipping again. Try it in the CrashLoopBackOff challenge.

"Terraform wants to destroy the production database"

Weak answer: "The plan must be right, so I would apply it during a maintenance window."

Strong answer: "I would not apply anything yet. I want to read the plan and find out exactly why it wants to replace the resource."

"Terraform marks the attribute that triggers it with forces replacement. Often the cause is a renamed resource, a changed attribute or drift, not an intent to rebuild the database. If it is a rename, I would fix it with a moved block or terraform state mv so the state matches, then plan again until it shows no destroy. Before touching anything risky I would confirm a recent backup restores. I would also add prevent_destroy to the database so this cannot happen by accident."

The trade-off to name: some attribute changes really do require replacement. Then this becomes a planned migration with a cutover, not a Terraform apply. Practice it in the destructive apply challenge.

"Design a CI/CD pipeline for this service"

Weak answer: Naming tools straight away: "GitHub Actions, then Docker, then Kubernetes."

Strong answer: Ask first. How large is the team? How often do they deploy? What does a bad deploy cost? Is there a database migration in the path? Then lay it out:

1. On every pull request: lint, unit tests, and a build, kept fast enough that people do not route around it.
2. On merge: build one immutable image, tag it with the commit SHA, and scan it.
3. Promote that same image through staging to production. Never rebuild between environments, or you are not shipping what you tested.
4. Deploy gradually: rolling or canary, watching error rate and latency.
5. Roll back automatically when those signals go bad, and keep database migrations backward compatible so rollback stays possible.
6. Handle secrets without long-lived keys: short-lived credentials through OIDC where the platform supports it.

The trade-off to name: speed against safety. If someone says "the pipeline is slow, skip the tests", the better answer is to parallelize and cache, not to remove the check. Argue that in the skip-tests challenge, and see the OIDC vs keys challenge for the secrets part.

"Latency just spiked. Walk me through it."

Weak answer: "I would scale up the service and check the database."

Strong answer: "First, how bad is it and who is affected? Which endpoints, which regions, is it p50 or only p99? Then what changed: a deploy, a config change, a traffic shift, a dependency? If a deploy lines up with the spike, I would roll back first and investigate after, because that is the fastest way to stop the impact. Then I would use traces to find where the time goes across the request, rather than scaling whichever service looks slowest."

The trade-off to name: rolling back loses a release but restores users, while fixing forward keeps the release but extends the risk. Practice both sides in the p99 latency challenge and the roll back or fix forward challenge.

How to handle the live troubleshooting round

Candidates on Blind describe these rounds in concrete terms. One had to log in to a VM and fix an nginx server that would not start, with faults including a full disk, a malformed config, wrong file permissions and a port already in use. The same candidate put their success down to having dealt with nginx failures before, and said the interviewer gave hints when they got stuck.

Use the same order every time:

1. Restate the problem in your own words and ask what "broken" means here.
2. Scope the impact: everyone or some users, since when.
3. Check what changed recently.
4. State a hypothesis out loud before you test it.
5. Run one command and say what the result proves or rules out.
6. Mitigate if users are affected.
7. Find the root cause.
8. Say how you would prevent a repeat.

Ask about the rules at the start. Another candidate reported being told "You're allowed to google during it", but do not assume every company allows it.

If your mind goes blank, say so and fall back on the method: "Let me step back. Here is what I know, here is what I have ruled out, and the next thing I would check is this." Silence is hard to score. Visible reasoning, even when it is wrong, gives the interviewer something to work with.

The scripting and coding round

Expect practical tasks more often than puzzles: parse a log and count errors, call an API and write the result to a file, retry a failing request. The Blind candidate above was asked to write "some short script to curl an API and write to a file". Some companies do use LeetCode-style questions, so ask the recruiter which kind to expect.

What separates candidates is usually the unhappy path. What if the API returns a 500? What if the file is missing or the JSON is malformed? Handle those without being asked, and mention what you would log. Pick one language, Python or Bash, and get fast with it.

Telling incident stories that hold up

Prepare three stories using this structure:

• What broke, and how you found out.
• Your part, specifically. Say "I", not "we", for what you did.
• How you mitigated it before you understood it fully.
• What changed afterward, such as an alert, a runbook or a removed failure mode.

Keep it blameless. Blaming a teammate is a red flag, and techinterview.org notes this round is "scored as much on tone as on technical depth".

If you have no production experience, use a project you built and broke. Run something real on a small VM, cause a failure on purpose, and write down what happened. Say plainly that it was a personal project. An honest small story beats an inflated big one, because follow-up questions expose inflated stories quickly.

A 4-week DevOps interview prep plan

This is our recommended plan, and it assumes you already have working fundamentals. If you are changing careers, expect it to take longer.

Week	Focus	Daily practice	Done when
1	Linux and networking	Fix broken servers, for example on SadServers. Practice DNS, TCP, permissions and processes	You can debug "it cannot connect" layer by layer without notes
2	Containers, Kubernetes, Terraform	Break a local cluster and fix it. Read Terraform plans closely	You can explain any pod failure state and any forces replacement line
3	CI/CD, design, scripting	Design two pipelines out loud. Write three small scripts with error handling	You can draw a pipeline and name how each stage fails
4	Timed practice and stories	Timed scenarios out loud, three incident stories, research on the company	You can answer a scenario in 10 minutes and survive follow-up questions

Only have 2 weeks? Skip design depth. Focus on the stack named in the job description, troubleshooting method, and your stories.

Our free Linux, Docker, Kubernetes and Terraform guides cover the material for weeks 1 and 2.

Common ways candidates fail

• Running commands without saying what they expect to learn
• Chasing the root cause while users are still affected
• Listing tools instead of giving reasons
• Putting a tool on the resume and failing basic follow-up questions
• Designing before asking about requirements
• Blaming a teammate in an incident story
• Folding the moment the interviewer pushes back, even when the answer was right
• Only ever practicing silently, in their head

The last two are the easiest to fix and the most often skipped. Reading answers feels like progress, but the interview tests whether you can defend a call while someone argues with you, so practice that directly.

FAQ

Are DevOps interviews hard?

They are broad more than deep, and the format is hard to predict. As one commenter on Blind said, "Linux is enormous", and you will not learn all of it. Hands-on experience helps most, because live rounds look a lot like everyday debugging.

Do DevOps interviews have coding?

Usually some, mostly scripting such as parsing logs or calling APIs. Some companies use LeetCode-style questions, so ask the recruiter what to expect.

How many rounds are in a DevOps interview?

It varies. Published loops at larger companies have about four to six stages. Smaller companies often run fewer.

How long should I prepare for a DevOps interview?

About four weeks if you already have working fundamentals, and longer if you are changing careers. If you have less time, focus on the job description's stack, troubleshooting, and your stories.

What questions are asked in a DevOps interview?

Expect definitions in the screen, scenarios in the technical rounds, a pipeline or system design, and incident stories in the behavioral round. Typical scenario prompts are a full disk, a crashing pod, a dangerous Terraform plan, or a latency spike.

Can I Google during a DevOps interview?

Sometimes. Some companies allow it during hands-on rounds and others do not, so ask at the start.

What if I do not know the answer?

Say so, then explain how you would find out and give your best hypothesis. Hints are normal in live rounds. Bluffing is the mistake that is hard to recover from.

How do I pass a DevOps interview with no experience?

Build and break a real project, and use it for your stories. Know Linux, networking, Git, one cloud, and containers well enough to debug them. Be honest about your scope, since entry-level interviewers are not expecting production war stories.

The day-before checklist

• Confirm the rounds, their length, and whether you can look things up
• Reread the job description and note its stack
• Say your three incident stories out loud
• Run through one troubleshooting scenario, narrating each step
• Prepare two or three questions about their on-call and deploy process
• Review anything on your resume you could not defend under follow-up
• Test your camera, microphone, and terminal setup
• Get some sleep