Tag: DevOps

A DevOps candidate may know the commands for a deployment and still make the wrong call when that deployment starts failing. A useful DevOps engineer interview needs to show how they think when the next action could affect customers.

You are looking for someone who can connect a symptom to evidence, choose a sensible response, and explain what happens next. Tool knowledge matters, but it makes more sense inside that conversation than in a long round of definitions.

Here is a practical way to run the interview. Start with one troubled release, follow the candidate’s decisions, and use five areas of evidence to assess whether they are ready for the responsibility your team needs.

Be clear about what the person will own

“We need a DevOps engineer” can mean several different jobs. One team needs help making deployments repeatable; another needs someone to maintain cloud infrastructure. A third needs an engineer who will investigate incidents and help service owners recover.

Before writing questions, describe the first responsibility in plain language. For example: “Own the deployment path for our API, including release checks, recovery instructions, and support for the engineers using it.” Now you have something concrete to assess.

Also make clear who approves production changes, owns database migrations, and joins an incident. Agree who provides cover when the engineer is away. These decisions shape the job as much as the technology stack does.

GitLab’s overview of the DevOps engineer role brings together automation, infrastructure, and collaboration. That breadth is a reason to narrow your interview to the actual assignment, rather than expect equal depth in every possible tool.

A contractor repairing a release pipeline and a permanent engineer building an internal platform may face the same technical scenario. Their expected ownership, follow-through, and longer-term design decisions will differ.

Begin with a release that has gone wrong

Use this fictional scenario in a safe interview environment. A subscription product runs its API and background worker on Kubernetes, with PostgreSQL and a queue supporting the application. After a release, customers begin receiving errors and queued work starts taking longer.

Give the candidate a short timeline: the release begins at 10:00, request errors rise at 10:03, and queue age increases at 10:06. Supply sanitised logs, a few graphs, and the relevant configuration. Explain that the release includes a database migration.

Do not ask them to fix your production system. Ask what they would investigate, what action they might take, and what evidence would tell them whether it helped. Let them ask questions and make the information available consistently to each candidate.

The system diagram gives the conversation a shared reference. A candidate can trace a request, a release, or a queued task through it. When they suggest a change, ask which part of that path it affects.

An 80-minute session could leave 15 minutes for the system and ownership, 25 for the incident, 20 for a change review, and the rest for access and handover. Adjust the format to the role; the times are a suggested structure, not a benchmark.

Explain the policy on documentation and AI tools beforehand. If the candidate uses either, they should still be able to explain the proposed action, its risks, and how they would verify the result.

Listen to the first few questions

A useful first response is to establish the impact. Ask which requests are failing and whether the problem affects all customers or only those on the new version. Check who is coordinating the incident and what changed besides the application code.

These questions help the engineer avoid making an uncertain situation harder to understand. If several people change configuration independently, the team can lose track of what caused the original problem and what caused the next one.

Ask the candidate to name a hypothesis and the observation that would test it. For example, a rise in errors after deployment makes the release worth investigating. Comparing failures across versions could strengthen or weaken that explanation.

The queue is useful evidence too. Its age might rise because workers are failing, a database operation is slower, or the system is receiving more work than it can finish. Adding workers without examining the bottleneck could increase pressure on the database.

Notice how the candidate handles uncertainty. A reasoned next step with a clear verification condition gives you something to assess. Immediate certainty based on one graph gives you less.

GitLab’s account of changing its technical interviews argues for work that resembles the real job and makes a candidate’s reasoning visible. In this session, that means discussing evidence together rather than hiding the important facts to create a trick question.

Ask for a mitigation, then challenge the rollback plan

The candidate does not need to find the root cause before taking every useful action. Pausing further rollout may limit the problem while the team investigates. But the action should have a purpose and an owner.

Now ask about rollback. The database migration is the important detail: can the previous application version still work with the new schema? Rolling back code without knowing that can replace one failure with another.

A strong answer checks compatibility and identifies the smallest justified change. If an application rollback is safe, what will confirm recovery? If it is unsafe, can the team disable the affected feature, restore a compatible path, or prepare a reviewed fix?

The workflow is useful because it includes the step after deployment. Agree what success should look like, observe it, and decide whether to continue or mitigate. A green pipeline alone does not establish that customers can complete their tasks.

For our scenario, a recovery check might include successful API requests and a queue that is beginning to drain. The team would also look for work that failed or was processed twice during the incident. Restoring service and reconciling the aftermath are connected responsibilities.

