In this article
How to use this list
The questions run from measurable delivery topics to people topics. If the round is mostly about people, start with the engineering manager interview guide, then come back here for the operations-flavoured questions. Say each answer aloud before you read ours, and keep the shape the same every time: the answer, one number or example, then the trade-off. Answers here are written as advice on what a strong answer contains; they do not claim any company asks a given question.
Delivery and metrics
What does a DevOps manager do?
A DevOps manager leads the team and the practices that carry a change from a developer's commit to running in production, and keeps that path fast and safe. In an answer, cover three things: delivery flow, reliability, and the culture between development and operations. Then say how you measure each and what you personally own, so the answer does not sound like running an operations desk.
Why it is asked: it shows whether you see the role as flow and outcomes or as tickets.
Which metrics do you use to measure software delivery?
Use the DevOps Research and Assessment (DORA) metrics. DORA, January 2026 lists five: change lead time, deployment frequency and failed deployment recovery time, which show throughput, plus change failure rate (DORA's guide calls it change fail rate) and deployment rework rate, which show instability. Apply them per application or service, and pair them with a people signal such as on-call load.
Why it is asked: it separates managers who measure outcomes from those who count activity. Source: DORA software delivery metrics.
Do speed and stability trade off?
No, according to DORA. Its guide says its research has repeatedly shown that speed and stability are not trade-offs, and that the metrics are correlated for most teams: top performers do well on all five and low performers do poorly (DORA, January 2026). Back the claim with your mechanism: small changes are easier to test and to recover from.
Why it is asked: many candidates repeat the "move fast or be safe" myth. Source: DORA software delivery metrics.
How do you stop teams from gaming delivery metrics?
Do not turn a metric into a target. DORA names this pitfall and ties it to Goodhart's law: a mandate such as deploying many times a day by year end invites gaming (DORA, January 2026). Use several metrics that pull against each other, share all of them across development and operations, and use them to find bottlenecks in conversation, not to rank teams.
Why it is asked: it tests judgement about measurement and its effect on behaviour. Source: DORA software delivery metrics.
How do you calculate and improve change failure rate?
Change failure rate is the share of deployments that need immediate intervention, such as a rollback or a hotfix. With illustrative counts of 4 such deployments out of 80, the rate is 5%.1 To improve it, shrink batch size: DORA's guide says smaller changes are easier to move through delivery and easier to recover from (DORA, January 2026). Add automated tests before deployment.
Why it is asked: it checks that you can define a metric and name a lever. Source: DORA software delivery metrics.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Reliability and incidents
What is an error budget?
An error budget is the amount of unreliability a service may have in a period, equal to one minus its service level objective (SLO), the reliability target for that service. A 99.9% target over 30 days leaves 43.2 minutes of allowed downtime.1 Teams can spend it on releases and risk; when it runs out, they slow feature releases and fix reliability.
Why it is asked: it tests whether you can turn reliability into a decision rule. Source: Google site reliability engineering (SRE) book, Embracing Risk.
Should a service aim for 100% uptime?
No. The Google SRE book argues that past a certain point, more reliability is worse for the service and its users, because extreme reliability limits how fast features ship and raises cost, and users often cannot tell the difference (Google SRE book, Chapter 3). Set the target from what the business can bear, then spend the remaining budget on change.
Why it is asked: it separates operations instinct from risk-based thinking. Source: Google SRE book, Embracing Risk.
How much downtime does a given availability target allow?
Multiply the unavailable fraction by the period. Over 30 days, 99% allows 432 minutes, 99.9% allows 43.2, 99.95% allows 21.6 and 99.99% allows 4.32 minutes.1 The SRE book gives the yearly case: 99.99% allows up to 52.56 minutes a year (Google SRE book, Chapter 3). Each added nine cuts the allowance tenfold; 99.95% is a half step between 99.9% and 99.99%, not a nine.
Text description of the diagram
- Over 30 days, 99% allows 432 minutes, 99.9% allows 43.2, 99.95% allows 21.6 and 99.99% allows 4.32 minutes.
- Each added nine cuts the allowance tenfold.
Why it is asked: it checks quick arithmetic and the cost of each extra nine. Source: Google SRE book, Embracing Risk.
How do you run a major incident?
Name an incident commander who runs the response, with an operations lead who fixes and a communications lead who updates stakeholders on a fixed rhythm (Google SRE book, chapter 14). Restore service first with a rollback or failover, then investigate causes; DORA's failed deployment recovery time measures how fast you recover. Keep a running timeline for the postmortem, and give every action item an owner and a date.
Why it is asked: it shows calm structure under pressure and whether you lead or only fix. Source: Google SRE book, Managing Incidents.
How do you run a blameless postmortem?
A blameless postmortem is a written review of an incident that asks how the system and its processes allowed the failure, not who caused it (Google SRE book, Postmortem Culture, chapter 15). Build the timeline from facts, ask why decisions made sense at the time, and end with a few owned follow-up actions. Share it widely. If people fear blame, they hide near misses.
Why it is asked: it tests whether you can create safety and still drive accountability. Read the full explanation: team health as an engineering manager question.
How do you reduce toil and on-call burden?
Toil is manual, repetitive operational work that adds no lasting value and grows with the service (Google SRE book, Eliminating Toil, chapter 5). Measure it first: track pages per shift and hours lost to repeated tasks. Then automate the largest recurring item, fix the noisiest alert, and protect engineering time for it. Rotate on-call fairly and watch for burnout signals in one-on-ones.
Why it is asked: it shows whether you protect the team's capacity and health. Read the full explanation: one-on-ones and hard feedback.
Teams and culture
How do you get developers and operations to share ownership?
Give both sides the same measures and the same pager. DORA warns that giving each team only its own metrics isolates teams and leads to friction and finger-pointing, and recommends sharing all five across development, operations and release (DORA, January 2026). Add joint reviews of incidents and a shared backlog for reliability work.
Why it is asked: it probes how you break silos without a reorganisation. Source: DORA software delivery metrics.
How would you structure a DevOps or platform team?
Choose by the problem. A central platform team that offers self-service tools suits many product teams that all need the same pipelines; embedded engineers suit a few teams with unusual needs. Treat the platform as a product: name its users, gather feedback and measure adoption. State the risk of each choice, such as a platform team that becomes a ticket queue.
Why it is asked: it tests organisation design and trade-off thinking. Related: tech lead interview questions.
How do you handle a low performer on your team?
Check expectations and context first, then give specific, documented feedback and a short plan with clear checkpoints and support. Meet often during the plan. If performance does not improve, move to the formal process with human resources. Show that you act early, stay fair, and protect the rest of the team from carrying the gap.
Why it is asked: it tests candour and fairness together. Read the full explanation: how do you handle a low performer.
How do you measure the health of your team?
Combine delivery signals with human ones. Delivery signals include the DORA metrics and on-call load; human signals include one-on-one themes, retention and a short regular survey. Look at trends, not one reading, and act on what you hear in front of the team. A single dashboard never replaces a conversation.
Why it is asked: it shows whether you notice problems before they become resignations. Read the full explanation: team health as an engineering manager question.
How do you grow engineers who work on operations?
Make growth explicit: agree a goal in a one-on-one, then match it to work such as leading an incident, owning a reliability target or designing a pipeline. Give the stretch with support, give feedback soon after the work, and make sure on-call and automation work counts toward promotion, not only features.
Why it is asked: operations-heavy roles are often undervalued, and interviewers want to see you value them. Read the full explanation: growing engineers.
Change, tooling and philosophy
How do you introduce continuous integration and delivery to a team that deploys by hand?
Continuous integration and continuous delivery (continuous integration (CI)/continuous delivery (CD)) means every change is built, tested and made ready to deploy by an automated pipeline. Start with one service, measure a baseline, and ask the team to name the biggest bottleneck. DORA's improvement steps are to set a baseline, discuss friction, commit to one constraint, and check progress (DORA, January 2026).
Why it is asked: it tests change leadership, not tool knowledge. Source: DORA software delivery metrics.
How do you decide whether to build or buy tooling?
Compare total cost: licence or hosting, plus the engineering time to build and maintain, against the time saved. Buy where the need is common and the tool is not a differentiator; build where it is core or no product fits. Define exit costs and review the decision each year.
Why it is asked: it shows cost thinking and respect for the team's time.
How do you balance security and delivery speed?
Treat security checks as part of the pipeline, not a gate at the end: automated scans, dependency checks and access reviews that run on every change. Agree a severity policy so only serious findings block a release. Where infrastructure is defined as code (IaC), reviewed changes also leave an audit trail.
Why it is asked: it tests whether you see the two as compatible and can design for both.
What is your management philosophy?
Pick two or three principles and show each in a story: for example, clear goals with freedom in how to reach them, safety to report problems early, and measuring outcomes not hours. Give one decision you made because of each principle, including one that cost something. Keep it grounded in this role: shared ownership and learning from incidents.
Why it is asked: it reveals values and whether your behaviour matches them. Read the full explanation: what's your management philosophy.
Follow-up questions
What are common DevOps manager interview questions?
The twenty above cover the themes that recur: delivery metrics, reliability targets, incidents and postmortems, on-call load, team structure, low performers and change. Expect a mix of operations and people questions, and read the people management round guide for the latter.
How do I prepare for a DevOps manager interview?
Prepare one real story per theme: an incident you led, a metric you improved, a conflict you resolved and a team you grew. Practise saying each in about a minute with the result and the trade-off. Rehearse out loud, not only in your head.
What is the difference between a DevOps manager and an engineering manager?
Both lead engineers, so the people questions overlap. A DevOps manager answers more questions on pipelines, reliability, incidents and the link between development and operations; an engineering manager's questions lean more on product delivery and growth. Scope varies by company, so ask the recruiter what the team owns.
Is a DevOps manager the same as a site reliability engineering (SRE) manager?
Not always. The titles overlap, and the SRE book describes site reliability engineering as balancing the risk of unavailability against rapid innovation (Google SRE book, Chapter 3). Ask how each team is organised and who owns the pager before you assume.
- Measure delivery with the DORA metrics, per service, and never as a target.
- Speed and stability move together when changes are small.
- An error budget turns a reliability target into a decision rule; extra nines cost more.
- Run incidents with clear roles, restore first, and hold blameless postmortems.
- Share ownership and measures between development and operations, and protect the team from toil.
Sources
- DORA's software delivery performance metrics — DORA (Google Cloud), 5 Jan 2026
- Embracing Risk, Chapter 3 of the Site Reliability Engineering book — Google SRE book (O'Reilly, first edition), 1 Apr 2016
- Managing Incidents, Chapter 14 of the Site Reliability Engineering book — Google SRE book (O'Reilly, first edition), 1 Apr 2016
- Eliminating Toil, Chapter 5 of the Site Reliability Engineering book — Google SRE book (O'Reilly, first edition), 1 Apr 2016
- Postmortem Culture: Learning from Failure, Chapter 15 of the Site Reliability Engineering book — Google SRE book (O'Reilly, first edition), 1 Apr 2016
