Interview Q&A · 40 questions · 17 answered publicly
Tech Lead Interview Questions
Ordered by how often they're asked. Sign in free to see every answer, rate your confidence and run timed mock interviews.
-
Most asked What does a tech lead do, and how is it different from an engineering manager?
Summary
A tech lead is accountable for how the team builds: technical direction, architecture and standards, delivery risk and quality — achieved through the team, not by doing all the work. An engineering manager owns people and organisation: hiring, performance, careers and team health.
Longer Answer
The two roles partner closely. A useful split: the tech lead owns technical direction, design decisions, delivery sequencing and code quality; the manager is consulted. The manager owns hiring, performance and careers; the tech lead is consulted with evidence. Product owns what and why; the tech lead is consulted on cost, risk and sequencing. In small teams one person may hold both roles — then they need protected time for each. Will Larson describes the Tech Lead as a staff archetype that "guides the approach and execution of a particular team".
Key Points
- Tech lead: technical direction, design, delivery risk, quality — through the team
- Engineering manager: people, hiring, performance, careers
- Write the split down with your manager; review it quarterly
Deep dive: What a Tech Lead Owns
-
Most asked How much should a tech lead code?
Summary
Enough to stay credible and close to the code, but not on the critical path. In practice a tech lead on a team of six to eight usually has 30–50% of their time for hands-on work, because reviews, design support, planning and cross-team work take the rest.
Longer Answer
Plan the lead at reduced capacity and make leadership work visible in planning. Keep work that maintains context without blocking the team: prototypes and spikes, tooling and developer-experience fixes, pairing as navigator, small non-urgent tickets. Give away the riskiest critical-path tickets — with support — so the lead isn't the bottleneck and others grow. Never stop coding entirely; designs reviewed by someone who no longer touches the code get worse.
Key Points
- Plan 30–50% coding capacity
- Keep prototypes, tooling, pairing; give away critical-path tickets
- Batch reviews and questions to protect focus time
Deep dive: Coding vs Leading
-
Most asked You join as tech lead of an existing team. What do you do in the first 90 days?
Summary
Listen and map for the first month, deliver one improvement the team already wants in the second, and set technical direction in the third — after you can describe the system's risks in the team's own words.
Longer Answer
Days 1–30: 1:1s with every engineer, the manager, product and key neighbouring teams, using the same questions (what's going well, what slows you down, what worries you); read recent incidents, design docs and the backlog; draw the system and a risk map. Days 31–60: fix one thing the team feels daily (flaky tests, slow deploys) together with them; share back what you heard and ask to be corrected. Days 61–90: propose two or three technical priorities tied to risks and business goals; agree them with product and the manager; publish them. Avoid proposing big changes before you understand why the current design exists.
Key Points
- Same interview questions for everyone
- One visible improvement the team wants
- Direction only after understanding constraints
Deep dive: Your First 90 Days as a Tech Lead
-
Most asked Two senior engineers have argued about an approach for weeks. What do you do?
Summary
Check whether it's a reversible decision; make sure both positions are written down with their trade-offs; set a decision date; decide (or have the owner decide) and explain why; record the minority concern as a revisit trigger; and ask everyone to disagree and commit.
Longer Answer
Often the debate is about preferences, not risks — reframe it around the problems each option solves and what evidence would change the decision. If a small experiment can settle it within days, run it. Then close: "I'm choosing B for these reasons; Tom's concern about X is our revisit trigger." Follow up privately with the person who disagreed so they feel heard. Long stalemates cost more than most wrong two-way-door decisions.
Key Points
- Write both options and trade-offs
- Decide by a date, explain the reasoning
- Record the concern as a revisit trigger; disagree and commit
Deep dive: Decision Speed: One-Way and Two-Way Doors
-
Most asked How do you keep code reviews fast without lowering quality?
Summary
Agree that reviews come before new work, with a first response within hours and never more than one business day; keep pull requests small; let any trained engineer approve outside high-risk areas; automate style; and label comments by severity.
Longer Answer
Slow reviews create a loop: authors batch work into large PRs to avoid waiting, large PRs get shallow reviews, and reviews get slower. Google's public review guide says one business day is the maximum time to respond. Remove single-person gates, reserve required reviewers for areas like ledgers, auth and migrations, and focus reviews on correctness, design, tests and security. Track time to first review as a team metric.
Key Points
- Response within hours; max one business day
- Small PRs; shared reviewing
- Automate style; label blocking vs nit
Deep dive: Code Review Standards and Speed
-
Most asked How do you manage technical debt on a team that is always under delivery pressure?
Summary
Make debt visible in a register with its cost and 'interest', prioritise debt in code you change often or that causes incidents, protect a steady budget (often 15–20% per sprint) instead of rare clean-up sprints, and report results in product terms.
Longer Answer
Clean-up sprints get cancelled when launches arrive; a steady budget survives. Bundle paydown into features that touch debt hotspots. Leave stable, rarely touched code alone. Distinguish deliberate, prudent debt — a conscious trade-off with a payback plan — from reckless debt. Show product numbers they can weigh: "test suite 25 to 9 minutes saves six engineer-hours a day", "refund changes now take two days instead of five".
Key Points
- Debt register with impact and interest
- Steady 15–20% budget; bundle with features
- Report outcomes in product terms
Deep dive: Managing Technical Debt Deliberately
-
Most asked A production incident is happening and eight engineers are on the call. What is your role as tech lead?
Summary
Establish structure: name an incident commander who coordinates but doesn't debug, an operations lead through whom all changes go, and a communications lead with a fixed update cadence — then drive towards mitigation before root cause.
Longer Answer
Without roles, people make conflicting changes and stakeholders interrupt the debuggers. Mitigate first (roll back, fail over, disable a feature), make one change at a time, announce changes before making them, and post updates every 30 minutes in one channel. The tech lead can be the commander or the operations lead, but not both. Afterwards, run a blameless postmortem with contributing factors and tracked action items.
Key Points
- Roles: commander, operations, communications
- Mitigate first; one change at a time
- Blameless postmortem with tracked actions
Deep dive: Leading Incidents and Blameless Postmortems
-
Most asked How do you grow the engineers on your team?
Summary
Know what skill each person is building this quarter and give them real work that exercises it — delegating outcomes rather than tasks, at an explicit level of autonomy, with checkpoints and pairing instead of taking the work back.
Longer Answer
Delegation isn't binary: match the level (tell, consult, agree, advise, delegate) to experience and risk. For a risky project, add checkpoints — design review, first PR, rollout plan — rather than keeping it yourself. Pair as navigator on the hardest parts. Accept different solutions that meet the outcome. Coordinate with the engineering manager so growth work feeds into career conversations and reviews.
Key Points
- Outcomes, not tasks
- Explicit autonomy level and checkpoints
- One growth skill per person per quarter
Deep dive: Mentoring and Delegation
-
Most asked Tell me about a time you made a technical decision that turned out to be wrong.
Summary
Pick a real decision with consequences, explain the context and why the choice seemed right, how you discovered it was wrong, what you did to limit the impact, and what you changed in your decision-making afterwards.
Longer Answer
Structure (STAR): Situation and Task briefly; Action in detail — how you noticed, how you communicated it, how you corrected course (e.g. a migration path, a rollback, an ADR superseding the original); Result with numbers. Close with the lesson as a change in practice: "I now prototype the riskiest integration before committing to a library", "we added a revisit trigger to every ADR". Show ownership without self-flagellation.
Key Points
- Real decision, real consequences
- How you detected and corrected it
- A concrete change in your practice
Deep dive: Decision Speed: One-Way and Two-Way Doors
-
Most asked Tell me about a time you had to push back on a deadline or scope.
Summary
Describe the request, the evidence that it wasn't achievable (throughput, risks), how you presented options rather than a flat no, and the decision that resulted.
Longer Answer
Strong answers show data and partnership: "Based on our throughput the full scope was 85% likely in 14 weeks, not 8. I offered two options: ship card payments only by the date, or full scope two months later. Product chose the reduced scope; we shipped on time and added the rest in the next quarter." Mention how you kept the relationship constructive and how the forecast was tracked afterwards.
Key Points
- Evidence, not opinion
- Options that trade scope for time
- Outcome and relationship afterwards
Deep dive: Forecasting Delivery Honestly
-
Most asked Tell me about the most complex system you designed or led.
Summary
Pick a system where you made the key design decisions; explain the problem and constraints, the main options and why you chose one, how you de-risked the rollout, and what the results and lessons were.
Longer Answer
Interviewers use this to assess depth and judgement. Cover: scale and constraints (traffic, data, compliance), the two or three decisions that mattered most and their alternatives, failure modes you designed for, how you sliced and rolled it out safely (flags, shadow traffic, migration plan), and measurable results. Be ready to go deep on any component and to say what you'd do differently.
Key Points
- Constraints and scale
- Key decisions with alternatives
- Safe rollout and measurable results
Deep dive: Design Docs and RFCs That Get Read
-
Most asked Product wants to skip tests and code review to hit a launch date. What do you do?
Summary
Make the risk concrete, offer alternatives that protect the date (reduce scope, feature flags, ship to a subset of users, temporary extra review capacity), and agree explicitly on any deliberate debt with a payback plan — rather than silently cutting quality.
Longer Answer
Explain consequences in product terms: a payments bug would cost refunds, support load and trust. Often the date can be met with a smaller scope or staged rollout. If a conscious trade-off is made (e.g. fewer end-to-end tests for a non-critical area), record it in the debt register with an owner and a date. Never skip review for high-risk areas like money, auth or migrations.
Key Points
- Translate risk into product impact
- Options that keep the date
- Deliberate debt, recorded with a payback plan
Deep dive: Managing Technical Debt Deliberately
-
Most asked Your team wants to rewrite a legacy service. How do you evaluate the proposal?
Summary
Look at evidence — where incidents and change costs concentrate — weigh the business cost of a feature freeze and the typical risks of rewrites, and prefer an incremental strangler approach that delivers value along the way unless the evidence strongly favours a rewrite.
Longer Answer
Rewrites usually take longer than estimated and lose business rules encoded in old code. Questions to ask: what specific problems would it solve? Are they concentrated in a few modules? Can we add tests and extract those modules incrementally? What happens to the roadmap meanwhile? Record the decision in an ADR, give the proposers ownership of the new parts, and set a revisit trigger.
Key Points
- Evidence of where pain concentrates
- Business cost of a freeze; rewrite risks
- Incremental strangler approach by default
Deep dive: Capstone: Rewrite or Refactor
-
Most asked What makes a good design document, and when do you require one?
Summary
A good design doc is a short argument about trade-offs: context and scope, goals and non-goals, the design, alternatives considered, risks and rollout. Require one for non-trivial changes — new services or data models, cross-team impact, money or security, hard-to-reverse choices.
Longer Answer
Keep docs to a few pages so they're actually read. Name two to four reviewers who are affected or have expertise, ask them specific questions, and set a decision date. The 'Alternatives considered' section is the heart: it shows why other options lost and prevents re-litigating later. Record the outcome in the doc and, for lasting decisions, in an ADR. Small, reversible changes only need a good PR description.
Key Points
- Trade-offs over completeness
- Named reviewers, specific questions, decision date
- Lasting decisions also go into an ADR
Deep dive: Design Docs and RFCs That Get Read
-
Most asked How do you decide how much process a technical decision needs?
Summary
By how costly it is to reverse. Reversible 'two-way door' decisions should be made quickly by the people doing the work; hard-to-reverse 'one-way door' decisions get a design doc, alternatives, review and an ADR.
Longer Answer
Ask: what would it cost to undo this in six months? A CI tool or internal library is cheap to switch; a primary data store, public API contract or data model with migrations isn't. Make one-way doors more reversible where cheap (abstractions, flags, versioned APIs, dual writes). Amazon's 2016 shareholder letter describes reversible decisions as two-way doors that "can use a light-weight process", and suggests most decisions should be made with around 70% of the information you'd like.
Key Points
- Classify by reversibility first
- Fast for two-way doors, rigorous for one-way doors
- Make irreversible choices more reversible
Deep dive: Decision Speed: One-Way and Two-Way Doors
-
Most asked A product manager asks when a large project will be done. How do you answer?
Summary
With a range and a confidence level based on the team's actual throughput — for example '50% likely in 12 weeks, 85% in 14' — and a commitment to re-forecast weekly as scope and progress change.
Longer Answer
Summing estimates gives an optimistic single date because it ignores variation, interruptions and newly discovered work. A Monte Carlo simulation over the team's weekly throughput history produces a distribution of finish dates. If a single external date is needed, use a high-confidence percentile and say it's a commitment level. Reduce uncertainty over time by slicing work smaller and limiting work in progress.
Key Points
- Ranges with confidence, not single dates
- Forecast from throughput history (Monte Carlo)
- Re-forecast weekly
Deep dive: Forecasting Delivery Honestly
-
Most asked How do you communicate project status to stakeholders?
Summary
One short written update on a fixed cadence, in one place: status and forecast with any change at the top, progress against the goal, risks with owners, and decisions needed with dates.
Longer Answer
Report progress, not activity. Change status as soon as the forecast changes — gradual movement builds trust; sudden green-to-red destroys it. When delivering bad news, bring options and a decision date. A regular written update reduces ad-hoc interruptions to the team and lets stakeholders prepare for decisions.
Key Points
- Fixed cadence, one page, one place
- Forecast-based status; change early
- Bad news with options and a decision date
Deep dive: Status Updates Stakeholders Trust
- How do you set technical direction for a team?
- How do you approach build vs buy decisions?
- How do you break down a large feature so it can ship incrementally?
- Why should postmortems be blameless, and doesn't that remove accountability?
- How do you balance reliability work against feature work?
- Your project depends on a change from another team that hasn't been scheduled. What do you do?
- Tell me about a time you resolved a technical disagreement in your team.
- Tell me about a time you improved how your team works.
- Tell me about a time you mentored someone through a hard project.
- Tell me about an incident you led.
- A senior engineer on your team consistently ignores the team's code review agreement. How do you handle it?
- A key engineer is the only person who understands a critical system. What do you do?
- Your team's velocity is dropping. How do you investigate?
- How do you work with your engineering manager as a tech lead?
- How do you work with your product manager as a tech lead?
- What would you look at to judge the technical health of a team you just joined?
- What is an ADR and why would you use one?
- How do you run a design review that is useful rather than a gate?
- How do you handle a production bug caused by code you approved in review?
- How do you make sure your team's services are operable in production?
- How do you onboard a new engineer to a complex code base quickly?
- How do you decide whether to adopt a new technology the team is excited about?
- What's the hardest part of being a tech lead, in your experience?