Team lead interview: cases, questions, and role play
What a team lead interview checks, how to answer management cases about an underperformer, a conflict, or a missed deadline, and how to handle role play.
A team lead interview has almost no coding. You are asked what you will do when a strong developer has been missing deadlines for three months, two seniors cannot agree on the architecture, and a stakeholder shows up on Friday with a task due yesterday. Strong engineers often fail this part: they answer with the right words from books while the interviewer is waiting for a story.
The leadership question comes up long before you apply for a lead role. In the Sobes question bank, collected from real interviews mostly at companies hiring in Russia, "Is there a career track? Do you want to grow technically or toward management and team lead?" was asked at 6 companies, and there is the direct "Which leadership role do you prefer: team lead or tech lead?". In the team lead round itself the wording turns situational: "Your manager gives you an instruction you disagree with and won't accept your arguments. What do you do?".
What gets checked
| Area | What they ask about | What they want to hear |
|---|---|---|
| People | Hiring, feedback, weak and strong performers, conflicts, letting people go | A specific conversation with a specific person and how it ended |
| Process | Planning, priorities, estimates, team metrics | What was broken, what you changed, how you knew it got better |
| Technology | Architecture decisions, tech debt, quality, incidents | That you still understand the system and can argue with seniors on substance |
| Business | Stakeholders, deadlines, negotiating scope, explaining risk | That you talk to product in terms of money and dates |
The weight of each area depends on the role. Ask the recruiter how hands-on it is expected to be: a lead who still codes and a manager of three teams go through different interviews. If there is a technical round, it is most often system design, and the answer structure is in a separate post.
Process questions can be about terminology too: "What problems does a retrospective solve?", "What are DORA metrics?", "How did you decide what to do first? How do you make priority decisions?". You need to know the terms, but still build the answer from your own team: which metric you watched and what decision you made because of it.
Answer with a case, not with theory
Compare two answers to "What do you do with an underperformer?"
Theory:
First you need to find the cause, give feedback, put together a development plan, and if that doesn't help, part ways.
Case:
I had a developer who started closing half as many tasks after moving to a new project. In a one-on-one it turned out he didn't understand the domain and was embarrassed to ask. I paired him with a senior for a month and agreed on a weekly check-in on three specific tasks. In six weeks he was back to his previous pace. I've had the opposite case too, where after two months on a plan we parted ways.
The first answer is correct and says nothing about you. The second shows how you looked for the cause, what exactly you did, how long it took, and that you can follow through to a separation when the plan does not work.
An outline for any management question: the situation in one sentence, what you found out, what you did, the result, and what you now do differently. If you have no case of your own, say so honestly and work through a hypothetical with the same steps and with questions to the interviewer: "Has he been on the team long? Was his work fine before?"
Four standard cases
The underperformer
The interviewer checks whether you can tell "can't" from "won't" from "doesn't know what's expected". Required elements: a one-on-one built on facts instead of judgments, clear expectations with a date, regular check-ins, and an outcome named in advance if nothing changes. Both extremes sound bad: "I'd fire them right away" and "I'd wait until it gets better".
A conflict between two seniors
The argument is usually technical, while the cause is status or an old grudge. Show that you talk to each of them separately first, then reduce the argument to criteria (load, deadlines, maintenance cost), and if there is still no agreement, make the call yourself and own it. "Let them sort it out" reads as stepping away from the role. How to tell conflict stories without blame is covered in the post on conflict and mistake stories.
A missed deadline
The bank has a question for developers: "What do you do when you realize you won't finish a task on time?", asked at 6 companies. A team lead gets the same question, but about the team and the stakeholder. A good answer has three things: you report the risk early, you come with options (cut scope, move the date, add people and what that costs), and afterwards you work out why the estimate was wrong.
Three weeks before the release it became clear we wouldn't finish the payment provider integration. That same day I went to the product manager with two options: ship on time without installments, or ship everything two weeks later. We chose the first. In the retro we found we hadn't budgeted time for certification, and since then we estimate external dependencies as a separate line.
It has a date, options with a price, a decision, and a change in the process.
A key person leaves
This checks whether you think about risk ahead of time. Describe what you do before the resignation (documentation, task rotation, a second person on every critical area) and after: an honest conversation about the reasons, a handover plan, and a review of the team's commitments to the business. Be careful with counteroffers: keeping someone with money rarely fixes the original reason, and the interviewer knows it. A related question from the bank: "The workload grew sharply. How do you hire without things falling apart?".
Role play with an "employee"
More and more often the case is acted out instead of discussed. The interviewer says: "I'm your developer Igor, you've called me in to talk about missed deadlines. Go ahead." Then they play the part: make excuses, take offense, change the subject.
What helps:
- Open with the purpose of the conversation in one sentence, with no long preamble.
- Speak in facts: "in the last month three tasks out of five ran over the estimate by more than double", not "your work has gotten worse".
- Ask questions and listen. The real cause usually comes out only in response to a direct question.
- Don't promise what you can't give: a promotion, a transfer, a cancelled deadline.
- End with an agreement: what, who, by what date, and when you check in.
A typical mistake is stepping out of the role and explaining to the interviewer what you would do. Stay in the conversation with "Igor" to the end.
How to rehearse
Collect six to eight stories of your own: an underperformer, a conflict, a missed deadline, someone leaving, hiring, a disagreement with your manager, a decision you regret. Fit each into ninety seconds to two minutes and tell it out loud. For questions on management theory and process, use the project management section of the bank.
Role play cannot be rehearsed alone. You need a partner who pushes back. The mock interview has management cases in this format: the interviewer speaks as the employee or the stakeholder, and you lead the conversation. You can do it by voice, which is closer to a real meeting. After the case you get a step-by-step review, including what you never asked about.
The final stage for a team lead is almost always with your future manager and deserves separate preparation: see the post on the final interview with a manager. And how expectations of a lead extend expectations of a senior is clear from the breakdown of middle versus senior.