Tech Lead Interview: The Leadership Round, Technical Decisions and Mentoring

I’ve sat on both sides of the interview table for Tech Lead and Lead Engineer roles, frontend and fullstack. The most familiar scene: the candidate writes clean code and has solid system design, but when the leadership round comes they answer as if solving a coding problem. They hand over the “right answer”. No context. No option they turned down. No cost.

This round doesn’t ask what you know. It asks something else: when everything falls apart at 2 a.m., will other people trust your judgment?

A few of the stories below are composite scenarios, not tied to any particular company or person. The numbers are only there to show how to present things.

1. What leadership interviewers are actually looking for

After many sessions on both sides, I find every leadership question boils down to five signals:

1. Ownership: when there’s a problem, do you say “I” or “they”?
2. Judgment under uncertainty: how do you decide when you’re missing information?
3. Influence without authority: a Tech Lead is often not a manager, so what do you use to persuade people?
4. Multiplying the team’s output: do you make others better, or turn yourself into a bottleneck?
5. Self-awareness: can you tell a story about a time you were wrong?

Once you have those five, your answers find their own direction: each story you bring should prove at least one signal.

2. STAR, but with numbers

STAR (Situation, Task, Action, Result) is so familiar that everyone knows it, yet most people tell it flat: 70% of the time goes to Situation and Result, and the Result is vague, like “the outcome was that everyone was happy”. I tweak it a little:

S - Situation (2 sentences max): how many people on the team, what constraints
T - YOUR responsibility (not the team's)
A - Action (~60% of the answer): what you weighed, which option you dropped, and why
R - Result with a measurement: before / after, plus the cost you paid
L - Lesson: what you'd do differently next time

Two places I look at hardest:

• The “A” part must include a rejected option. “I considered A and B, chose B because…” is judgment. If you just say “I did B”, there’s nothing to grade.
• The “R” part must have a number, or if you can’t measure it, say clearly how you judged it. “Average review time went from 2 days to under 1 day” is far more concrete than “reviews got faster”. But don’t make up numbers. A good interviewer will immediately ask “how did you measure that”, and a number with no source collapses on the spot. If you don’t have an exact figure, saying “I estimate about… based on…” still beats inventing one.

Before the interview, I write down 6-8 real stories, each tagged with a few themes. One incident can serve incident ownership, disagreement and a failure lesson all at once. Learn the backbone of each story. Don’t memorize every sentence.

3. ADRs and trade-offs: writing down how you decided

The typical question: “Tell me about a hard technical decision you led.” The maturity isn’t in what the decision was. It’s in how you recorded and communicated it.

The ADR (Architecture Decision Record) is the thing I bring up most in this situation. One page, usually with these sections:

# ADR-014: Choosing a cache strategy for catalog data

Status:     Accepted (2026-xx-xx)   Decision maker: <name/role>
Context:    The problem, the constraints, the numbers we have
Options:    A) ...   B) ...   C) Do nothing
Decision:   Choose B, because ...
Trade-off:  Accept ... in exchange for ...
Consequences: Follow-up work, remaining risks
Revisit when: If <metric> exceeds <threshold>, reopen the decision

When I hear a candidate talk about ADRs, I watch for three things:

• “Do nothing” is on the options list. Whoever writes it down knows every change has a cost.
• There’s a condition for revisiting, saying up front when this decision stops being right.
• Sorting by reversibility. A “two-way door” is something easy to change back, like choosing an internal library: decide fast, few meetings. A “one-way door” is hard to undo, like picking a database or a public data format: spend the time, gather input, write the ADR.

The two branches differ in how they spend time:

flowchart TB
  Q["A technical decision to make"] --> R{"Can we go back?"}
  R -- "Yes: internal library" --> T1["Two-way door<br/>decide fast, few meetings"]
  R -- "Hard: database,<br/>public data format" --> T2["One-way door<br/>take time, gather input, write an ADR"]

And here’s a short framework for answering “how do you make decisions”:

