Tech lead interview questions: what each one scores, from the hiring side

Before the Room calls the problem behind these questions the authority gap: the distance between what you are accountable for and what you are allowed to command. A tech lead lives in it. Every question in this round puts you back in it and watches what you reach for.

The book names three reflexes strong engineers reach for first, and all three show up as interview answers: be more right (more data, a better diagram), work harder (carry it yourself over a few late nights), or retreat into private frustration about politics. None of the three touches the decision, and the decision is what the interviewer is scoring. Across the eleven questions, they write down the same four things:

Level shows in scope, not in vocabulary. The book's lens: "A senior engineer solves the problem. A staff engineer changes the decision around the problem. A principal engineer changes the system that keeps producing that decision." A tech lead loop is usually calibrating between the first two.

Before the Room runs every situation through three moves, always in this order, and they make a dependable answer skeleton. Surface: the decision that was really being made, who owned it, and the incentive that would settle it. Shift: the one artifact you used to change it and who saw it first. Secure: the threshold you set for escalating and the signal you checked to see whether it held.

Open with two sentences of context, spend most of the time on those three, and close with the result and its cost. About ninety seconds for the first telling. Then stop and let the interviewer pull. A missing move is where the follow-up goes, so you can predict most follow-ups by checking which move your story skips.

The question: "Tell me about a time you influenced a decision you did not own." Variants: changed another team's mind, led without authority.

What it scores. Whether you found the decision under the problem, its owner and the incentive behind the no, and whether you moved it before the meeting rather than in it.

Weak answer. "I gathered more data and presented a stronger case at the review, and eventually they came around." It describes being more right. If the resistance came from an incentive, more evidence can make the proposal look more threatening, and the interviewer knows it.

Strong answer. Built on the book's consolidation scene: "The proposal moved the data model out of another director's team. His 'too early to standardize' was about his team's role, not the schedule. The decision belonged to the portfolio sponsor, and his objection carried weight there. Before the review I took him a one-page memo showing how his team could own the new platform. It was approved with the start pushed a quarter, and I logged the delay as the price of the yes."

The follow-up. "What if his objection had been technically right?" The book's test: a technical objection is specific and stable, can name what would change its owner's mind, and survives a fair trade. If it survives, change the plan. The full answer is in the influence without authority question, scored.

The question: "Tell me about a time you pushed back on a deadline," or "have you ever said no to a project?"

What it scores. Whether you knew whose no it was. A lead rarely owns the decision to move a date. What you own is making the trade visible and putting it with the person who owns the priority.

Weak answer. "I told them there was no way we would hit that date and we needed another month." Often true, and it still fails: it hands a director who repeated the date a problem with no way out, so they push back.

Strong answer. The three-option memo from the book's order-tracking launch, said in one breath: keep the date and move the home-screen widget to the next release, keep the full scope and move the launch about two weeks, or submit the build now with tracking switched off and turn it on for a limited cohort on the day. One recommended, with the reason. Then the line that hands the choice back: "Engineering sizes the risks and recommends one. You own which promise we make. Which do you want?" On mobile, a real option counts App Store review, which nobody outside Apple controls, and a possible rejection.

The follow-up. "What if they picked the option you argued against?" Record who chose it and which risks its owner accepted, stop relitigating it in side threads, and run it as well as it can be run. The full version is in how to say no to a project as a tech lead.

The question: "How would you drive a migration across teams you do not manage?" or "tell me about a platform adoption that stalled."

What it scores. Whether you see the economics: the benefit is global and later, the cost is local and lands on whoever moves first. Before the Room is direct about what the hiring side listens for here: "the candidates I rated highest asked who pays the first team's discovery cost, what the late teams inherit for free, and when the old path stops being an option."

Weak answer. "I would get buy-in, put it on a shared roadmap and follow up with each team." Reminders ask every team to act against its own quarter as a favor. Asking leadership for a mandate with no capacity behind it is the other weak version.

