All jobs / Engineering manager / tech lead
Metrics interview questions
Metrics questions a Engineering manager / tech lead can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What does “lead time for changes” measure, exactly?
The strongest answer: How long a change takes to go from committed to running in production — the whole path, including review, pipeline and waiting, not the time somebody spent typing it
Why it works: Exactly — commit to running in production, so all the waiting is inside it, and that is usually where most of it sits.
- Commit to running in production.
- Waiting counts.
- It is a team metric.
- Not a stopwatch on people.
Which delivery metrics do you look at, and what for?
The strongest answer: Lead time, deployment frequency, change-failure rate, and time to restore — as a team-level trend we discuss, never for ranking individuals
Why it works: Exactly. Flow and stability metrics belong to the team and guide the system, not the appraisal.
- Flow and stability, at team level.
- Trend, not target.
- Never per-person.
- Never for ranking.
A director asks you for velocity per engineer so they can compare your team with another one.
How do you respond?
The strongest answer: Explain that points are a local unit only that team can compare, and that per-person they get gamed; then offer what does travel — team flow and stability trends, and what actually shipped
Why it works: Exactly — the unit does not travel between teams, per-person turns it into a target, and there are honest metrics to offer instead.
- Points are local, not comparable.
- Never measure them per person.
- Offer team flow and stability.
- Show what actually shipped.
What does change failure rate actually count?
The strongest answer: The share of deployments to production that degrade service and need something done — a rollback, a hotfix, a patch — measured against deployments, not against tickets or bugs found in test
Why it works: Exactly — deployments needing remediation over deployments, which is what keeps it comparable as release volume changes.
- Failed deployments over deployments.
- Remediation: rollback, hotfix, patch.
- Deployments are the denominator.
- Never per person.
Which quality metrics do you actually use with your team?
The strongest answer: Defects that reach users, each recorded with the stage that should have caught it, alongside change failure rate — read as a trend with the team rather than as a target to hit
Why it works: Exactly — an escaped defect plus where it should have been caught points straight at the check to strengthen.
- Count what reaches users.
- Record where it escaped.
- Read it as a trend.
- Never per developer.
A whole team is delivering slowly, but nobody on it seems weak. What do you look at?
The strongest answer: The system around them: dependencies, work in progress, unclear requirements, review queues, tooling — before I look at any individual
Why it works: Exactly. Slow teams are usually a system problem wearing people’s faces.
- Look at the system first.
- WIP, dependencies, clarity.
- More people is not more flow.
- Do not rank your way out.
You run several teams. What tells you one of them is in trouble, before somebody resigns?
The strongest answer: On-call load and the share of unplanned work, how long changes wait, whether problems get raised in the open, who never takes leave — read together and checked in 1:1s, never as one score
Why it works: Right — load, flow, safety and leave, cross-checked with what people actually say; no single number carries that.
- Watch load, flow, safety, leave.
- Read the signals together.
- Confirm them in 1:1s.
- No single team score.
Your dashboard shows fewer incidents this quarter than last, but each one now takes far longer to resolve.
Which number do you take to leadership, and what do you do about it?
The strongest answer: Both, and I say what they mean together: users feel total time down, so the rising restore time is the real problem — usually diagnosis, ownership or access, and that is where I dig
Why it works: Right — the pair tells the story, and a rising restore time points at diagnosis, ownership or access rather than at effort.
- Report the pair, not the flattering one.
- Total time down is what users feel.
- Ask why restoring got slower.
- Look at diagnosis, ownership, access.
An exec puts two teams’ DORA numbers side by side and asks why the payments team is behind the web team.
What do you say?
The strongest answer: Deployment frequency, lead time for changes, change failure rate and time to restore service describe a team against its own trend — payments deploys into a regulated path, so compare each team with itself
Why it works: Exactly — name the four metrics, then insist each team is read against its own trend and its own constraints.
- Compare a team with itself.
- Name the four metrics precisely.
- Explain the constraint.
- Never rank teams on them.
How do you use delivery metrics across an organisation?
The strongest answer: As trends each team watches for itself, paired with the outcomes the work was meant to achieve — never as a league table between teams
Why it works: Exactly. Per-team trends, paired with outcomes, never a league table.
- Trends, per team.
- Pair with outcomes.
- No targets on the metrics.
- Never a league table.