Tech Lead Interview Questions

Option B is the strongest: it gives a concrete time split (20–30% / 70–80%), explains the reasoning behind each side, names the critical anti-pattern (bottleneck tech lead), and demonstrates self-awareness about the transition from individual contributor to leader. Key Tech Lead vocabulary: Individual contributor (IC) — an engineer who delivers value through their own code output. Multiplier — a leader who increases the output of the whole team rather than just themselves. Bottleneck anti-pattern — when the Tech Lead owns critical paths that others can't touch, slowing delivery. Technically credible — respected enough by engineers that technical decisions land; maintained by staying close to the code without owning it. The 20–30% / 70–80% model is a commonly cited benchmark; the exact split is less important than the intentionality behind it. Option A describes an IC mindset, not a leadership mindset. Option C shows reactive behaviour without a clear model. Option D overcorrects and abandons technical involvement entirely.

Option C is the strongest: it distinguishes pre-planning refinement from the planning meeting itself (a key process maturity signal), names the inputs (acceptance criteria, capacity, velocity), describes the role of scope negotiation with the product owner, and introduces the concept of a sprint goal. Key planning vocabulary: Backlog refinement (grooming) — a session before sprint planning where tickets are sized and clarified, so planning is a commitment meeting, not a discovery meeting. Acceptance criteria — conditions a ticket must meet to be considered done; absence of these is the most common source of scope creep. Capacity planning — adjusting velocity for holidays, on-call rotations, planned leave. Scope negotiation — when the planned scope exceeds capacity, the Tech Lead negotiates with product to defer, descope, or split tickets; this is leadership work, not just delivery management. Sprint goal — a single-sentence business objective for the sprint; teams with sprint goals recover from blockers better because they understand intent, not just task lists. Option A shows basic process awareness but the "ask during the meeting" detail reveals insufficient preparation. Option D is mechanical but lacks leadership framing.

Option B is the strongest: it opens with diagnosing the cause rather than applying a response, names three distinct root causes (complexity, confidence, process), specifies that the conversation is one-to-one and framed as curiosity rather than performance management, and ends by reframing a seemingly individual problem as a potential systemic issue. Key leadership vocabulary: One-to-one (1:1) — a private, regular meeting between manager/lead and team member; the right venue for sensitive performance signals. Root cause vs symptom — missing estimates is a symptom; the underlying cause determines the right response. Psychological safety — an engineer who fears being blamed for missing estimates will hide risk instead of raising it early. Task decomposition — breaking a large ticket into sub-tasks of 1–2 days each; makes hidden complexity visible before commitments are made. Buffer for unknowns — explicitly accounting for uncertainty in estimates rather than assuming the happy path. Option A leads with accountability before diagnosis, which can damage trust. Option D reassigns rather than developing the engineer — a leadership shortcut that doesn't build team capability.

Option C is the strongest: it introduces the debt register as a structured artefact, names the 20% capacity allocation as a standing practice rather than a negotiated favour, demonstrates how to translate technical debt into business language, and explicitly names the failure mode to avoid (silent accumulation). Key technical debt vocabulary: Technical debt register — a living document listing known debt items with impact and urgency scores; makes debt visible and discussable. 20% rule — reserving a fixed proportion of sprint capacity for non-feature work (refactoring, debt, reliability); the specific percentage varies, but the principle of a standing allocation is what matters. Business-impact framing — translating technical cost into terms stakeholders care about: delivery speed, incident risk, onboarding time. Silent accumulation — the failure mode where debt is accepted without being recorded, making it invisible until it causes a production incident or delivery crisis. Boy scout rule — leaving code cleaner than you found it (mentioned in Option B), a good micro-practice but insufficient as a debt strategy at team level. Option D shows process awareness but frames debt negotiations as adversarial rather than collaborative, and reactive (incident-driven) rather than proactive.

Option C is the strongest: it gives a day-by-day structure with concrete milestones, introduces the first PR on day 2 principle (early deployment pipeline exposure), assigns a buddy with a defined duration, and most importantly sets out explicit 30/60/90-day expectations that frame onboarding as a progressive ramp, not a fixed event. Key onboarding vocabulary: Buddy system — pairing a new hire with an experienced team member for day-to-day guidance; different from a formal manager relationship. First PR on day 2 — a deliberate practice of getting new engineers through the full build/review/deploy cycle within 48 hours; builds confidence and surfaces tooling issues early. 30/60/90-day expectations — a framework for setting progressive milestones: independent delivery (30 days), design contribution (60 days), mentoring capability (90 days); makes ramp-up measurable. Time to first meaningful contribution — the metric a good onboarding plan minimises; meaningful means real production impact, not just setup tasks. Psychological safety during onboarding — new engineers need explicit permission to ask "obvious" questions; the buddy system and structured 1:1s create this. Option A is too informal. Option D prioritises culture over structure and lacks concrete milestones.