Strong answer. From the book's legacy-client migration, told as an answer: "Six teams agreed the platform was better and two moved, because nobody owned the adoption cost or the decommission date. I wrote a wave plan: high-pain teams first with direct pairing, representative teams second, the long tail last with docs and a deadline. With my director, I took one question to the portfolio sponsor." The book gives that question in one sentence: "The decision I need from you is whether the organization funds adoption as portfolio work or lets it compete against each team's roadmap."

The follow-up. "And if the sponsor says no?" The book's answer: record the decision and the risks accepted, stop absorbing the gap with weekend pairing, tell the team carrying the unfair share that the trade was raised and declined, and write down what would reopen it. For the technical side of the same question, see the mobile architecture migration interview question.

The question: "How do you know your project is on track?" or "tell me about a launch that surprised you."

What it scores. Whether you can tell activity from evidence. In the book's chapter on false green, every team closed its tickets and the feature had never once worked end to end. False green is rarely a lie; it is the truth from the wrong instrument.

Weak answer. "We track everything on the board, I run a weekly status and every team reports green." That describes the instrument that produced the surprise.

Strong answer. Built on the book's chapter on false green: "I ask for one piece of proof that crosses the team boundaries: a real client completing the flow against the intended backend path, with the release sequence and rollback we will actually use. Until that runs, status is amber, not green. I say it as 'the work is locally complete, but the launch path is not proven', so nobody has to defend their tickets, and I take it to the sponsor before the readiness meeting, not during it."

The follow-up. "What if the sponsor wants to launch on amber anyway?" That is their call, as a named risk they accept. Your job ends at making the risk visible and owned; acting as though the launch decision is yours turns a status conversation into a status war. More in green on the dashboard, red in reality.

The question: "Tell me about a time you escalated something."

What it scores. Whether you moved a decision to the owner who could make it, or asked an audience for a verdict on a person. And when you announced the threshold.

Weak answer. "I looped in the directors because it had been blocked by platform for five weeks, and it got resolved within the hour." The blocker moved, and the story still scores low: it names a villain, asks for no decision, and says nothing about the relationship you need for the next three launches.

Strong answer. From the book's vendor-cutoff scene, told as an answer: "It was a priority conflict between our payment SDK migration and the platform team's incident follow-up, and only the launch sponsor owned both. I had told the other lead weeks earlier that if the endpoint was not owned and scheduled by Monday, I would take a brief to the sponsor, with both managers consulted. When it fired, the brief named both teams' risks, what the two leads had already tried, two options and a recommendation, and asked for a choice by Wednesday noon."

The follow-up. "How did the other lead feel about it?" Have an answer. The book's check after a week is wider than the blocker: an owner decided, the dependency plan changed, and the other lead did not feel ambushed. The full method is in how to escalate as a tech lead.

The question: "Tell me about an incident where you took charge."

What it scores. Two things that pull in opposite directions: restoring service in minutes, and learning over weeks. In the restoration half, the interviewer listens for structure, not heroics: roles, tempo, mitigation before diagnosis. In the review half, whether it ended at a condition and a control, or at a person.

Weak answer. "I found the bad config and fixed it, and afterwards we added an extra approval step." A debugging story, closed with the cheapest visible control.

Strong answer. The book's opening message for an unrostered channel is a useful model: "I am running this. We roll back the last deploy now. Owen, you stay on diagnosis in case the rollback does not help. Next update in ten minutes." Then the review: the config change was the trigger; the missing validation, the lack of a staged rollout and the alert that paged the wrong team were the conditions, and one primary control was funded first. On mobile, say exactly what your brake was: you can pause a phased release on the App Store or halt a staged rollout on Google Play, and turn a feature off server-side, but you cannot take a shipped binary back from phones.

The follow-up. "So whose fault was it?" The book's line: "The final trigger was the change. The real question is what had to be true for it to do this much damage." With one boundary: a deliberate breach or a repeated, corrected mistake is a management matter, not a systems review. For the story structure itself, see the production incident interview question.

The question: "Your strongest engineer shuts down designs he disagrees with. What do you do?" Variants: a conflict with a senior engineer, a disagreement you lost.

What it scores. Whether you can keep his judgment without the silence it imposes. The book separates contribution, what he produces, from impact, what changes in the people around him. Contribution can be high while impact is negative.

