Tech Lead Interview Questions for Senior .NET Engineers

Q1 You've just been promoted to tech lead over a team that included your peers. How do you handle the first month?#

Short answer: Name the shift in the relationship directly instead of pretending nothing changed, over-invest in one-on-ones to reset expectations with each former peer individually, and resist the urge to make sweeping changes in week one — your first moves are read as signals about what kind of lead you're going to be, so make them small and credible.

The awkward part isn't the org chart, it's the informal one: people who used to vent to you about the codebase now have to decide whether they can still do that. The fastest way through it is a direct, private conversation with each person — acknowledging the change, asking what they need from you, and being honest that you're figuring it out too. If someone on the team wanted the role themselves, that conversation is the one you cannot skip or soften; avoiding it just relocates the resentment somewhere you can't see it. In terms of actual leadership moves, spend the first month doing more listening than deciding: sit in on reviews, pair on something gnarly, and make your first unilateral call a small, clearly reversible one rather than a re-org or a new process nobody asked for. Clarify decision rights early — what you'll decide alone, what you'll decide with the team, and what stays theirs entirely — because ambiguity about authority is what breeds quiet resentment, not the authority itself.

What interviewers look for: self-awareness about the power shift, evidence that you invested in relationships rather than just asserting authority, and restraint — not treating a promotion as a mandate to remake the team immediately.

Common mistakes: rewriting standards or re-organizing the team in the first weeks to "leave a mark"; assuming the team will adjust on its own without a direct conversation; being the same peer as before and avoiding the leadership decisions the role now requires.

Q2 How do you set technical direction for a team without turning into an architect who has lost touch with the code?#

Short answer: Technical direction has to come out of the actual codebase — through reviews, pairing and the occasional hands-on sprint — not out of a slide deck, and it should be captured as a living, revisited decision rather than a one-time mandate handed down from above.

The mechanism matters more than the intent here. A lead who says "I stay close to the code" but has no concrete way to do it drifts within two quarters; the ones who don't drift use something like a lightweight architecture decision record for anything non-trivial, so direction is written down, dated, and revisited when circumstances change instead of treated as gospel. Direction-setting also works better as a proposal-and-critique loop than a decree: let the team explore two or three options for a real decision, bring the trade-offs to a short review, and make the call transparently — people follow technical direction they helped shape far more willingly than direction they were only told about. The other half of staying grounded is keeping a toehold in the code itself: reviewing the hardest pull requests personally, not just rubber-stamping, and periodically taking a real ticket so your mental model of the system doesn't quietly go stale while you're in meetings.

# Lightweight ADR template
Title: <short name of the decision>
Status: Proposed | Accepted | Superseded by ADR-NNN
Context: What problem are we solving, and what constraints apply?
Options considered: A, B, C — one line of trade-off each
Decision: What we're doing and why, in one paragraph
Consequences: What gets easier, what gets harder, what to revisit and when

What interviewers look for: a concrete mechanism for staying grounded (reviews, ADRs, occasional hands-on work), not just a claim of staying involved, and evidence that direction is treated as revisable rather than fixed.

Follow-up questions:

• How do you handle it when the direction you set turns out to be wrong six months later?
• How much of the team's input do you actually incorporate versus just soliciting for buy-in?

Q3 Walk through how you decide what to delegate versus what to keep doing yourself as a tech lead.#

Short answer: Delegate anything that's a genuine growth opportunity and doesn't require context only you have; keep decisions that are hard to reverse, that require your organizational authority, or where the cost of a wrong call is high enough that the team shouldn't be learning on it yet.

A useful way to make this concrete is to separate the "what" from the "how": delegate the how almost always — implementation approach, task breakdown, which library to use for a contained problem — while being explicit about the "why" and the success criteria so the person isn't guessing what good looks like. Reversibility is the other lens: a database schema change that's painful to undo, a public API contract, or a security-sensitive design deserves your direct involvement even if you'd otherwise hand it off, while an internal refactor or a new feature's implementation details are exactly where a stretch assignment builds someone's judgment cheaply.

