All jobs / Engineering manager / tech lead
Team Design interview questions
Team Design 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.
You hand a piece of work to a developer. What do you actually hand over?
The strongest answer: The outcome, the constraints, and what they may decide alone, plus an agreed check-in — not a list of steps
Why it works: Exactly. Delegate the problem and the decision rights, then check in on purpose.
- Delegate outcome and constraints.
- Say what they may decide alone.
- Agree the check-in.
- Do not redo it in secret.
What does it actually mean to say “this team owns that service”?
The strongest answer: They carry the pager for it, decide how it changes, keep it healthy and supported, and are who other teams ask — and they have the capacity and the mandate to do all four
Why it works: Exactly — pager, direction, health and answers, plus the capacity to do them. Ownership without capacity is only a label.
- Pager, direction, health, answers.
- Ownership needs capacity.
- More than a repository.
- Not a name to blame.
Only one person understands the billing module. What do you do?
The strongest answer: Pair others onto billing tickets deliberately, accept it is slower for a while, and get the essentials written down as we go
Why it works: Exactly. Silos are dismantled by shared work, and you pay the slowdown on purpose.
- Pair people onto the silo.
- Pay the slowdown deliberately.
- Write as you learn.
- Do not optimise for today’s speed.
The team brings you every small decision. How do you change that?
The strongest answer: Make decision rights explicit, push reversible decisions down to whoever is closest, and coach with questions instead of answers
Why it works: Exactly. Name who decides what, and answer questions with questions until they stop needing you.
- Explicit decision rights.
- Reversible calls go down.
- Coach with questions.
- Do not enjoy being the bottleneck.
A team of twelve is getting slow. How do you split it?
The strongest answer: Along product or domain boundaries so each team can ship on its own, involve the team in the shape, and name a lead for each
Why it works: Exactly. Split for independent flow, with the team’s input and clear ownership.
- Split by domain, not layer.
- Each team can ship alone.
- Involve the team.
- Name the leads.
How should an internal platform team operate?
The strongest answer: As a product team with the other teams as customers: a paved road people choose because it is better, measured by adoption and the toil it removes
Why it works: Exactly. Paved road, chosen not forced, measured by adoption and removed toil.
- Platform is a product.
- Paved road, freely chosen.
- Measure adoption and toil removed.
- Not a gate, not a mandate.
A senior engineer who built most of the payments system has given two weeks’ notice.
How do you spend the two weeks?
The strongest answer: Rank what only they know by risk, pair people onto the riskiest parts, record walk-throughs, and accept that some knowledge will be lost
Why it works: Exactly. Triage by risk, transfer through pairing, and be realistic.
- Triage knowledge by risk.
- Pair, do not just document.
- Record walk-throughs.
- Accept some loss.
What principles guide how you design an engineering organisation?
The strongest answer: Teams aligned to value streams or domains they can own end to end, minimal handoffs, clear ownership, and an awareness that the org shape becomes the system shape
Why it works: Exactly. Ownership, flow, and an eye on Conway’s law.
- Align to value streams.
- Minimise handoffs.
- Clear ownership.
- Org shape becomes system shape.
An old service nobody owns breaks every few weeks. Three teams touch it, and each says it is not theirs.
How do you settle it?
The strongest answer: Decide whether it still matters: if it does, hand it to the closest team with the capacity and a proper handover; if it does not, set a retirement date and a migration off it
Why it works: Exactly — owned with capacity and context, or retired with a date. Drifting unowned is the only option that is not a decision.
- Own it or retire it.
- Ownership comes with capacity.
- Do a real handover.
- Retirement needs a date.
How do you approach succession for key roles in your organisation?
The strongest answer: Identify who could grow into each critical role, give them stretch and visibility now, and make sure critical knowledge is shared before anyone leaves
Why it works: Exactly. Grow successors on purpose and remove single points of failure.
- Name likely successors.
- Stretch them now.
- Share critical knowledge.
- No indispensable people.
How do you build your leadership team?
The strongest answer: Complementary strengths rather than copies of me, clear decision rights between them, and an operating cadence where they work as a team rather than only through me
Why it works: Exactly. Complementary, clear, and a real team rather than a hub and spokes.
- Complementary, not copies.
- Clear decision rights.
- A team, not spokes.
- No yes-people.
Engineering is growing from twenty to eighty people this year. What do you put in place?
The strongest answer: Structure just ahead of need — levels, a first layer of managers, lightweight decision processes — while protecting the things that made twenty people work
Why it works: Exactly. Just-in-time structure and deliberate protection of what already works.
- Structure just ahead of need.
- Levels and first-line managers.
- Protect what works.
- Hire at a pace you can onboard.
Your company has acquired a smaller one with its own engineering team and technology stack.
How do you approach the first six months?
The strongest answer: Keep their system running and their team whole, learn what is actually good, integrate deliberately at the seams, and decide the long-term shape on evidence
Why it works: Exactly. Stability, respect, learning, then deliberate integration.
- Keep it running, keep the team.
- Learn what is good.
- Integrate at the seams.
- Decide the shape on evidence.