Weak answer. Either "he is usually right, so I defer", or "I gave him feedback about collaboration in our one-on-one." The first keeps the private veto. The second turns into a fight about his character.

Strong answer. Shaped on the book's example: "I made it a review rule for everyone, not feedback for him: an objection names the failure mode, cites the evidence and says whether it is a blocker or a preference. When he called a retry path a blocker, he walked us through the missing idempotency guard and won on the merits. When it was a preference, we replayed recorded production traffic through both designs in staging and went with the result." The sentence the book gives for the room: "Walk me through the failure mode and the evidence, and tell me whether it is a blocker or a preference."

The follow-up. "And if the behavior continues?" A tech lead can set the norm. Only his manager can change what the organization rewards, and if he gets the most visible work every time he rescues a launch, that reward is louder than any feedback. Escalate the behavior, not his character.

The question: "Your director keeps asking the team to just push for the full scope. What do you say the third time?"

What it scores. Whether you can hold a line without raising the volume. Most candidates have a good first answer. This question is about the second and third time the pressure lands.

Weak answer. A longer explanation each round, the history of the last time someone ignored engineering, or quietly folding and promising the date. The book names the tell: your sentences get longer each round, which means you have started arguing.

Strong answer. The same line as the first time, in the sponsor's terms. The book's version begins: "I can commit to the limited beta on the date, behind flags, with rollback proven before we pass five percent of traffic. That part I will hold." It goes on to say why the full migration on that date is a risk effort cannot remove, because the new data format has no downgrade path, and that if the business wants it anyway, it is the sponsor's call, written down as an accepted irreversible risk.

The follow-up. "What would change your answer?" New facts, not new pressure: a later window, or a partner willing to accept a limited cohort. And watch the word monitor. "Ship it and monitor" is a plan only if it names the failure mode, the alert, who watches and the response. In the book's phrase, without those, "monitor means hope while looking."

The question: "Tell me about a technical decision your team kept relitigating," or "how do you make architecture decisions stick?"

What it scores. Whether you can tell a decision from a nod, and new evidence from repeated disagreement. A meeting gives you people appearing to agree. It does not give anyone the right to decide.

Weak answer. "We agreed in the design review, then one engineer kept reopening it in pull requests, so I escalated him." It treats a decision-system gap as a difficult person.

Strong answer. Built on the book's chapters on decision rights and decision records: "The review never named who decided, and the person who could reopen it was not in the room. So I mapped the roles: who proposes, decides, pays, executes and can reopen. Then I wrote the decision record with the options we rejected, the consequences we accepted and the reopen criteria, the specific evidence that would justify revisiting it. After that the line was simple: if you have evidence that meets the criteria, put it on the record and we take it to the owner; if not, the implementation follows the decision." The book's check before calling anything closed: "Before we call this closed, who actually owns this decision, and who could reopen it who is not in this room?"

The follow-up. "Is that not just shutting down dissent?" The answer the book gives is that you want better dissent, not less: earlier, more specific and on the record. If nobody ever disagrees, the evidence has probably been suppressed, and you meet it later as an incident.

The question: "What does a week look like for you as a lead?" or "what happens to your team when you are on vacation?"

What it scores. Whether decisions route to the lowest competent owner or through you. Before the Room's hiring-side observation is specific: in the debriefs and calibrations behind it, the tech lead who read as ready for more scope "was usually the one whose team kept moving while they were on vacation."

Weak answer. "I review every pull request, I am always available, and I unblock everyone." It sounds generous. It describes a single point of failure whose speed caps everyone else's autonomy.

Strong answer. Built on the book's weekly operating system: "I sort work into four lanes: decisions I own because they are irreversible and inside my remit, decisions I review but do not take back, bounded decisions I delegate with a guardrail and a review point, and recurring questions I turn into a mechanism. Decisions that need me arrive in writing with a recommendation, alternatives and risks. Once a month I hand one class of decisions to a team lead, such as library adoption, and review the first two calls at the checkpoint, not in the thread."

