All jobs / Engineering manager / tech lead
Technical Leadership interview questions
Technical Leadership 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 were the fastest developer on the team and were just made tech lead.
How much should you code now?
The strongest answer: Less, and off the critical path — small tickets and reviews so I can be interrupted to unblock people without holding a release
Why it works: Exactly. Stay technical, but never be the person a release is waiting on.
- Code, but off the critical path.
- Be interruptible.
- Do not hoard the hard tickets.
- Do not vanish from the codebase either.
A developer asks why the team has coding standards at all. What do you tell them?
The strongest answer: So any of us can read and change any file: reviews then argue design, not style. We agree them as a team and let a formatter and linter enforce what they can
Why it works: Exactly — shared readability and cheaper reviews, with anything mechanical enforced by a tool rather than a person.
- Shared readability, enforced by tools.
- Agree them with the team.
- Automate format and lint.
- Review design, not style.
A senior developer pushes a technical approach you doubt. What do you do?
The strongest answer: Ask them to lay out the trade-offs against the alternative, agree what would make it wrong, and if it is reversible let them own the call
Why it works: Exactly. Make the trade-offs explicit and let reversible decisions be owned by the person closest to them.
- Surface the trade-offs.
- Agree what would prove it wrong.
- Reversible calls go to the owner.
- Never undo a decision quietly.
A developer wants a week to refactor a module. What do you say?
The strongest answer: Ask what pain it removes and what it unblocks, size it, and put it on the board next to the product work so the trade is visible
Why it works: Exactly. Debt work is real work; make its value and cost visible and prioritise it honestly.
- Ask what pain it removes.
- Size it and make it visible.
- Prioritise next to product work.
- Do not hide it in a feature.
How do you make room for technical debt alongside features?
The strongest answer: An explicit, visible share of capacity agreed with product, spent on the debt that causes the most pain or blocks the roadmap
Why it works: Exactly. Debt work is a negotiated, visible investment tied to actual pain.
- Explicit, visible capacity.
- Agree it with product.
- Target the debt that hurts.
- Never hide it.
The team is split on how to structure a new service. How do you get to a decision?
The strongest answer: Write the options with their trade-offs and context, timebox the discussion, name who decides, and record the decision so we can revisit it
Why it works: Exactly. Written options, a decider, a timebox, and a record.
- Write options and trade-offs.
- Timebox and name the decider.
- Record the decision.
- Not a vote, not a shouting match.
How do you run a design review so the hour is worth it?
The strongest answer: The document goes out a day before with the problem, the constraints and the options; the hour is for questions and risks, and it ends with a decision, an owner and what was rejected
Why it works: Exactly — pre-read, constraints on the page, and a decision with the discarded options written down.
- Pre-read, then decide.
- Send problem and constraints early.
- Spend the room on risks.
- Record decision, owner, rejected options.
The team wants to rewrite the core service from scratch. How do you respond?
The strongest answer: Understand the pain concretely, then favour an incremental path — replace behind a seam piece by piece — and decide on evidence about risk and value
Why it works: Exactly. Name the pain, prefer incremental replacement, and decide on evidence.
- Understand the pain first.
- Incremental over big bang.
- Decide on evidence.
- Never freeze the business.
You have taken over a team where reviews are rubber stamps, the style argument reopens weekly, and bugs keep reaching users.
How do you raise code quality without stopping delivery?
The strongest answer: Agree with the team what quality means here, automate the mechanical part in the pipeline, make reviews about design and risk, and start with the two areas the bugs actually come from
Why it works: Right — quality is a system: an agreed standard, automated checks, reviews spent on design, and the worst areas first.
- Build quality into the path.
- Agree the standard with the team.
- Automate what a tool can check.
- Start where the bugs come from.
What belongs in a technical strategy for your area?
The strongest answer: Where we are and what hurts, where the business is going, a few principles, and the small number of bets we will make and not make
Why it works: Exactly. Diagnosis, direction, principles, and a few explicit bets.
- Diagnose where you are.
- Tie it to where the business goes.
- Few bets, explicitly.
- Say what you will not do.
How do you manage technical debt at organisation level?
The strongest answer: An inventory of the debt that matters with its risk and cost, tied to business outcomes, an explicit share of the portfolio, and a story executives can understand
Why it works: Exactly. Inventory, business link, explicit share, executive-readable.
- Inventory with risk and cost.
- Tie to business outcomes.
- Explicit portfolio share.
- Tell the story upward.
A new class of developer tooling has appeared and several teams want to adopt it immediately.
How do you handle it?
The strongest answer: Pilot it with a couple of willing teams under clear guardrails, define what we would observe if it helped, and then decide on what we actually saw
Why it works: Exactly. Pilot, guardrails, agreed evidence, then decide.
- Pilot with willing teams.
- Guardrails first.
- Agree what evidence counts.
- Decide on what you saw.