Hire a tech lead: test judgment, tradeoffs, team calm

Why ticket output misses the job

Ticket count feels neat because it gives you a number. The job of a tech lead is rarely neat. Most weeks, a lead makes decisions with partial facts, real deadlines, and tradeoffs nobody likes.

That is why raw output is a poor filter. Someone can close twenty tickets and still leave the team with messy handoffs, shaky architecture, and bugs that return two sprints later. Speed matters, but speed without judgment usually creates rework for everyone else.

A tech lead also works at a different level than a strong individual contributor. They decide when to keep scope small, when to push for a cleaner fix, and when to accept an ugly but safe patch because the business cannot wait. None of that shows up in a simple ticket report.

You see the gap most clearly during rough weeks. A release starts failing in production while sales is waiting on a promised feature. One lead keeps coding and adds more noise. Another slows the room down, names the real risk, assigns owners, and cuts the plan to what the team can ship safely. Teams remember that person for months.

If you want to hire a tech lead, look past personal output and ask what happened around their output. Did their decisions lower stress or spread it? Did they help other engineers move faster next week, not just close more work today? Did they stop a bad decision when nobody had complete information?

Good leads do write code. But code is only part of the job. The harder part is choosing well under uncertainty, protecting the team from avoidable churn, and bringing calm when the room starts to spin.

What good tech lead judgment looks like

A strong tech lead does not start with a favorite tool or a fast answer. They start with the goal, the real limits, and the people who will live with the result every day. That usually means asking about deadlines, failure costs, team size, weak spots in the current system, and who will support the work after launch.

When you hire a tech lead, pay attention to whether they can say "not yet" without sounding hesitant. Good judgment often shows up in what they refuse to build now. They cut scope on purpose, protect the schedule, and leave room to learn before the team commits to a bigger design.

They also name risks in plain language. A strong answer sounds like this: "If we add a second service now, releases get slower, on-call gets harder, and the team has more moving parts to manage. I'd keep it in one service until traffic or team structure gives us a real reason to split it."

Another good sign is reversibility. Careful leads prefer moves the team can undo if they learn something new. They use feature flags, small rollouts, narrow interface changes, and short experiments instead of big rewrites. That does not make them passive. It makes them hard to trap with one irreversible bet.

Judgment also has a people side. A solid tech lead protects morale while pushing for clarity. Under pressure, they lower the temperature, separate facts from guesses, and give the team a simple plan for the next few hours. They do not hide problems, and they do not spread panic.

A simple example makes this easy to spot. Say response times spike after a release. A weak lead jumps into fixes and talks over everyone. A strong one asks what changed, what customers feel first, whether rollback is safe, and who owns communication while the team investigates. That calm, ordered response is often the clearest sign that their judgment is real.

Build the interview around real decisions

Abstract questions create weak interviews. If you want to hire a tech lead, use a decision your team actually faced in the last few months. Pick something messy enough to force judgment, not trivia.

A good example is a release that slipped because one dependency kept failing, the team had two different fixes in mind, and product still wanted the original date. That sounds ordinary, which is the point. Real work rarely looks tidy in a hiring loop.

Give the candidate a short brief, not a full spec. Include the goal, a few facts, and a few gaps. Leave out some details on purpose so you can see whether they notice what is missing.

Before they answer, ask them to list the questions they would ask first. Strong candidates usually slow down here. They ask who is blocked, how many users feel the problem, what the deadline actually means, who owns the risky part, and what happens if the team ships a smaller fix now.

Then tighten the constraints. Cut the budget. Freeze hiring. Say one senior engineer is out for two weeks. Move the deadline closer, or say the date cannot move because another team depends on it. Watch whether they adjust their plan in a calm, practical way.

You are not looking for the smartest-sounding design. You are looking for how they sort the problem. Do they protect the team from panic? Do they trade scope for safety? Do they know when to gather more facts and when to decide?

End with one simple question: what would you do in your first week? That pulls the conversation out of theory. Good answers usually include talking to the people closest to the problem, checking what fails in real usage, setting a short decision window, and making sure the team knows what will not happen yet.

That last part matters more than many teams admit. A lead who can reduce noise, narrow choices, and make a clear call helps more than someone who only produces a fast answer.

Questions that reveal system thinking

A strong lead rarely starts with code. They start by mapping the system in plain language: users, services, data stores, queues, outside vendors, failure points, and the handoffs between them. Ask, "Before you change anything, what would you map first?" If they jump straight to a framework or a rewrite, treat that as a warning.

Then push on fragility. Ask, "What signals would make you say this system feels brittle?" Good candidates talk about slow deploys, unclear ownership, manual fixes, noisy alerts, shared tables, hidden retries, and changes that break unrelated areas. They should name signals they have seen before, not vague talk about complexity.

Hidden coupling often separates a lead from a strong individual contributor. Ask, "Where would you expect one innocent change to cause damage somewhere else?" Listen for answers about auth, billing, shared schemas, background jobs, caching, permissions, and anything several teams touch without noticing. The strongest answers sound careful, not dramatic.