The follow-up. "Tell me about a delegated call you would have made differently." The strong answer is that you let it stand and told them why. Re-review every call and you have kept the veto and handed over only the typing. For the review side of this, see tech lead code review is a system.

The question: "What have you done that shows you are ready for this scope?" Often asked late, sometimes as "what are you most proud of?"

What it scores. Evidence, scope and honesty about what is still unproven. It is the same reading a promotion committee does, compressed into five minutes.

Weak answer. A list of activities, the book's example being "Led meetings, coordinated teams, improved reliability". Before the Room notes that calibration rooms discount such lists quickly, because plenty of plateaued engineers could write the same one.

Strong answer. One entry, in the shape the book's evidence ledger uses: the situation, the leadership problem inside it, your action, the artifact, the outcome, the scope with other people's parts named, and the missing proof. Adapted from the book's migration example, spoken: "Six teams needed to leave the legacy client and each paid the cost locally. I wrote the wave plan and, with my director, took the funding question to the portfolio sponsor, who funded adoption as portfolio work. Three teams committed to wave one with named capacity. The platform lead built the tooling. What I cannot show yet is old-path usage after a month."

The follow-up. "What was your part, and what was the team's?" Have the scope line ready before they ask. The missing-proof field is what makes the rest believable. Building that evidence while the work is alive is the subject of the staff promotion packet article.

Read the eleven follow-ups together and they repeat three moves. Whose call was it? That checks Surface. What did you put in front of them, and when? That checks Shift. And what happened a week later? That checks Secure. A candidate who has the three in every story can take almost any follow-up; one who skips a move hears the same question in different words until the gap shows.

When a follow-up does expose a gap, say so plainly rather than inventing the missing move: "I did not set a threshold that time. Today I would have told the other lead on day one when I would take it to the sponsor." That reads as judgment. A reconstructed story that suddenly has every move in it reads as preparation.

You do not need eleven stories. Most leads can cover the loop with four or five, as long as each one has a named decision, an owner, an artifact and an ending you can check. A migration story can answer questions 3, 5 and 11. A launch story can answer 2, 4 and 8. Write each story down as the book's evidence ledger does, with the missing proof included, and check that the part you claim was yours.

One boundary is worth saying in the room if it comes up. Before the Room is explicit that not every organizational failure can be solved by a skilled engineer: some objections are simply correct, some costs cannot be made fair, and some decisions belong above you. A story where you recognized that and stopped is a lead story too.

What questions are asked in a tech lead interview?

Beyond the coding and design rounds, a tech lead loop asks about situations where you were accountable for something you could not command: a decision another team owned, a date you could not hit, a migration nobody funded, a status report you did not believe, an escalation, an incident, a conflict with a strong engineer, a sponsor who kept pushing, a decision that kept reopening, where your week goes and what evidence shows you already work at the level. The wording changes between companies; the situations rarely do.

How is a tech lead interview different from a senior engineer interview?

A senior loop mostly asks whether you can solve the problem. A tech lead loop asks what you do when the solution depends on people you do not manage. Being right is assumed. The score comes from whether you found the real decision and its owner, what you put in front of that owner, and what kept the outcome from drifting a week later.

Are iOS and Android tech lead interview questions different?

The leadership questions are the same on both platforms. What changes is the detail a strong answer carries: app review time you cannot schedule, phased or staged rollouts, old app versions still in use after a backend change, and the fact that you cannot take a shipped binary back from phones. A mobile lead who leaves those out of a deadline or incident story sounds like they have not shipped under them.

Should I use STAR for tech lead behavioral questions?

STAR is a usable skeleton, but on its own it leaves out what a lead loop scores most: whose decision it was, what artifact you used to move it, and how you knew it held. A simple check: before you answer, be able to say the decision, its owner, the one artifact, and the threshold or signal you set. If one is missing, that is where the follow-up will go.

What if my best story ended in a no or a failure?

Use it. A no that came from the person who owned the decision, with the cost in front of them, is a strong answer if you say what you recorded, what you stopped absorbing and what would reopen it. Interviewers for lead roles score whether the decision reached its owner, not whether you won it.