Step	Question to ask yourself
Define the problem	Is this really the problem to solve, or a symptom?
Gather facts	Is there data, a prototype, a quick spike that reduces uncertainty?
List options	Do we have at least two real options, including “do nothing”?
Trade-offs	Cost, risk, reversibility, impact on the team?
Decide and communicate	Who needs to be consulted, who is affected, where is it recorded?
Measure and revisit	Which metric tells us we were right or wrong?

A weak answer: “I chose technology X because it’s new and fast.” A strong answer: “I chose X even though the team wasn’t familiar with it because the cost of reversing was low, I limited it to one module as a trial, and set evaluation criteria for after two sprints.”

4. Disagreement: understand first, push back second

“Tell me about a time you disagreed with a coworker or your boss.” People tend to swing to one of two extremes on this one: “I convinced them” sounds domineering, and “I let it go” sounds like having no opinion.

I tell it in this order:

1. Understand the other side’s view first. “I asked to understand why they preferred that solution, and found they were worried about the deadline, while I was worried about maintainability.”
2. Move the argument from opinions to criteria. Agree on the evaluation criteria first (latency, operating cost, delivery time), and only then compare options.
3. Use facts instead of authority: a small spike, a benchmark, a time-boxed experiment.
4. Disagree and commit. If the decision doesn’t go your way, you still do it seriously and record the conditions for revisiting. What you need is for the final decision maker to know your concern clearly.
5. Keep the relationship. When the work is done, you still sit down together as usual.

A composite example: two engineers argued over whether to split a module into its own service or keep it in the monolith. The lead suggested both write down three success metrics, run a two-day spike for each direction, then decide based on the results. In the end they kept the monolith and wrote an ADR stating the load threshold at which they’d split. The person who had objected was put in charge of tracking that threshold. The one who “lost” still had a stake in the outcome.

A related trap question: “What if your boss makes you do something you think is wrong?” The safe and honest answer: present the risk with facts, propose an alternative or a risk mitigation, and if the decision stands, carry it out while recording the risk. Only when it touches ethics, safety or legal issues is it a red line to escalate or refuse.

5. Tech debt: speak in the language of risk

“How do you handle tech debt when product always wants more features?” Poor answer: “I ask for refactoring time.” A workable answer: translate tech debt into risk and cost, because that’s the only way it gets prioritized.

How I categorize it:

Type of debt	Example	How to handle
Deliberate, planned	A shortcut to hit a milestone, ticket already filed	Put in the backlog with a specific deadline
Accidental, from lack of knowledge	A weak design	Mentoring, review, documentation
Bit rot	Old libraries, missing tests	Steady, in small doses
Security/stability risk	A vulnerable dependency, no monitoring	High priority, present it as a risk

What I’ve found works:

• Make debt visible. A debt list with owners and impact descriptions (how much it slows things down, what kind of bugs it causes), not just “bad code”.
• Convert it into business impact. “This module adds about 2-3 days to every related feature and is the source of most recent regression bugs” is far more convincing than “the code is hard to read”.
• Set aside a fixed budget instead of asking each time. For example, agree on a share of each sprint’s capacity for internal improvement, settled with product from the start. The number depends on the team, but the principle is transparency and stability.
• Pay debt down alongside work you’re already doing (the boy scout rule): touch a module, clean up the related parts. Avoid big refactoring projects not tied to value.
• Know when NOT to pay. Code that’s rarely touched or about to be replaced isn’t worth fixing.

Red flags in a candidate: treating all debt as something that must be paid, or proposing to “stop features for two months and rewrite”. Both are off balance between engineering and business.

6. Mentoring: pulling a mid up to senior

This is where a Tech Lead differs from a strong senior. The question: “How have you helped someone grow to a higher level?”

The mid-to-senior gap is less about pure technical skill. It’s about the scope of impact and autonomy. A mid does assigned work well. A senior decides what work needs doing, manages risk, and lifts the people around them.

The path I usually describe:

