DevOps Engineer Interview Rounds and What Each One Tests

The rounds in DevOps, SRE, platform and cloud engineer interviews, what each one tests, a worked troubleshooting example and a three-week prep plan.

A DevOps engineer interview can start with a recruiter screen and a coding or scripting round, then move into systems rounds: Linux and networking fundamentals, a live troubleshooting scenario, an infrastructure or system design discussion, and a behavioral conversation about incidents and on-call. Which rounds carry the most weight depends on the title. In our reading of the published material, site reliability engineering (SRE) loops lean hardest on troubleshooting and operating-system internals, platform roles on tools for other engineers, and cloud roles on architecture inside one provider.

There is no single standard loop for these roles, so this page compares three companies that describe theirs in public, explains each round, walks through an illustrative troubleshooting round and ends with a preparation plan.

What three companies publish about their loops

GitLab publishes the hiring steps for its Site Reliability Engineer role in its public handbook. Selected candidates complete a technical questionnaire, then have a 30-minute screening call, a 60-minute technical interview with a member of the Reliability Engineering team, two or three 45-minute team interviews with at least one SRE, and a 60-minute interview with a hiring manager. The same page asks for programming skills in "Shell, and Ruby and/or Go" and expects SREs to join an on-call rotation and run "blameless RCAs on incidents and outages".

Google described its SRE interview process in a 2015 article in USENIX's ;login: magazine, written by three Google authors. After a recruiter pre-screen and one or two phone interviews with an engineer, candidates had four or five interviews in a day, each assigned one topic such as programming, UNIX internals, networks, or troubleshooting and problem-solving, chosen partly from the strengths the candidate said they had. At least one interview involved coding in the candidate's preferred language, and one covered "non-abstract large system design", which asked for realistic throughput and storage estimates rather than boxes on a whiteboard. A hiring committee, not the manager, made the decision. The article is a decade old, so read it as a philosophy rather than today's schedule.

Atlassian publishes one interview guide for all its engineering roles and adds sample coding prompts for SRE candidates. Its stages are a two-part coding interview (data structures and code design) in a language you choose, a 60-minute systems design interview, a manager interview, a values interview and a hiring committee review. Atlassian says the design interviewer looks at the questions you ask, "how you'd talk through constraints like reliability and cost", who you would partner with and which technologies you would pick.

Side by side, the three agree on more than their job titles suggest. All three expect real programming skill, and both Google and Atlassian judge design answers on reliability and cost rather than on a polished diagram. They differ in where systems knowledge is tested: GitLab opens with a technical questionnaire and a dedicated technical interview, Google gave it to interviewers by topic, and Atlassian's guide lists no separate Linux or troubleshooting stage at all.

Eight rounds you may meet, and what each one probes

The eight rounds below are our grouping of what these loops can include, not any company's published list. None of the three published loops above runs all eight as separate interviews, so ask your recruiter which ones yours includes.

Recruiter screen

The recruiter screen checks that your experience matches the role before engineers spend time on you; GitLab's lasts 30 minutes, and Google's article calls its version a short technical pre-screen. Be ready to name your production stack, your strongest cloud provider and whether you have carried a pager. Our recruiter phone screen guide covers the logistics and the salary question.

Coding or scripting

Expect code even for operations-heavy roles: Google's article says to ask every SRE candidate to code something, Atlassian runs a two-part coding interview in a language you choose, and GitLab's SRE role asks for Shell plus Ruby or Go. Interviewers want readable code you would trust to run unattended, so handle empty or malformed input and say how you would test it.

Linux and networking fundamentals

Google's SRE book says UNIX system internals and networking (Layer 1 to Layer 3) are the two most common extra skills it seeks in SRE candidates, and the 2015 article says each interviewer tries to "discover the limits of the candidate's knowledge" and watch how they reason beyond it. When you reach a gap, say so and reason it through; Monzo's backend engineering interview guide says saying "I don't know" is fine and that it is more interested in reasoning from first principles. Our SRE interview questions are good drilling material for this round.

Troubleshooting or incident scenario

The interviewer describes a broken system and you investigate out loud, asking for the data you would check. Google's SRE book chapter on troubleshooting lays out a sequence that maps well onto this round: problem report, triage, examining metrics and logs, diagnosis, then testing and treating candidate causes. It also says to stop the bleeding before root-causing, because "you aren't helping your users if the system dies while you're root-causing", and that recent changes such as a configuration push often cause failures.

Infrastructure and CI/CD design

You design something such as a deployment pipeline or the infrastructure for a new service, and talk through trade-offs. For pipelines, use the DORA software delivery metrics as your vocabulary: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Say which one your design improves and how a bad change gets rolled back. For Microsoft's toolchain, our Azure DevOps interview questions cover pipelines and releases.

Kubernetes and containers

The Certified Kubernetes Administrator exam is a useful map of what this round probes. It is a two-hour, performance-based test taken at a command line, and troubleshooting is its largest domain at 30%, ahead of cluster architecture at 25% and services and networking at 20%. Kubernetes-focused interviews often probe the same skill: finding why a pod will not start or a service is unreachable. Drill with our Kubernetes interview questions, our Kubernetes troubleshooting scenarios and our Docker interview questions for the container layer underneath.