Team thinking matters too. Ask how they would split the work if two or three people had to ship it. A good answer shows sequence, not equal slices. One person might tighten logs and tests first, another might change the API, and a third might handle rollout and rollback. You want someone who reduces collisions and leaves room to learn during the work.

Last, ask what they would watch after launch. Strong leads mention a short set of signals: error rate, latency, queue depth, task success, support tickets, and a clear rollback trigger. Many good candidates add one detail others miss: who watches those numbers, and for how long.

The answers should feel grounded. Look for rough maps, likely failure points, and a plan for people as well as code. Those details tell you far more than a polished story about ticket output.

Questions that reveal tradeoff sense

If you want to hire a tech lead, ask about choices that feel a little uncomfortable. Anyone can say they care about quality, speed, and team health. The useful signal appears when those goals pull in different directions and the candidate has to choose.

A good interview question changes the pressure mid-answer. Give them a normal plan, then move the deadline closer. Ask, "We thought we had six weeks. Now we have three. What do you cut first, and what do you protect?" Strong leads do not answer with slogans. They name what they would drop, what they would keep, and why.

Speed versus polish is another clean test. Put them in a real context: an internal admin tool, a public signup flow, a billing change, or a migration with customer data. Then ask where they would accept rough edges and where they would slow down. If they treat every project the same, that is a warning. Good judgment changes with the risk.

Short fixes versus long fixes tell you how they think beyond this week. Try a case like this: a service fails every Friday under load, support is tired, and the team has one week before a launch. Ask what they would patch now and what they would schedule later. Listen for two things. First, do they reduce pain fast? Second, do they leave a clear path to remove the patch?

Some risks deserve a hard no. Ask them to name the ones they would refuse even under founder pressure. Good answers usually include silent data loss, security holes, untested billing changes, broken access control, and migrations nobody can roll back.

Then ask how they would explain a hard tradeoff to a founder who wants everything. The best answers use plain language: what the team gains, what it gives up, what might break, and who needs to own the decision. A calm lead can say no without making the room tense.

How they calm a team under pressure

Pressure exposes habits fast. The interview should show whether this person lowers the temperature or spreads it. A good tech lead does not calm a team with a pep talk. They make the problem smaller, assign ownership, and keep everyone working from the same facts.

Ask for one story from a tense release week. Do not accept a polished summary. Ask what broke, who joined the call, what they said first, and what changed in the plan that day. People who have done this for real remember the details. They might freeze risky merges, cut scope, pick one owner for each open issue, or move to updates every 30 minutes.

Then ask about conflict between two strong engineers. Pressure rarely shows up as pure tech trouble. More often, it turns into friction between people who both think they are protecting the product. A steady lead listens to each side, names the decision that needs to be made, and ends the loop. If they only talk about "alignment," keep pushing.

Ask what they say when a plan slips. The best answers are plain and specific: "We are late on this part. We can still ship the safer version by Friday if we drop these two items. I will confirm the new scope by 2 p.m." That kind of response calms a room because it replaces worry with a next step.

Panic from above is another good test. Ask what they do when a founder, executive, or client starts pushing for hourly changes. Strong candidates shield the team from that churn. They give one clear status update, offer two options, and stop random new work from entering the sprint.

Listen for specific actions. Good leads narrow scope instead of promising more, set a clear update rhythm, assign ownership for each open problem, speak directly when conflict starts, and keep panic from rolling downhill. If the answer sounds like a speech about leadership, keep digging. Calm leaders remember what they did, not just how they felt.

Mistakes that lead to a bad hire

When you hire a tech lead, the biggest interview mistakes are usually simple. Teams reward polished answers, fast talking, and a confident tone. Those signals feel good in the room, but they often hide weak judgment.

The better candidate often does something less flashy. They pause, ask for missing facts, and explain what they would check before making a call. Clear thinking often sounds calm and a little plain.

Trivia-heavy interviews cause another miss. A candidate can name tools, cloud products, and framework details all day, then struggle when the real problem is messy: a broken release, two engineers pushing opposite fixes, and a manager asking for an update in ten minutes. Tech leads need to sort noise, choose a direction, and explain why.

Many panels skip questions about conflict and pressure because those topics feel uncomfortable. That leaves a huge blind spot. A lead who looks great in a friendly interview can become rigid, vague, or sharp with people when deadlines slip. You need to hear how they handle disagreement, how they calm a room, and how they keep work moving when nobody has a perfect answer.

Confidence also gets too much credit. Some candidates answer every question right away and speak with total certainty. That can sound like seniority. Often it is just speed. Good judgment sounds different. Strong leads say what they know, what they do not know yet, and what would change their mind.

Panel design can ruin the interview too. One strong coder often dominates the discussion and pulls everything toward code quality, clever fixes, or technical depth. Those things matter, but they are only part of the job. If one person controls the room, you may never learn how the candidate handles tradeoffs, risk, or people problems.