The failure mode to watch for is delegating the task but not the authority — assigning someone a decision and then overriding it the moment they choose differently than you would have. That isn't delegation, it's an assignment with your name still on the decision, and people learn to stop bringing you their real judgment once they notice it.

What interviewers look for: an actual framework (not "I delegate everything" or "I don't trust anyone yet"), and awareness that delegating authority, not just work, is what actually develops people.

Common mistakes: delegating only the unglamorous work and keeping anything interesting; taking a decision back the first time the outcome differs from what you'd have chosen.

Q4 A strong engineer on your team has been underperforming for two months. How do you handle it?#

Short answer: Diagnose before you act — a skill gap, a motivation problem and unclear expectations each need a different response — then have a direct, specific, private conversation early, backed by concrete examples, instead of waiting for the next formal review cycle to raise it.

Vague feelings ("something feels off") aren't enough to act on and aren't fair to bring to the person either, so the first step is gathering specifics: which commitments were missed, what the pattern looks like across several pull requests or sprints, and whether it's new or has always been there and only recently became visible. The conversation itself should name the pattern plainly, ask what's going on from their side — it might be personal, a mismatch with the current work, or something about the team dynamic you don't see — and jointly set a short, concrete improvement plan with observable criteria and a defined check-in cadence, not just "do better." If the plan doesn't move the needle within that window, that's the point to involve your manager or HR formally rather than letting it drift another quarter; letting sustained underperformance go unaddressed is itself a leadership failure, because your best engineers notice the inconsistency and start to disengage from a standard that clearly isn't enforced.

What interviewers look for: the courage to raise it early and directly rather than avoiding the conversation, a structured diagnose-then-remedy approach, and fairness — documentation and clear criteria, not an ambush.

Follow-up questions:

• What do you do differently if this was your strongest engineer a year ago and something changed recently?
• How do you know when to stop trying to fix it and start managing the person out?

Q5 How do you split your time between hands-on coding and leading the team, and how does that ratio change as the team grows?#

Short answer: The ratio should shrink deliberately as the team grows — a lead of two or three might still write close to half their own code, a lead of eight or more should be spending most of their time unblocking, reviewing and deciding — and the coding you keep should be chosen for leverage, not for what's most enjoyable.

The trap on one side is a lead who keeps a heavy personal coding load because it feels tangibly productive, while the team quietly stalls waiting on their reviews and decisions — code review turnaround time is one of the most reliable early signals that a lead has over-indexed on their own output. The trap on the other side is a lead who stops writing code entirely and loses the ground truth that makes their design opinions credible; a lead whose only exposure to the codebase is second-hand eventually gets that lack of context called out in a design review, and it undermines trust in every future opinion. In practice, the highest-leverage moves are treating code review as your primary "coding" activity, since a good review scales your judgment across everyone's output instead of just your own, protecting a fast, consistent review turnaround as a hard commitment, and picking one focused, moderately technical piece of work per quarter — often the riskiest or least-owned part of the system — to stay sharp without becoming the bottleneck.

What interviewers look for: recognition that this ratio is dynamic and tied to team size and maturity rather than a fixed personal preference, plus a concrete mechanism (protected review time, a chosen leverage project) rather than "I just make time for both."

Common mistakes: treating a high personal commit count as proof of being a good lead; disappearing from the codebase entirely and losing the technical credibility the role depends on.

Q6 Walk me through how you lead an incident end to end, from the first alert to the postmortem.#

Short answer: Leading an incident means running the process, not necessarily typing the fix — classify severity fast, put one person in the incident commander seat and a separate person on communication, mitigate user impact before chasing root cause, and only close the incident once impact is confirmed gone and a postmortem is on the calendar.