Cloud architecture

For cloud engineer roles, expect the design round to become a provider-specific architecture discussion. AWS's Well-Architected Framework names six pillars, operational excellence, security, reliability, performance efficiency, cost optimization and sustainability, and using them as a checklist stops your answer becoming a list of services. Our AWS interview questions cover the services interviewers ask about most.

Behavioral: on-call, incidents and postmortems

In DevOps and SRE loops, the behavioral round can be about operations as much as teamwork: an incident you handled, a risky change you pushed back on, how you shared on-call load. Atlassian's manager interview covers your background, career goals and collaboration style, and Monzo says its behavioral stage explores communication, learning, teamwork and delivering projects. Our behavioral interview questions guide covers the general method, and the incident story gets its own section below.

How DevOps, SRE, platform and cloud loops differ

Google's SRE workbook calls DevOps "a loose set of practices, guidelines, and culture" and SRE "somewhat closer to a concrete definition of a job or role than, say, 'DevOps engineer'". A DevOps engineer title can cover anything from build-and-release work to infrastructure as code, so read the job description, and prepare for CI/CD design and scripting.

In our reading, SRE loops are the most predictable, weighting Linux internals, networking and live troubleshooting, and it is worth knowing service level objectives and error budgets, since the workbook lists managing by SLOs as a defining SRE principle and treats error budgets as part of the SRE framework. Platform engineer loops add a product question: the CNCF's platforms white paper defines a platform as capabilities "presented according to the needs of the platform's users", meaning internal developers, so expect prompts about self-service tooling and how you would learn what other engineers need. Our platform engineering interview prep guide goes deeper on that angle. Cloud engineer loops weight architecture and provider services most, with less on operating-system internals. This split is our reading of the published material, not a rule any company states, so check the job posting.

An illustrative troubleshooting round: intermittent 502s after a deploy

This scenario is illustrative: we wrote it to show how a strong candidate narrates an investigation, and it is not from any company's question bank. The technical steps follow AWS's documentation for Application Load Balancers.

In the prompt, a web service runs on instances behind an AWS Application Load Balancer, a new version shipped 20 minutes ago, and users now see occasional 502 Bad Gateway errors.

Scope and mitigate. The candidate asks what share of requests fail, whether errors began exactly at the deploy, and whether every target is affected. Because the errors started with a change, they propose rolling back first if that is safe, keeping the new build available to investigate.

Find who returned the 502. The load balancer counts errors it generates in the HTTPCode_ELB_5XX_Count metric and errors from targets in HTTPCode_Target_5XX_Count. In the access logs, an elb_status_code of 502 with a target_status_code of "-" means the load balancer either could not establish a connection to the target or received no response from it.

List the causes that fit. AWS documents several causes of a load-balancer 502 that match "intermittent" and "after a deploy". The target may have closed the connection while a request was outstanding, which AWS says to check by comparing the target's keep-alive duration with the load balancer's idle timeout. Requests may have been cut off when the deregistration delay elapsed for targets removed during the rolling deploy, or the new version may send malformed headers or a response header over 32 K.

Test the cheapest distinguishing hypothesis. The candidate asks whether the release changed the web server or its keep-alive settings, and whether errors cluster while old instances drain or spread evenly across healthy targets. Clustering during draining points at the deregistration delay, while an even spread points at a keep-alive shorter than the idle timeout.

Fix, verify and follow up. The fix is a target keep-alive longer than the idle timeout, or a longer deregistration delay, then watching the ELB 5XX count return to baseline. Afterwards they would alert on that metric and write up the incident.

The interviewer is scoring reasoning, not the answer: asking for data instead of guessing, stating each hypothesis before testing it, picking the cheapest test that separates two causes, and mitigating before investigating. Google's troubleshooting chapter warns against unlikely theories ("When you hear hoofbeats, think of horses not zebras") and against confusing correlation with causation, and interviewers notice both quickly.

How to tell the story of an incident you handled

Expect at least one question asking you to walk through a real incident. Google's SRE book defines a postmortem as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring", which makes a good outline for your answer.

Open with the context and your role, whether you were the responder, the incident lead or the engineer who found the cause.
Give the timeline in a few beats: how it was detected, how you mitigated it and when service recovered.
State the impact as the business would, such as which users were affected and for how long.
Explain the causes, including contributing ones, and keep the story about systems rather than people.
Finish with what changed afterwards, such as a new alert, a pipeline check or a runbook, because that is the part interviewers remember.

Google describes a blameless postmortem as one that focuses "on identifying the contributing causes of the incident without indicting any individual or team", and GitLab lists blameless root-cause analysis among an SRE's duties, so an answer that blames a colleague signals the wrong habits even if it is accurate. If the mistake was yours, say so plainly and focus on how you closed the gap. An illustrative answer, invented to show the shape, might run: "I was on call when checkout errors spiked after a config change; I rolled it back within minutes, we found it had skipped staging, and I added a pipeline step that blocks configs that have not passed staging."

A three-week preparation plan

