Team Lead and Engineering Manager Interview Questions India 2026: Leadership, Processes, and People

What EM interviews evaluate:

1. The shift from IC to EM: Engineering managers are multipliers: their output is their team's output. Interviewers assess whether you have made the mental shift from optimising your own performance to optimising the team's performance. Signs of this shift in answers: 'I helped my team deliver X' (not 'I delivered X'); 'I removed the blocker so the team could continue' (not 'I solved the problem'); 'I hired an engineer who is now better than me at Y' (not 'I am the expert in Y').

2. People management depth: Can you handle: difficult conversations (low performance, missed deadlines, interpersonal conflict)? Career development (helping engineers at different career stages grow)? Hiring (judging technical candidates, designing interview loops, closing offers)? Motivation (keeping engineers engaged and challenged during long-term projects or technical debt phases)?

3. Technical credibility: Engineering managers at Indian product companies are expected to maintain technical credibility: understand the architecture, make trade-off decisions, review designs, and unblock engineers. Interviewers verify you are not purely a project manager. Be prepared to discuss: a significant architectural decision you made or influenced, a technical trade-off you navigated with your team, and how you kept your technical skills current while managing.

4. Process and delivery: Can you run a team effectively? Questions around: how you run sprint planning and retrospectives, how you handle estimation and scope changes, how you communicate status to stakeholders, and how you define and track technical quality metrics (test coverage, incident rate, deployment frequency).

Difficult people management scenarios:

1. Handling a low-performing team member: Structure: (1) Identify the gap: is it skill, motivation, or fit? Have honest 1:1 conversations to understand the root cause. (2) Set clear expectations: document what 'good' looks like for the role; make the performance gap explicit with specific examples. (3) Create a support plan: pair them with a stronger engineer; provide a course or learning resource; adjust their work to play to their strengths. (4) Progress check (30-60 days): assess if performance has improved; if not, escalate to a formal Performance Improvement Plan (PIP) with HR. (5) Exit: if the PIP does not result in improvement, proceed with termination per the company's process.

Anti-patterns to avoid in your answer: waiting too long to address the issue (hoping it resolves itself); delivering feedback in a public setting; making it personal ('you are not a good engineer') rather than specific ('the last three code reviews had significant issues: X, Y, Z').

2. Interpersonal conflict between two engineers: Approach: (1) Separate conversations: speak to each engineer individually first; understand both perspectives without taking sides. (2) Identify the root cause: is the conflict about technical disagreement (resolve by establishing a decision-making framework), personal style differences (coach both on professional communication), or competition for the same opportunity (structural issue; address the role/opportunity allocation)? (3) Joint resolution: once each has felt heard, bring them together to agree on working norms. (4) Follow-up: check in after 2 weeks to confirm the situation has improved.

3. Delivering negative performance feedback: The SBI model (Situation, Behaviour, Impact): 'In the code review last Tuesday (situation), you dismissed the feedback from the senior engineer without engaging with it (behaviour). This made the senior engineer feel their input was not valued and reduced their willingness to review your code in the future (impact).' Avoid: vague feedback ('you need to improve your attitude'), delayed feedback (months after the incident), and feedback delivered during a stressful time.

Technical leadership questions:

1. How do you make architectural decisions as an EM? Best practice: involve the team in the decision. A good EM does not make architectural decisions in isolation; they facilitate the process: - Gather context: have the relevant engineers research the options and write a design document - Define criteria: what matters most (simplicity, performance, operational burden, team expertise, migration cost)? - Facilitate discussion: create space for engineers to advocate for different options; ensure all perspectives are heard - Make the call: if consensus is not reached, the EM makes the final decision with the team's input - Communicate: share the decision and its reasoning with the broader team

2. Managing technical debt: Technical debt is normal and not necessarily a problem. The problem is when unmanaged technical debt slows the team down significantly. Framework for managing technical debt: (1) Quantify the impact: 'our test coverage is 40%, which means we spend an average of 2 days per sprint debugging production issues that tests would have caught.' (2) Prioritise ruthlessly: not all technical debt deserves attention; fix debt that is actively causing pain (slow deployments, frequent bugs, difficulty adding features in a specific area). (3) Integrate into sprints: allocate 20% of sprint capacity to technical debt; do not do 'debt sprints' (the product team will resent the lost velocity and cut them). (4) Track and communicate: show the product team that reduced technical debt correlates with faster feature delivery.

3. How do you handle a team that is consistently missing deadlines? Diagnosis first: is it poor estimation (the team is optimistic about complexity)? Scope creep (stakeholders keep adding requirements)? Unexpected technical complexity (the problem is harder than thought)? External dependencies (blocked on another team)? Capacity issues (team is too small for the scope)? Address the root cause: if estimation, implement more rigorous breakdown (story points + historical velocity); if scope creep, enforce a change control process with the product manager; if external dependencies, escalate the dependency or change the project plan.

Engineering manager responsibilities:

1. Hiring: Designing the interview loop: each interview round should assess a specific competency that cannot be assessed by other rounds. Avoid repetition. Typical engineering loop for an Indian product company: recruiter screen (communication, experience, logistics), coding round (DSA), technical interview (system design or deep technical discussion), behavioural/values round, and hiring manager conversation. Your role as EM in the loop: run the behavioural/values round; calibrate the other interviewers; make the final hire/no-hire call; close the candidate after the offer.

2. Career development: Every engineer on your team should have a clear development goal and a plan for achieving it. 1:1s (at least weekly): use them primarily for the engineer's concerns and development, not your project status updates (use Slack or standups for status). Performance reviews: give feedback that is specific, timely, and actionable. Promotion advocacy: actively make the case for your engineers' promotions; do not wait for them to ask.

3. Team culture: Psychological safety: the most important predictor of team effectiveness (Google's Project Aristotle study). Engineers should feel safe to take risks, share opinions, and make mistakes without fear of punishment. How to build it: model the behaviour yourself (share your mistakes and learnings publicly); call out blame-oriented responses in retrospectives; celebrate attempts even when they fail.

4. Managing up: Engineering managers must manage their relationship with their own manager (Director of Engineering, VP Engineering, or CTO). Best practices: no surprises (proactively share bad news early); bring solutions, not just problems; make decisions yourself and inform your manager (do not escalate everything); advocate for your team's resources and headcount using business impact language.