The sequence matters: triage first (what's the actual user-facing impact, and does it meet the bar for paging more people in), then stabilize using the fastest safe lever — a rollback, a feature flag, scaling out — rather than debugging live in production, because a lead's real job during the outage is protecting decision quality under pressure, not being the person who finds the root cause fastest. Communication is a parallel track, not an afterthought: stakeholders need a steady cadence of updates even when the update is "still investigating, next update in fifteen minutes," because silence reads as loss of control far worse than slow progress does. None of this works without consistent instrumentation habits built before the incident ever happens — a correlation identifier that ties a request across every service it touches is what turns "we think it's the payment path" into a confirmed trace during triage.

using var activity = ActivitySource.StartActivity("incident.correlate");
activity?.SetTag("incident.id", incidentId);
activity?.SetTag("request.correlation_id", correlationId);
logger.LogWarning(
    "Elevated error rate detected for {Service}; correlation {CorrelationId}",
    serviceName, correlationId);

What interviewers look for: process discipline under pressure, prioritizing mitigation over diagnosis, a concrete communication habit, and — ideally — a real story rather than a hypothetical one.

Common mistakes: leading from the keyboard alone while stakeholders get silence; chasing root cause before user impact is stopped; treating "green again" as the end of the incident and skipping or rushing the postmortem.

Q7 How do you run a blameless postmortem, and what do you do when the root cause really is a specific person's mistake?#

Short answer: Blameless means assuming any competent, well-intentioned engineer could have made the same call given the same information, tools and time pressure, so the postmortem's job is to find and fix the systemic gaps that let the mistake happen and reach production — not to identify who to blame — even when one person's specific action is the proximate cause.

The useful distinction is between the proximate cause (a person made a change) and the contributing factors (no second reviewer on that class of change, no staging parity for that config, alert fatigue that delayed detection): the action items target the contributing factors, because that's what actually prevents a repeat, while naming and re-litigating the individual's mistake in a group setting prevents nothing and just teaches people to hide problems next time. Accountability doesn't disappear — it moves to the org level, with every action item getting a named owner and a date, which is a different thing from blame entirely. It's also worth having a short private conversation with whoever was involved, separate from the group postmortem, since they likely already feel worse about it than anyone else in the room and don't need that compounded publicly.

# Postmortem outline
Summary: one paragraph, what happened and the user-facing impact
Timeline: UTC timestamps from first signal to full resolution
Impact: who/what was affected, and for how long
Root cause: proximate cause + contributing factors, kept factual and specific
What went well / what didn't: honest, not performative
Action items: owner + due date for each, tracked to completion

What interviewers look for: genuine understanding of why blameless works — it makes people report and fix problems faster next time — not just repeating the word, plus the ability to hold people accountable for follow-through without that being punitive.

Common mistakes: confusing "blameless" with "no accountability," so action items have no owner and nothing changes; being blameless in the document but subtly blaming in the room's tone.

Q8 Two senior engineers on your team disagree strongly about a technical approach and both escalate to you. How do you resolve it?#

Short answer: Don't just pick a side — make sure each engineer can accurately restate the other's position first, force the disagreement onto shared criteria like cost, risk and reversibility instead of opinion, apply a decision process sized to how reversible the choice actually is, and write the outcome down so it doesn't get re-litigated every sprint.

Escalated technical disagreements are often partly a communication problem: asking each person to restate the other's argument before defending their own frequently reveals they're not as far apart as it felt, or that one side is optimizing for a constraint the other didn't know about. Once the real disagreement is clear, classify it by reversibility — a database access pattern or a public contract deserves more deliberation than an internal helper's implementation — and match the process to that: a quick, low-ceremony call for a two-way door, a short written comparison for a one-way door. If it genuinely comes down to a coin flip on technical merit, it's fine to decide on a non-technical factor like team familiarity or migration cost, as long as you say that's what you're doing rather than dressing up a preference as pure engineering logic.

// Option A: synchronous retry inline with the request
await SendWithRetryAsync(payload, maxAttempts: 3, cancellationToken);

// Option B: enqueue and process asynchronously with at-least-once delivery
await queue.EnqueueAsync(new OutboundMessage(payload), cancellationToken);

What interviewers look for: facilitation skill rather than pure tie-breaking, converting opinions into comparable criteria, and attention to the relationship afterward — not just the technical outcome.

Common mistakes: consistently siding with the louder or more senior voice; deciding privately and announcing it without explaining the reasoning to either engineer; avoiding the decision long enough that the disagreement festers into a personal conflict.

Q9 How do you decide when to say no to your manager or product on a technical shortcut that will create real technical debt?#

Short answer: Treat it as a trade-off with a cost and an owner rather than a moral objection — translate the technical risk into terms the stakeholder cares about, propose the fastest safe alternative if one exists, and if you're overruled, write the decision down so it's a conscious, deliberate choice rather than something that looks like an oversight six months later.

Not every shortcut is worth pushing back on, and spending your credibility on all of them means you'll have none left when it actually matters — save the pushback for corners that touch data integrity, security, or anything expensive to reverse. When you do push back, the argument lands better as a specific failure mode ("this skips validation on the one field that's user-controlled, and here's what happens if it's malformed") than as an abstract appeal to code quality, because the former is something a non-technical stakeholder can actually weigh against the deadline. Offering a scoped middle ground — ship the narrower safe version now, track the gap as a dated follow-up — usually gets further than an unqualified no. When you're overruled on something genuinely risky, escalate calmly with the specific consequence in writing, and if the decision still stands, make sure it's recorded as a decision someone made with the trade-off visible, not a shortcut nobody chose on purpose.

// Shortcut: writes straight through, trusting the caller's input
public Task ApplyDiscountAsync(Order order, decimal percent) =>
    repository.UpdateDiscountAsync(order.Id, percent);

// Minimal safe version: validates the one field that can realistically be wrong
public Task ApplyDiscountAsync(Order order, decimal percent)
{
    if (percent is < 0 or > 100)
        throw new ArgumentOutOfRangeException(nameof(percent));
    return repository.UpdateDiscountAsync(order.Id, percent);
}

What interviewers look for: judgment about which fights are worth having, the ability to say no without being obstructive, and graceful acceptance — with a paper trail — when overruled on lower-stakes calls.

Common mistakes: pushing back on everything and losing influence; agreeing to everything and quietly resenting it; not documenting the trade-off, so it reads as negligence later instead of a decision.

Q10 How do you grow a mid-level engineer into someone who could take over as tech lead?#

Short answer: Give them real scope before the title — end-to-end ownership of a project, the chance to run a design review or lead a minor incident — pair it with honest feedback on the leadership behaviors that don't show up in a diff, and then actively sponsor them for the real opportunity rather than just telling them they're ready.

Stretch assignments work best with a safety net you're explicit about: you're still accountable for the outcome, but they make the calls, and you debrief afterward on the decisions rather than the code. The leadership skills that actually need coaching are the ones that never appear in a pull request — running a meeting, giving direct feedback, handling a disagreement between two other engineers — and the only way to build them is through direct observation and a specific debrief, not a generic "keep developing your leadership skills" comment in a review. It's worth being explicit about the difference between mentoring and sponsorship: mentoring is advice you give them privately, sponsorship is using your own credibility to get them into the room or onto the project where they can prove it — and sponsorship is usually the scarcer, higher-leverage half of the two.

What interviewers look for: a concrete development approach beyond "give them more responsibility," recognition that sponsorship (not just mentoring) is what actually gets someone into the role, and patience with them making lower-stakes mistakes as part of the process.

Common mistakes: mentoring privately but never sponsoring publicly; taking a delegated decision back the moment it goes differently than you would have chosen; promoting the title before ever giving them the real scope.