Mid  ->  Senior
 │         │
 ├─ Assign work with steadily growing scope: task -> feature -> small system
 ├─ Let them write the design doc, then review it together, don't write it for them
 ├─ Let them lead a review/sharing session, a small incident (with support)
 ├─ Specific, timely feedback based on observable behavior
 └─ Agree on clear goals and promotion criteria

A few principles I stress when answering:

• Assign work with a bit of stretch, plus a safety net. Too easy and they don’t grow. Too hard with nobody to catch them and they lose confidence.
• Ask questions instead of handing over answers. “What options have you considered?” trains trade-off thinking, which is what a senior needs.
• Give feedback as behavior, impact, suggestion. For example: “In yesterday’s PR you skipped the empty-list case (behavior), so the screen went blank in production (impact). Next time try listing the edge states before writing code (suggestion).” Talk about the work, not the person.
• Regular 1:1s, with the mentee setting the agenda.
• Mentoring success is measured by you gradually becoming less necessary. If every decision still has to go through you, you’re creating dependence, not capability.

A trap question: “What if someone on the team never improves?” The mature answer: clarify expectations, look for the cause (lack of skill, lack of motivation, lack of context, personal issues), agree on an improvement plan with concrete milestones, and coordinate with their manager. Don’t avoid it or “quietly do their work for them”.

7. Code review: where culture shows first

If you want to know a team’s engineering culture, reading their code reviews is faster than reading any document. The question: “How do you build a review culture?”

Practices I use:

• Distinguish the severity of comments. For example, a prefix convention: blocker: (must fix), suggestion: (worth considering), nit: (minor detail, doesn’t block merge), question: (asking to understand). With prefixes, arguments over small details drop sharply.
• Automate whatever a machine can do: formatting, lint, type check, tests. People review design, correctness and maintainability, not semicolons.
• Small PRs. The bigger the PR, the worse the review quality. Many teams set a reasonable size convention and encourage splitting PRs.
• A review response SLA. For example, commit to a first response within one working day, so review doesn’t become a bottleneck.
• Review is two-way teaching and learning. Leads also get comments from more junior people, and how a lead takes them shapes the culture.
• Praise specifically. “The way you split this function made the tests much easier to write” is valuable feedback too.
• Tone: comment on the code, not the person. “This could cause a race condition when two requests arrive at once” instead of “you wrote this wrong”.

A trap question: “A senior colleague regularly merges without waiting for review. What do you do?” Talk to them privately first to understand why (it might be because reviews are slow), then use protected-branch rules that apply to everyone, not aimed at one person.

8. Estimates and negotiating scope with product

“Product wants it done in 4 weeks but you estimate 8. What do you do?” This question shows whether a Tech Lead is a partner to product or just someone who takes orders.

Two broken answers: nod and let the team work overtime, or flatly refuse. The approach I use:

1. Understand the goal behind the deadline. Where does the 4-week limit come from: an event, a contract, or just a guess? What business outcome do they actually need?
2. Estimate with a range and confidence, not a single number: “best case 5 weeks, likely 7 weeks, with the assumptions and biggest risks”.
3. Split the scope into tiers:

Must-have   : enough to hit the core business goal
Should-have : adds value but can come later
Could-have  : nice to have, first to be cut when late

4. Offer choices instead of only offering obstacles: “In 4 weeks I can deliver parts A and B at full quality. Part C needs 3 more weeks. Or if we need all three, we can reduce the scope of B, or add people but they’ll need time to pick up the context.”
5. Deliver in thin slices (incremental delivery) so product sees real progress and the risk isn’t all pushed to the end.
6. Track and update early. If an assumption turns out wrong, say so right away, don’t wait until the deadline is close.

Estimates are mostly wrong because of invisible things: review, testing, deployment, integration, sick days, meetings. If you can name those, the listener knows you’ve been in the trenches. And estimation always carries uncertainty. A lead’s job is to manage that uncertainty openly, not to pretend it away.

9. Incident ownership: telling the story properly

“Tell me about a production incident you handled.” A good story usually has three phases:

