PeoplePractitioner8 min read27 October 2026

How do you interview an observability engineer?

A short, structured hiring process for observability and reliability profiles: the steps, questions by theme with what a good answer looks like, an incident diagnosis exercise and an evaluation grid.

For: team managers · engineers and SREsPrerequisites: Having a job description; see [How do you write a job description?](/en/people/job-descriptions/).

Reading mode

Illustrative scenario. A brilliant speaker spends an hour explaining the architecture of an observability platform. The team is won over. Three months later, at the first serious incident, this new hire suggests adding a tool rather than reading the traces already available. Nobody had seen them diagnose anything during hiring.

This page proposes a process that shows the person at work. It follows Which profiles should you hire? and How do you write a job description?.

Why structure the interview

A structured interview asks every candidate the same questions and scores them with a grid written in advance. A meta-analysis by Sackett and colleagues (2022), which revisits decades of hiring studies, ranks the structured interview first among methods for predicting success in the job. The free conversation, where each interviewer asks their own questions, does markedly worse.

Structure has two other benefits. It makes candidates comparable. It also makes the decision explainable, which matters legally: in France, assessment methods must be relevant to the job and the candidate must be told about them (articles L1221-8 and L1221-9 of the Labour Code, on Légifrance).

The process in four steps

Step	Length	Who	What we look for
1. Discovery call	30 min	the manager	motivation, fit with the problem described in the job description, conditions (on-call, pay)
2. Hands-on exercise	60 to 75 min	two team members	the diagnosis approach and communication during an incident
3. In-depth interview	45 to 60 min	the manager and someone from a neighbouring team	past experience, design, how to get a practice adopted
4. Decision and answer	within ten days	the manager	a decision argued on the grid, feedback to the candidate even when declining

I advise against take-home assignments that take more than two hours. They filter out the candidates with the least free time, often those with family responsibilities, without measuring anything more than a one-hour exercise.

The diagnosis exercise

This is the step that best separates profiles. The principle: the candidate gets access to a demo environment, or to screenshots prepared in advance; they then diagnose an incident out loud. Two team members play colleagues: they answer questions, give hints if the candidate is stuck and do not judge on the spot.

A sample scenario

Illustrative scenario, to adapt with your own tools. Since 2 p.m., the error rate of the payment page has gone from 0.1% to 4%. The candidate has:

a dashboard with error rate, latency and throughput per service;
about thirty traces of failed and successful requests;
logs from the payment service and the database;
the history of the day’s deployments.

The cause, prepared in advance: a deployment at 1:55 p.m. reduced the size of the database connection pool. Under the afternoon load, some requests wait for a connection and then fail. The traces show it through an abnormally long connection-wait span; the logs contain a timeout message; the deployment is visible in the history.

A demo environment can be built with the site’s labs or the OpenTelemetry demo application, which lets you inject failures.

What we observe

What we observe	Weak signal	Strong signal
Starting point	opens everything, in no order	starts from the user symptom (the error rate) and looks for when it began
Hypotheses	jumps to a conclusion	states a hypothesis, says how to check it, checks it
Use of signals	stays on a single signal	moves from metric to trace to log, each for a reason
Recent changes	does not think of them	asks what changed around 2 p.m.
Communication	works in silence	says what they are doing, what they ruled out and what they do not know
Recovery	only proposes the root cause	first proposes to recover (roll back the deployment), then to fix
Follow-up	stops at the cause	proposes an alert or a safeguard for next time

A candidate who does not find the cause but shows a solid approach is often a better hire than one who guesses it without being able to explain it.

Questions by theme

The following questions are for the in-depth interview. Pick four or five depending on the profile and ask the same ones of every candidate. For each, the right column says what a good answer looks like.

Theme	Question	What we expect
Incident experience	“Tell us about an incident you helped resolve. What did you do, in order?”	a precise timeline, own part separated from the team’s, what was learned afterwards
Signals	“When do you use a metric, a trace, a log?”	concrete examples; the idea that the metric alerts, the trace locates and the log explains, without dogma
Alerts	“An alert wakes the on-call three times a week and nobody ever acts. What do you do?”	remove or change it, measure before and after, talk with the team concerned
SLOs	“How would you set the reliability objective of a payment service?”	start from what users experience, negotiate with product, link the objective to the error budget and the decisions it triggers
Cost	“The metrics bill doubled with flat traffic. Where do you start?”	find the metric and the label that exploded, then their owner (see who is growing the bill)
Design	“How would you instrument a new service so it can be diagnosed from day one?”	shared conventions, context propagation, a few user-facing metrics rather than measuring everything
Adoption	“A team refuses to instrument its code: ‘no time’. What do you do?”	understand why, show a concrete gain on their own service, lower the effort (libraries, templates) rather than impose
Post-mortem	“How do you run a post-mortem after a human error?”	look for what made the error possible, not for a culprit; actions that are followed through (see the blameless post-mortem)
Limits	“Tell us about a technical decision you regret.”	a real, owned mistake and what it changed in how the person works

For an AI observability profile, add a question on measuring quality: “How would you know an assistant answers worse this week than last week?” We expect evaluations on a reference question set, tracking of user feedback and the idea that a success code says nothing about whether an answer is correct.

The evaluation grid

Each assessor scores alone, right after their step, before any discussion. A four-point scale, with no middle, forces a decision.

Criterion	1: insufficient	2: to develop	3: solid	4: outstanding
Diagnosis approach	no visible method	a method, applied with help	hypotheses stated and checked alone	clear method, explains why each lead is ruled out
Use of signals	a single signal used	several signals, unconnected	moves between signals for good reasons	can also say what is missing in the instrumentation
Communication	silence or jargon	explains when asked	explains along the way, says what they do not know	makes themselves understood by a non-specialist
Reliability and SLOs	vague notions	knows the notions	can write an SLO and its alert	links SLOs, error budget and product decisions
Getting things adopted	imposes or gives up	convinces with help	can convince a team	has already changed the practices of several teams
Fit with the role’s problem	unrelated	partial	addresses the problem described	brings an idea the team did not have

The decision is then made in a short meeting, grids on the table. A score of 1 on a criterion marked essential in the job description is enough to say no, whatever the others.

What not to ask

In France, questions must have a direct link with the job (article L1221-6 of the Labour Code). No questions on family situation, pregnancy plans, age, origin, health, opinions or union membership (article L1132-1 for the list of grounds). For on-call, describe what it involves and ask whether the candidate can take it on; do not ask why.

After the decision

Answer every candidate you interviewed, including when declining, with two or three sentences of feedback drawn from the grid. The observability world is small: a candidate declined properly speaks well of you; one left without an answer speaks too, the other way round.

Going further

How do you get the first 90 days right?: what comes next, once the person is hired.
The job description generator: an interview plan tailored to the profile and level.
Revisiting meta-analytic estimates of validity in personnel selection: Sackett, Zhang, Berry and Lievens, Journal of Applied Psychology, 2022.