Tech Lead Interview Questions India 2026: Leadership

Leadership questions are the differentiator for tech lead roles:

1. What makes a good tech lead? A tech lead is responsible for the technical direction and quality of the team's output, not just their own code. Responsibilities: define technical roadmap and architecture, ensure the team has clarity on what to build and why, unblock engineers, conduct or oversee code reviews, drive technical decisions with data, represent the team to stakeholders, manage technical debt, grow junior engineers. The balance shifts: less individual coding, more enabling others to code well.

2. How do you handle a team member who is not performing? The STAR framework works: first understand the root cause (is it unclear expectations, personal issues, lack of skills, motivation). Have a direct and private conversation: be specific about the gap (use examples from code reviews, sprint completion, code quality). Set clear, measurable expectations. Provide support (pair programming, architecture walkthroughs, training). Monitor. Escalate to the manager if no improvement after a defined period. Avoid: ignoring the problem, venting to other team members, or reassigning their work without a conversation.

3. How do you handle technical disagreements within the team? Never let technical disagreements become personal. The goal is the best outcome for the product, not winning the argument. Approach: (a) Ask the other person to explain their reasoning fully before responding. (b) Separate the technical argument from the person. (c) Use data: benchmark the options, prototype, look at industry precedents. (d) For irreversible or high-impact decisions, involve the broader team or a senior engineer for a third perspective. (e) Once a decision is made, the whole team commits to it regardless of their initial preference.

4. How do you prioritise technical debt vs feature work? Tech debt is not monolithic: categorise by impact (does it cause bugs, slow development velocity, block scaling, create security risk?). Visible debt (impacting users or releases) gets priority. Maintenance budget: reserve 15-20% of sprint capacity for debt reduction. Embed debt reduction in feature work: when you touch a module for a feature, clean it up as part of the same PR. Communicate to stakeholders: frame debt as investment in delivery velocity, not as developers wanting to play with code.

Technical leadership requires architectural judgement:

1. How do you approach a system design for a new product feature? Structured approach: (a) Clarify requirements: functional (what does it do?) and non-functional (scale, latency, availability, consistency). (b) Estimate scale: requests per second, data size, read:write ratio. (c) Define the data model. (d) Design the high-level architecture: components, APIs, storage, messaging. (e) Deep-dive on the most critical or complex component. (f) Identify failure modes and how to handle them. (g) Discuss trade-offs made. Tech leads are expected to ask the right clarifying questions before designing, not build on ambiguous requirements.

2. Build vs buy decisions: Factors for build: core competitive advantage, no good existing solution, team has the expertise, customisation requirements are high. Factors for buy: commodity capability, strong existing solutions (payment gateway, email delivery, monitoring), build cost exceeds value, speed to market is critical. Rule of thumb: buy for undifferentiated infrastructure (logging, monitoring, CI/CD), build for differentiating product capabilities. Common Indian company examples: Razorpay built payment processing but buys monitoring (Datadog), logging (Cloudwatch), and email (SendGrid).

3. How do you evaluate and adopt new technology? Evaluation criteria: does it solve a real problem we have now? Is it mature enough for production? What is the community and support like? What is the operational cost (monitoring, maintenance, on-call burden)? Does the team have or can acquire the skills? What is the migration path from the current solution? Process: prototype in a non-critical system, document findings, present trade-offs to the team, make a reversible decision if possible. Avoid: adopting technology because it is new or interesting (resume-driven development).

4. Code review culture: Code reviews are not just bug-catching: they are knowledge transfer, architecture enforcement, and team standard-setting. As a tech lead: set up review guidelines (what to look for, what not to nitpick), model the review behaviour you want (constructive, specific, explanatory), ensure all PRs are reviewed within 24 hours (stale PRs kill developer flow), use automated tools for style/linting so humans focus on logic and architecture.

Tech leads work across product, design, and business:

1. Working with product managers: Tech leads must understand product goals, not just feature specs. Participate in requirement discussions: push back on technically infeasible requirements early. Provide honest time estimates with reasoning. When product changes scope mid-sprint, communicate the cost (what gets deferred) transparently. Build trust by delivering commitments reliably rather than over-promising.

2. Communicating technical concepts to non-engineers: Avoid jargon. Use analogies. Focus on impact, not implementation. Example: instead of 'we need to refactor the database indexing strategy,' say 'our search response time will be 3x faster after this change, which will reduce user drop-off during checkout by approximately 8% based on our A/B test data.' Lead with the business outcome, follow with the technical mechanism if asked.

3. Handling scope creep and unrealistic deadlines: Tech leads often receive requests that cannot be delivered in the expected timeline. Responses: (a) Negotiate scope: 'We can deliver the core feature in 2 weeks, but the analytics dashboard will need another week.' (b) Negotiate timeline with data: 'Based on our velocity, this will take 6 weeks, not 4. Here is the breakdown.' (c) Never agree to a timeline you know is unrealistic: it destroys trust when you miss it. (d) Document scope agreements in writing (JIRA, Confluence, email) to prevent 'but you said...' conflicts.

4. Growing engineers on your team: Tech leads are responsible for the growth of their engineers. Mechanisms: pair programming, architecture walk-throughs, delegating progressively harder problems, code review feedback that explains the why, structured 1:1s where you discuss career goals and progress, sponsoring engineers for visibility (present their work to leadership). The best measure of a tech lead's impact is how senior their junior engineers become.