During the incident : reduce impact first (rollback, turn off a feature flag), communicate clearly
After the incident  : blameless post-mortem, find the systemic root cause
Long term           : preventive actions with owners and deadlines, and a check that they got done

The things that earn points:

• Restore service first, find the cause later. Roll back first, investigate after.
• Clear roles in the incident: one coordinator (incident commander), one person communicating with stakeholders, the rest investigating. Avoid everyone running to the same spot.
• Regular communication. Update on a fixed cadence even when there’s no progress, so outsiders don’t have to guess.
• Blameless post-mortem: ask “which system let this error through” instead of “who got it wrong”. The root cause here isn’t “the dev forgot to check” but “there was no test or alert that catches this case”.
• Concrete action items: with owners, deadlines, and tracked. A post-mortem whose action items never get done is just for show.
• Taking responsibility. If the incident came from a decision of yours, say so directly. Many candidates lose points here by turning the story into “I rescued everything” and forgetting to say who started the cause.

10. A roundup of trap questions

• “What’s your biggest weakness?” Pick a real one that doesn’t hurt the role (not “I’m too much of a perfectionist”), along with how you’re improving. For example: “I tend to do the hard work myself instead of delegating it. I’m practicing delegating earlier and accepting the cost, which is that the work goes slower at first.”
• “Do you prefer coding or managing?” A Tech Lead needs both. Say clearly that you keep hands-on coding at a level that’s just enough to understand the system, and spend the rest multiplying the team’s output.
• “Tell me about a failure.” Pick a real failure with consequences, say what you learned and how you changed the process. Avoid “fake” failures like “I work too hard”.
• “What if the team objects to your decision?” Listen, recheck the facts, explain the reasoning, and if you keep the decision, say clearly why and when you’ll look at it again.

11. Red flags: two sides, two lists

From the candidate’s side, here’s what the interviewer will notice:

Red flag	Why it’s worrying
Always says “I”, never “we”	Hard to work in a team, takes all the credit
Always says “they”, never “I”	Blame-shifting, lacks ownership
Bad-mouths coworkers/former company	May repeat it at the new company
No numbers or way of measuring	The story is hard to verify
Can’t tell a story about being wrong	Lacks self-awareness
Only technical stories, no people stories	Not ready for a leading role

From the company’s side, what you should watch for when you interview:

• The role description says “Tech Lead” but in practice it’s everything: code, management, DevOps, customer support, with no clear boundaries.
• The interviewer can’t describe the success criteria for the role after 6-12 months.
• A “hero” culture: every incident has one rescuer, and nobody talks about post-mortems or process.
• Vague answers about tech debt: “we don’t have time for that”.
• Too many interview rounds and nobody honestly talks about the team’s challenges.
• High turnover that can’t be explained.

12. Questions to ask back

Asking back is part of the assessment too, and it’s how you check the company itself. The list I usually prepare:

1. “What does success in this role look like at 6 months, at 12 months? How is it measured?” Shows whether the expectations are real.
2. “How was the most recent big technical decision made? Who made the final call?” To understand the Tech Lead’s real authority.
3. “How is tech debt managed right now, is there dedicated time?”
4. “Tell me about the most recent production incident and what the team learned.” The answer tells you whether the culture is blameless or blaming.
5. “What percentage of time does a Tech Lead here spend on code, review, meetings, mentoring?”
6. “What’s the process for negotiating scope and deadlines between engineering and product?”
7. “What’s the career path from this role: staying technical or moving into management?”
8. “What’s the hardest thing about this team that you’d hope a new person could help solve?” This one often gets the most honest answer.

Listen to both the content and how they answer. Hesitation or dodging is data too.

Preparation, and a few questions in return

Preparation is actually short: write down a few real stories from your own work, tie each one to one of the five signals in section 1, check every “R” to see whether you have a way of measuring it, and think ahead about the questions you want to ask back.

The person on the other side of the table is asking themselves one question too: “Do I want to work with this person at 2 a.m., when production is on fire?”