Leading a team of five to ten
Tech lead is a different job from senior engineer, and the interview probes whether you know that. The tell is where your leverage comes from: a senior engineer’s output is their code, a lead’s output is the team’s, and the two require opposite instincts about how to spend a day.
Mentoring, Feedback, and Helping Others Grow covers developing one person. Leading technical direction on R&D work covers work whose outcome is unknown. This is the operating layer between them.
How much do you still code
The question everyone gets and most answer badly, in one of two directions: “I stopped coding” reads as disengaged from the codebase; “I code the same amount” reads as not actually leading.
The defensible answer names a share and a shape. Roughly a third of the time, spent on work that is genuinely improving for the team to have done — the risky spike nobody else can size, the piece on the critical path when it is genuinely blocked, the tooling that removes friction from everyone.
What you stop doing is take the interesting feature. If the lead consistently takes the most interesting work, the team stops growing and the best people leave. That sentence, said unprompted, is most of the signal in this question.
Allocation is a growth decision, not a throughput one
The naive optimisation is to give each task to whoever finishes it fastest. That is locally correct and compounds badly: the person who knows the payment system keeps getting payment work, becomes the only one who can do it, and becomes a bus factor and a bottleneck at once.
| Task shape | Assign to |
|---|---|
| Urgent and risky | someone who has done it |
| Important, not urgent | someone stretching, with support |
| Routine | rotate deliberately |
| Nobody understands it | pair, or spike it first |
Stretch assignments need a named safety net — a reviewer, a check-in on day two, an explicit “come back if it is not moving by Thursday”. A stretch without one is not development, it is a person quietly stuck for a week.
Track ownership coverage as a thing: for each critical area, how many people could handle it. Anywhere the answer is one is a risk you can name to management, which is also how you get the time to fix it.
Code review is where most of your leverage is
More of a lead’s influence lands through review than through anything else, because it is the one place where standards, context and judgement transfer continuously rather than in a meeting.
- Separate blocking from non-blocking. Prefix comments, or say it plainly. A review where every remark reads as mandatory teaches people to wait for permission.
- Explain the why, once. “Use a set here” is a fix. “Use a set — this is O(n) per lookup inside a loop over 10k items” is a lesson.
- Review promptly. A day of latency on review is a day of blocked work multiplied by the team size; it is usually the cheapest throughput win available.
- Approve with comments more often than you think. Blocking on preferences is where review turns adversarial.
- Escalate out of the tool. Past two rounds of back-and-forth, the thread is the wrong medium — take it to a call and write the outcome back.
Set the standards in writing so review is not the first time someone learns them; conventions in a repository beat correcting the same thing in ten pull requests. Tooling notes in Code quality.
Competency development, made concrete
“I mentor the team” is unfalsifiable. What lands is a specific mechanism:
- A skills map — areas across the top, people down the side, who can do what today. It makes gaps and single points of failure visible, and it turns growth conversations from vague to specific.
- One growth goal per person per quarter, tied to real work rather than a course. The goal is the assignment, not a book.
- Rotate the unglamorous work — on-call, releases, the legacy service. Concentrating it creates resentment and single points of failure at once.
- Have the person who learned it teach it. A short walkthrough to the team is the cheapest way to move knowledge, and it develops the teacher more than the doing did.
Protecting the team’s attention
A team of eight generates enough interruption to consume a lead entirely, and the failure mode is a lead who absorbs it by working evenings.
Be the interface deliberately: take the ad-hoc requests, batch them, and bring them to planning rather than forwarding each one. Say no, or “not this sprint”, in a way that names the trade — “we can take that if the migration slips a week; which do you want?” gives the requester the decision and makes the cost visible. The client-facing version of this conversation is in Working directly with clients.
What to measure, and what not to
Do not measure individual output. Lines, commits and story points per person are gameable and corrosive, and reaching for them in an interview is a red flag.
Measure the system instead: cycle time from start to production, review latency, change failure rate, and how much of the sprint survives contact with interruption. Those describe the team’s ability to deliver, which is what you actually control.
Related
Interview angle 4
- “How much do you still code as a lead?” - name a share and a shape: about a third, on the risky spike, the blocked critical path, and tooling. And say what you stopped doing — taking the interesting feature, because a lead who keeps the best work stops the team growing.
- “How do you assign work?” - not to whoever is fastest, because that compounds into single points of failure. Match task shape to growth: risky and urgent to someone who has done it, important-not-urgent as a stretch with a named safety net, routine rotated deliberately.
- “How do you develop people?” - a skills map that makes gaps visible, one growth goal per person per quarter tied to real work rather than a course, and having whoever learned something teach it back. Follow-up: how do you know it worked? The coverage count for each critical area went up.
- “How do you measure your team?” - system metrics, not individual output. Cycle time, review latency, change failure rate. Per-person commits or points are gameable and damage exactly the collaboration you need.