A simple fix helps. Give each interviewer one area to test and write down what a good answer looks like before the interview starts. Then compare notes after.

The candidate who says "rewrite it" with full confidence may impress the room. The safer hire usually asks about customer impact, rollback options, team bandwidth, and who needs to hear the plan first.

A simple scenario to use in the room

Give the candidate one problem that mixes product pressure, technical risk, and team conflict. A good tech lead rarely gets neat choices. They get a week like this.

Use this prompt:

"Your product slows down every Monday morning. Support says customer complaints are climbing. Sales wants a launch in three weeks. One engineer wants a rewrite. Another wants small patches. You lead the next ten days. Talk through what you do."

Then stay quiet for a moment. Let them choose where to start. That choice tells you a lot.

A strong candidate usually does not jump straight to code. They reduce confusion first. They name the immediate goal, such as protecting customers on Monday morning and learning why the slowdown happens before betting on a rewrite. They also separate the ten-day plan from the three-week launch plan.

Ask them to walk through the work day by day, but keep it simple. You want decisions, not theater. Ask what they do in the first 24 hours, what facts they need before choosing a fix, how they handle the rewrite versus patch argument, what they tell sales and support, and what result they want by day ten.

Good answers sound calm. The candidate gathers a small set of facts, checks traffic patterns, error spikes, recent changes, and customer impact, then picks the lowest-risk move that can improve next Monday. They may pause nonessential work, assign one engineer to find the bottleneck, ask another to prepare a safe short-term fix, and set a time to revisit the rewrite once the system is stable.

This exercise works because it exposes judgment. A weak candidate treats the slowdown as a pure coding problem. A stronger one sees four problems at once: performance, delivery dates, team disagreement, and customer trust.

When you hire a tech lead, listen for plain language. They should explain tradeoffs clearly, make one or two bets, and say what they would not do yet. If they try to solve everything at once, they will probably create noise when the team needs calm.

Quick checks before you make the offer

Do not make the offer because one answer sounded smart. A tech lead earns trust in small moves: the questions they ask first, the assumptions they name, and the moments when they choose to slow down instead of guessing.

Start with their instinct before the solution. If you gave them a messy scenario and they jumped straight to a fix, that is a warning sign. Strong candidates usually ask a few useful questions first. They want to know what changed, who is affected, what cannot break, and how much time the team really has.

Assumptions matter just as much. Good leads say them out loud. They do not hide uncertainty behind confident language. If they say, "I am assuming the outage affects checkout only" or "I would confirm whether this deadline is fixed," you learn two things fast: how they think and whether they can keep a team aligned when facts are incomplete.

Watch where they slow down. That pause is often the best part of the interview. A mature lead does not treat every problem like a race. They slow down around risky migrations, unclear ownership, security concerns, and tense people issues. They can explain why a quick fix might create a bigger mess next week.

One more check matters a lot: do they protect delivery and team trust at the same time? A weak lead talks as if shipping faster solves everything. A strong one keeps the release moving without throwing people under the bus, hiding bad news, or burning out the team.

Before you decide, compare panel notes on a short scorecard. Did they ask useful questions before proposing changes? Did they state assumptions clearly? Did they explain where they would pause and why? Did they balance deadlines with trust inside the team? And did most interviewers describe the same person?

That last point is easy to miss. If one interviewer saw calm judgment, another saw ego, and a third saw vagueness, stop and dig deeper. Mixed notes usually mean the signal is not strong enough yet.

Next steps if you still feel unsure

Doubt after a strong interview usually means one of two things: the candidate spoke well, or your team asked questions that were too open and easy to improvise around. Do not wait and trust memory. Meet right after the interview, while the details are still fresh.

Ask each interviewer to name specific moments, not general feelings. "They seemed senior" tells you nothing. "They reduced scope during the outage scenario instead of promising a full fix in one hour" gives you something real to compare.

Write down the risks that still feel open in plain language. Can they make decisions with incomplete information? Do they protect the team when pressure rises? Do they explain tradeoffs without hiding behind jargon? Will they raise a concern early, even if it slows a launch?

If judgment still feels blurry, schedule a second conversation and keep it narrow. One realistic scenario is enough, and 30 to 45 minutes usually tells you more than another full interview loop. Give them a situation with messy constraints: a release date, a tired team, one unstable service, and a senior stakeholder asking for certainty. Then ask what they would do in the next two hours, the next two days, and what they would tell the team.

Watch how they think, not how much they talk. Good answers usually include a few calm moves: reduce scope, protect the on-call engineer, set a check-in time, and say what is still unknown. If they jump straight to heroic coding, keep digging.

If your team wants an outside read, a practical option is to bring in an experienced operator for the final stage. Oleg Sotnikov at oleg.is does this kind of advisory work and can review candidates or cover Fractional CTO responsibilities while you keep hiring.

If you still cannot tell whether the person has sound judgment, treat that as signal. This job requires clarity under pressure. Doubt that remains after a focused second pass usually means you should keep looking.