All jobs / Engineering manager / tech lead
Delivery interview questions
Delivery 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.
Product asks for an estimate for a new feature. How do you produce it?
The strongest answer: With the people who will build it: break it down together, note the unknowns, and give a range rather than a day
Why it works: Exactly. The builders estimate, and the unknowns are part of the answer.
- The builders estimate.
- Break it down, name unknowns.
- Give a range.
- Never adopt someone else’s date.
Two developers are blocked on another team’s access approval. What is your day?
The strongest answer: Unblocking them is my top priority today — I chase the approval myself and find them useful work meanwhile
Why it works: Exactly. Clearing blockers is the lead’s core work, not an interruption to it.
- Blockers are your work.
- Chase cross-team asks yourself.
- Keep people usefully busy meanwhile.
- Escalate as a step, not a reflex.
Your calendar is filling with meetings and invitations keep landing on the team too. What do you do?
The strongest answer: I take the meetings that need a team voice myself, decline or shorten the rest, and protect blocks of focus time for the team
Why it works: Exactly. You are the buffer; the team’s focus time is what you are protecting.
- Be the meeting buffer.
- Protect focus blocks.
- Decline and shorten.
- Do not add meetings for your comfort.
Your retros are quiet and end early. What do you change?
The strongest answer: Use a format where everyone writes first, then discuss the themes and leave with one concrete change we will actually try
Why it works: Exactly. Write-first formats get the quiet people in, and one real action makes it worth attending.
- Write first, then talk.
- Leave with one real change.
- It is their retro, not your review.
- Silence means fix the format.
The product manager hands you a spec with a launch date already on it.
How do you respond?
The strongest answer: Read it with them, ask what problem it solves and what is negotiable, then bring back the team’s estimate before anyone commits
Why it works: Exactly. Understand the problem, find the negotiable parts, and commit only after the team has estimated.
- Ask about the problem first.
- Find what is negotiable.
- The team estimates before you commit.
- Never give the team a fake date.
Halfway through the sprint you can see the commitment will not be met. What do you do?
The strongest answer: Tell product and stakeholders now, agree what drops, and protect the item that matters most
Why it works: Exactly. Bad news early is useful; bad news late is a surprise.
- Say it as soon as you see it.
- Re-scope explicitly.
- Protect the top item.
- Never report green you do not believe.
For the third week running, your status report says the feature is “about eighty per cent done”.
What do you do?
The strongest answer: Stop asking for a percentage: ask what works end to end today, watch it running, and turn what is left into a list of named items with an owner on each
Why it works: Exactly — a percentage hides the unfinished work; a demo and a named list make the remainder real.
- Replace percentages with evidence.
- Ask what runs end to end.
- Watch it working.
- List the remainder, with owners.
Your feature depends on another team’s API that does not exist yet. How do you manage it?
The strongest answer: Agree the interface and a date early, name an owner on both sides, build against a stub, and track it as a risk with regular check-ins
Why it works: Exactly. Contract first, owners named, stub to keep moving, and the risk visible.
- Agree the interface early.
- Owners on both sides.
- Build against a stub.
- Track it as a risk.
Product brings an urgent change mid-sprint. How do you handle it?
The strongest answer: Work out the cost of switching, swap it explicitly for something of similar size, and make the trade visible on the board
Why it works: Exactly. Urgent is fine when the trade is explicit and visible.
- Cost the switch.
- Swap, do not add.
- Make the trade visible.
- Never pass the squeeze down.
How do you make retro actions actually happen?
The strongest answer: One or two actions, each with an owner and a date, reviewed at the start of the next retro before anything new is added
Why it works: Exactly. Few, owned, dated, and reviewed.
- One or two actions.
- Owner and date.
- Review them first next time.
- Do not skip when busy.
How do you plan a quarter for two teams?
The strongest answer: Plan to real capacity — minus on-call, leave and debt — commit to a few outcomes as ranges, and leave room for what we do not know yet
Why it works: Exactly. Real capacity, few outcomes, ranges, slack for the unknown.
- Real capacity, not nominal.
- Few outcomes, as ranges.
- Leave slack.
- Stretch is not commitment.
You lead a programme spanning four teams. How do you keep it coherent?
The strongest answer: Shared milestones, agreed interface contracts between teams, one risk list, and a short regular sync of the leads
Why it works: Exactly. Milestones, contracts, one risk view, and the leads talking.
- Shared milestones.
- Interface contracts.
- One risk list.
- Leads sync, not everyone.
A six-month project has just been approved: a new billing integration, a data migration, and a user interface on top of both.
What do you do in the first two weeks?
The strongest answer: Name the assumptions that would sink it, then spend the two weeks proving the riskiest one — a thin slice through the real integration in a real environment — before the plan hardens
Why it works: Exactly — information is cheapest early, and the assumption that could kill the project is the one worth buying first.
- Buy information early.
- List the assumptions that could sink it.
- Prove the riskiest one first.
- Slice through the real thing.
How do you set quarterly goals with a team?
The strongest answer: A few outcomes the team helps write, measurable in ways we can honestly observe, connected to the company direction but translated into this team’s work
Why it works: Exactly. Few, co-written, honestly measurable, and translated rather than copied.
- Few outcomes, co-written.
- Honestly measurable.
- Translate, do not copy.
- Not tied to bonuses.
How do you build the annual engineering budget?
The strongest answer: From the strategy: what we must deliver, the headcount and non-headcount that needs, a couple of scenarios, and a reserve for what we do not know yet
Why it works: Exactly. Strategy-first, scenarios, and an honest reserve.
- Start from strategy.
- Headcount and non-headcount.
- Scenarios plus a reserve.
- Nothing hidden.
You have more initiatives than teams. How do you prioritise the portfolio?
The strongest answer: Rank by value, cost of delay and risk against the strategy, limit how many run at once, and say clearly which are stopped rather than paused
Why it works: Exactly. Explicit ranking, limited concurrency, honest stops.
- Rank by value and cost of delay.
- Limit what runs at once.
- Stop things explicitly.
- Everything is not a priority.