Option B is the strongest: it sequences the intervention correctly (private conversations first, joint conversation second), names the technique of active listening, identifies the diagnostic move of finding the shared goal beneath the conflict, frames the conversation around the work rather than personalities, and acknowledges the limit of the Tech Lead's role by naming escalation as the correct next step when resolution stalls. Key conflict resolution vocabulary: Private 1:1 first — holding separate conversations before a joint one reduces defensiveness and lets each person speak candidly; jumping to a group confrontation usually increases tension. Active listening — reflecting back what you hear, asking clarifying questions, withholding judgement; the opposite of waiting for your turn to respond. Shared goal — engineers in conflict usually share the outcome they want (good code, a reliable system, a clear API); making that explicit shifts the conversation from adversarial to collaborative. Focus on the work, not the personality — keeping the discussion on technical and process questions rather than character judgements is a core facilitation principle. Escalation — knowing when to involve a manager or HR is a sign of leadership maturity, not weakness. Option A jumps to a confrontational group setting and ends with the Tech Lead imposing a decision — which resolves the symptom but not the relationship. Option D is passive avoidance.

Option B is the strongest: it leads with business-impact framing, names the four business dimensions stakeholders care about (speed, cost, risk, experience), prohibits jargon without definition, introduces the analogy technique with a concrete example, describes the written summary format with its four components, and adds the sophisticated point about distinguishing inform vs. input decisions. Key stakeholder communication vocabulary: Business-impact framing — leading with "this decision means we can ship X faster" or "this reduces our risk of Y" rather than leading with the technical mechanism; this is the single most important communication habit for Tech Leads. Analogy — mapping an unfamiliar technical concept to a familiar domain; effective analogies don't need to be perfect, they need to be close enough to build intuition. Written summary after verbal discussion — a discipline that prevents misalignment; the format "decision / rationale / trade-offs / not doing" is a repeatable template. Inform vs. input decisions — a critical distinction; stakeholders should understand strategic technical decisions (inform) but should not be driving implementation choices (input on wrong level). Architecture Decision Record (ADR) — mentioned in Option D, a valid documentation practice, but Option D misses the framing and analogy techniques that make communication actually land. Option C over-relies on visuals without addressing the underlying framing problem.

Option B is the strongest: it names timeline reconstruction as the opening step, explains the purpose of five whys with the correct stopping condition (process/tooling/organisational gap, not human error), states the blameless framing principle explicitly ("any reasonable engineer would have made the same decision"), insists on named owners and due dates for action items, and advocates for company-wide publication as a trust and learning mechanism. Key post-mortem vocabulary: Blameless post-mortem — a review focused on systemic failures rather than individual mistakes; rooted in the principle that people operate within systems, and systems can be improved. Timeline reconstruction — the chronological sequence of events, observations, and decisions made during the incident; the foundation all analysis builds on. Five whys — an iterative root cause technique: ask "why did this happen?" and apply the same question to each answer until you reach a systemic factor. The rule is: never stop at "human error" — always ask what process or system allowed the human error to have that impact. Blameless framing principle — "given the information available at the time, any reasonable person would have done the same" — removes individual culpability and focuses on the environment. Named owners with due dates — action items without owners are wishes, not commitments; this is the most common post-mortem failure mode. Option C conflates blameless with anonymising individuals — these are different concepts; blameless means no individual punishment, not no individual names. Option D is close but misses the timeline step and company-wide publication.

The correct answer demonstrates a willingness to collaborate and address concerns constructively. Option 1 shows defensiveness and unwillingness to discuss solutions. Option 2 prompts a productive conversation about specific issues. Options 3 and 4 are dismissive and fail to acknowledge the feedback. Addressing edge cases proactively is crucial for robust software.

The best response emphasizes investigation and collaboration. David's message indicates a potential issue that needs immediate attention. Sharing logs and metrics allows for a systematic diagnosis, while options 2 & 3 demonstrate proactive leadership and responsibility. Option 4 is an unproductive question.

A good PR description should explain *why* a change was made and its implications. This description lacks crucial information about potential impacts on other services, making it difficult for reviewers to assess the risk and ensure compatibility. Providing context is critical for effective code review.

Understanding the *specific* error message is the first step in diagnosing a complex issue. While all options are potentially relevant, focusing on the concrete problem allows you to guide Maria towards a solution or identify any roadblocks she might be facing. Simply asking for a walkthrough without knowing what's wrong can lead to wasted time.

The response indicates the update was successful. Option 1 provides a concise and clear confirmation to the user. Options 2 & 3 are overly verbose and add unnecessary detail, while option 4 focuses solely on the technical aspect of the API without considering the user's perspective.