This plan assumes you already work with infrastructure; adjust it to the rounds your recruiter confirms.

Week one: fundamentals and code. Take one Linux or networking topic a day, such as processes and signals, memory, file systems, DNS or TCP, and explain it out loud from the bottom up. Write one small script a day in your interview language, such as parsing a log file, and handle bad input every time.

Week two: design, pipelines and Kubernetes. Design a CI/CD pipeline and the infrastructure for a new service, saying for each which DORA metric it improves and how a bad deploy is rolled back. Break and fix workloads on a local cluster until you can diagnose a failing pod without notes, and for cloud roles, review one reference architecture against the six pillars.

Week three: troubleshooting and stories. Run troubleshooting rounds aloud with a friend as interviewer, using the structure above, then write two incident stories and two collaboration stories and rehearse each until it fits in about three minutes.

Practise the rounds out loud with Verve AI

A troubleshooting round is judged on how you narrate the investigation, which is hard to practise in silence. In Verve AI's AI Mock Interview, an AI recruiter asks the questions, drawn from banks such as Software Engineering and Behavioral Questions, your own custom questions or a LinkedIn job description, so you can talk through an incident the way you would on the day, and afterwards you get "a detailed performance report with personalized feedback and scoring". Monzo's backend engineering guide states its rule directly, "It's fine to use AI to research and prepare for your interviews before, but we do not allow usage of LLMs during your interviews", so check your employer's rules and keep practice tools for before the day.

FAQ

How many rounds does a DevOps engineer interview have?

There is no standard number. GitLab's SRE process has a questionnaire, a screening call, a technical interview, two or three team interviews and a hiring manager interview. Atlassian lists coding, systems design, manager and values interviews before a hiring committee review. Ask your recruiter for the list of rounds and the topic of each.

Is an SRE interview different from a DevOps interview?

In our reading, it is usually more predictable. Google's SRE workbook calls SRE closer to a concrete job definition than "DevOps engineer", and SRE loops tend to weight Linux internals, networking and live troubleshooting more. DevOps engineer loops vary with the job description, with CI/CD design and scripting as likely themes.

Do DevOps and SRE interviews include coding?

Expect it. Google's 2015 article recommends asking every SRE candidate to code, Atlassian runs a two-part coding interview in a language you choose, and GitLab's SRE role asks for Shell plus Ruby or Go. Prepare practical code you would trust in automation.

Do I need a Kubernetes certification?

None of the hiring processes we read requires one. The Certified Kubernetes Administrator exam is still a useful study guide, because it is a hands-on command-line test where troubleshooting is the largest domain at 30%. In our view, doing those tasks on a real cluster matters more in the interview than holding the certificate.

Sources

GitLab SRE hiring process (questionnaire, 30-minute screen, 60-minute technical interview, two or three 45-minute team interviews, 60-minute hiring manager interview, possible director/VP interviews), Shell and Ruby and/or Go, on-call rotation, blameless RCAs: https://handbook.gitlab.com/job-description-library/engineering/infrastructure/site-reliability-engineer/
Google SRE hiring in 2015 (recruiter pre-screen, phone interviews, four or five onsite interviews, one topic per interviewer, topics by self-assessed strengths, "discover the limits of the candidate's knowledge", coding in preferred language, "Ask every SRE candidate to code something", non-abstract large system design with realistic estimates, hiring committee): https://www.usenix.org/publications/login/june15/hiring-site-reliability-engineers
Same article, full-text PDF: https://www.usenix.org/system/files/login/articles/login_june_07_jones.pdf
Google SRE book: UNIX internals and networking (Layer 1 to Layer 3) as the most common additional skills sought: https://sre.google/sre-book/introduction/
Google SRE book troubleshooting steps, stop the bleeding, recent changes, horses not zebras, correlation versus causation: https://sre.google/sre-book/effective-troubleshooting/
Google SRE book postmortem definition and blameless postmortems: https://sre.google/sre-book/postmortem-culture/
Google SRE workbook on DevOps versus SRE, managing by SLOs, error budgets: https://sre.google/workbook/how-sre-relates/
Atlassian engineering interview stages, SRE coding prompts, language choice, systems design assessed on reliability and cost: https://www.atlassian.com/company/careers/resources/interviewing/engineering
Monzo backend engineering interview stages, behavioral stage content, "I don't know" guidance, AI and LLM rule: https://monzo.com/blog/demystifying-the-backend-engineering-interview-process
AWS Application Load Balancer 502 causes (keep-alive versus idle timeout, deregistration delay, malformed headers, 32 K header limit) and ELB versus target 5XX metrics: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html
AWS ALB access log fields elb_status_code and target_status_code ("-" when the target sent no response): https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html
AWS Well-Architected Framework six pillars: https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html
DORA software delivery metrics: https://dora.dev/guides/dora-metrics/
CKA exam format and domain weights: https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/
CNCF platforms white paper definition of a platform: https://tag-app-delivery.cncf.io/whitepapers/platforms/
Verve AI Mock Interview (AI recruiter, question banks, performance report with personalized feedback and scoring): https://docs.vervecopilot.com/features/mock-interview