Ask the candidate to leave a short decision note: what they changed, why, what they observed, and what still needs investigation. That tests whether another engineer could take over the incident without starting again.

Use one broken health check to explore practical understanding

Show a liveness check that fails whenever an external dependency becomes slow. What happens if Kubernetes keeps restarting an otherwise functioning container while that dependency remains unavailable?

The restart may add disruption without repairing the dependency. The candidate should discuss what the application can recover from itself and which check is meant to represent which condition.

The Kubernetes probe documentation distinguishes these roles. Readiness influences whether a Pod receives traffic through Services; liveness can trigger a container restart; a startup probe can give a slow-starting application time before the other probes take over.

Ask the candidate to connect that behaviour to the fictional API. Discuss whether an instance should accept traffic during warm-up and how it should handle requests already in progress during shutdown. For the worker, ask when a message should be acknowledged so that failed processing does not silently lose work.

You do not need exact configuration thresholds from memory. You do need an explanation of what the checks mean, what a failure causes, and how the team would test the behaviour.

Review a change before asking someone to apply it

Next, provide a small infrastructure plan that replaces a stateful resource and broadens a cloud permission. Ask the candidate to review it as if a colleague had proposed it for tomorrow’s release.

They should notice the replacement and ask why it is required. They should also ask what data or availability might be affected, who approves the change, and whether the recovery path has been exercised. “We have a backup” is a starting point, not proof that the service can be restored.

If Terraform is part of the role, ask who can read its state and plan files. HashiCorp’s guidance explains that these files can contain sensitive values. Marking a value sensitive hides it in certain displays; that label alone does not keep it out of stored state.

Bring the same question to deployment credentials. The developer, the build workflow, and the application are different identities with different jobs. Ask which one needs production access and how tightly that access can be scoped.

GitHub Actions’ OIDC documentation describes obtaining short-lived cloud tokens through a configured trust relationship. In an interview, follow up on the allowed repository, branch or environment, and cloud role. Naming OIDC is less useful than explaining which workflow may use which permission.

Keep all artifacts synthetic. The candidate can demonstrate sound access judgment without seeing a real secret or receiving a privileged account.

Connect monitoring to the customer’s problem

Return to the incident timeline. The API’s CPU is high, but the most urgent question is whether people can use the product. Ask which signal should wake an engineer and what that engineer could do in response.

CPU can help diagnose a problem. A sustained fall in successful customer requests describes the impact more directly. A useful alert connects the symptom to an owner, relevant context, and a response path.

The Google SRE Workbook’s alerting chapter explains how service objectives and error-budget burn can inform alerts, including the complications of low-traffic services. You can discuss that reasoning without expecting a candidate to memorise its example thresholds.

For instance, if an example objective allows a 0.1% error fraction and the observed fraction is 1%, the error budget is being consumed at ten times the allowed rate, using the same event definition. Whether that should page someone depends on duration, traffic, and the team’s response policy.

Then ask who maintains the dashboard and the runbook after the interview scenario ends. Monitoring becomes useful operational knowledge only when someone keeps its definitions and instructions aligned with the service.

Score five areas of evidence

By now, you have seen how the candidate investigates, changes a system, checks access, and communicates. Record those observations using the same criteria for every candidate.

The following weights are illustrative. Give each area a zero-to-four rating, then scale it by the weight. A three-out-of-four rating in a 20-point area contributes 15 points.

Write notes independently before the panel compares scores. Discuss an observation such as “checked schema compatibility before proposing rollback.” That is easier to evaluate fairly than an impression that someone sounded confident.

Use the total to organise the discussion, not make the decision automatically. If the role owns releases, a serious gap in release judgment needs its own discussion even when the candidate is strong elsewhere. A junior automation role may have a narrower boundary and a named senior reviewer.

Carry the interview into a clear first assignment

The interview should leave you with a clearer picture of both the candidate and the job. If your team could not answer who approves a release or who covers an incident, resolve that before expecting a new hire to own it.

A useful first assignment could be one reviewed deployment path with a known build artifact, scoped workflow identity, explicit rollback conditions, and a rehearsed failure in a test environment. Another engineer should be able to follow the resulting instructions.

If you need a person to join an existing team, AppZime’s IT staffing services provide a starting point for discussing that responsibility. If the requirement is a broader implementation, explore DevOps and cloud services with the same ownership questions in view.

Bring your release path, one representative incident, and the gaps you want the role to close to a scoping conversation with AppZime. You will have a clearer brief—and a much better interview—than a tool checklist can provide.

Sources reviewed on 18 October 2026. The incident, interview timings, and scoring weights are illustrative.