Question 1

What is the difference between a tech lead and an engineering manager?

Accepted Answer

In short: A tech lead owns technical direction for a team: architecture and design decisions, code quality, breaking down work, unblocking developers and mentoring — and still writes significant code. An engineering manager owns people and delivery: hiring, career growth, performance reviews, team health, process and cross-team coordination, with less hands-on coding. In smaller teams (and in many Indian IT services companies team lead roles) one person does parts of both.

Question 2

Explain Scrum roles, events and artifacts.

Accepted Answer

In short: Accountabilities: Product Owner (maximises value, owns and orders the Product Backlog), Scrum Master (coaches the team and organisation in Scrum, removes impediments), Developers (create the increment, own the Sprint Backlog). Events: the Sprint (container), Sprint Planning, Daily Scrum (15 min), Sprint Review, Sprint Retrospective. Artifacts with commitments: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done (2020 Scrum Guide).

Question 3

What is the difference between Agile and Waterfall?

Accepted Answer

In short: Waterfall is sequential — requirements, design, build, test, deploy — each phase completed before the next, with change being costly; it suits fixed, well-understood requirements and regulated contexts. Agile delivers in short iterations with working software each cycle, continuous feedback, and embraces change; it suits evolving requirements. Many enterprises use hybrids (fixed milestones with agile execution).

Question 4

What are story points and velocity?

Accepted Answer

In short: Story points are relative estimates of effort, complexity and uncertainty (often Fibonacci: 1, 2, 3, 5, 8, 13), agreed by the team with planning poker — not hours. Velocity is the average number of points a team completes per sprint, used to forecast how much to plan. Velocity is team-specific: don t compare teams or use it as a performance target.

Question 5

Scrum vs Kanban — when would you use each?

Accepted Answer

In short: Scrum works well for product development where you can plan in fixed sprints with a stable team and regular reviews. Kanban suits continuous, unpredictable inflow like support, maintenance and operations: work is pulled through columns with WIP limits, measured by cycle time. Teams often combine them ( Scrumban ) — e.g. sprints for features with a Kanban lane for production support.

Question 6

How do you estimate a project or a large feature?

Accepted Answer

In short: Clarify scope and acceptance criteria; break it into small tasks (≤ 2–3 days) including testing, reviews, deployment and documentation; estimate with the people doing the work (planning poker or three-point estimates); add buffers for risks and unknowns (spikes for unclear areas); account for real capacity (meetings, support, leaves); state assumptions and dependencies explicitly; give a range rather than a single date; re-forecast as you learn and communicate changes early.

Question 7

How do you delegate work in your team?

Accepted Answer

In short: I delegate outcomes with context: why it matters, what done looks like, constraints, deadline and check-in points. I match tasks to skills and growth goals — a stretch task for a junior with a senior pairing, critical-path work for experienced people — and adjust my involvement to their experience (directing for new members, delegating to experts). Work is tracked on the board, I stay available to unblock, and I avoid taking the hardest tasks myself all the time so the team grows and I don t become a bottleneck.

Question 8

How do you mentor junior developers?

Accepted Answer

In short: Regular 1:1s and pairing sessions; clear coding standards and examples; code reviews that explain the why rather than just fixing things; gradually larger tasks with support (first a bug fix, then a small feature, then owning a module); encouraging questions and making it safe to make mistakes; sharing resources and certification paths; and celebrating progress publicly. I measure success by how independently they can deliver after a few months.

Question 9

How do you handle a team member who is underperforming?

Accepted Answer

In short: Gather facts first, then talk privately and early with specific examples, and listen to understand the cause (unclear expectations, skill gap, personal issues, motivation, wrong role). Agree on a concrete improvement plan with support — training, pairing, smaller scoped tasks — and regular check-ins. Recognise improvements. If there s no progress after a fair period, involve my manager and HR for a formal plan, documenting everything and treating the person with respect throughout.

Question 10

How do you resolve a conflict between two team members?

Accepted Answer

In short: Speak with each privately to understand their perspective and underlying concerns, then bring them together focused on facts and the shared goal. For technical disagreements, agree criteria and use data or a quick spike to decide; if still split, I make the call, explain the reasoning, record it (ADR) and ask both to commit. For personal friction, set expectations for respectful behaviour and follow up. I address conflict early, before it affects the team.

Question 11

How do you handle scope changes requested in the middle of a sprint?

Accepted Answer

In short: Protect the Sprint Goal. I acknowledge the request, assess urgency and impact with the Product Owner: if it s truly critical (production issue, regulatory), we swap out work of similar size and make the trade-off visible; otherwise it goes into the backlog for the next sprint planning. For client projects, significant changes go through impact analysis and a change request covering effort, timeline and cost.

Question 12

How do you report project status to stakeholders?

Accepted Answer

In short: Regular, concise updates: progress vs plan (with a RAG status), key achievements, risks and issues with mitigation plans, decisions needed from them, and next steps. I share bad news early with options and a recommendation, back statements with data (burnup charts, defect counts), tailor the detail to the audience (executives vs product owners), and keep a written record.

Question 13

What do you do in a sprint retrospective that has become boring and repetitive?

Accepted Answer

In short: Change the format (Start/Stop/Continue, 4Ls, sailboat, timeline), focus on one or two impactful improvements rather than long lists, review whether previous action items were done (and why not), use data (cycle time, escaped defects, interruptions), rotate the facilitator, and make it safe to raise uncomfortable topics. If the same issues keep coming back, escalate the systemic blockers outside the team.

Question 14

How do you handle technical debt?

Accepted Answer

In short: Make it visible as backlog items describing the business impact (slower delivery, incidents, security risk); prioritise debt in areas that change often or cause incidents; reserve regular capacity (e.g. 15–20% per sprint) or attach refactoring to related feature work (Boy Scout rule); prevent new debt with Definition of Done, reviews and automated quality gates; and avoid big-bang rewrites unless the case is very strong — prefer incremental Strangler Fig approaches.

Question 15

How do you make architecture or technology decisions in a team?

Accepted Answer

In short: Start from requirements (including non-functional ones and constraints like budget, skills and timelines), list options, evaluate them against agreed criteria, run a spike or proof of concept for risky unknowns, involve the team and relevant experts, decide (and own the decision), and document it in an Architecture Decision Record with context, alternatives and consequences. Revisit decisions when context changes. I prefer reversible decisions made quickly and irreversible ones made carefully.

Question 16

How do you measure your team's performance?

Accepted Answer

In short: At team level, never individuals by raw output: DORA metrics (deployment frequency, lead time, change failure rate, time to restore), flow metrics (cycle time, throughput, WIP), quality (escaped defects, incident trends), predictability (planned vs delivered), and team health (engagement, attrition, on-call load). Business outcomes — features adopted, customer issues resolved — matter most. I use metrics to find improvement opportunities, not to rank people.

Question 17

How would you build and scale a new team from 3 to 10 developers?

Accepted Answer

In short: Define the team s mission and the roles needed (mix of seniorities and skills); set up a structured hiring process with a scorecard; create strong onboarding (docs, buddy, dev environment scripts, first-week deliverable); establish working agreements, coding standards, CI/CD and review practices before scaling; split into sub-teams or feature pods around 5–7 people with clear ownership as you grow; grow leaders internally (tech leads per pod); and keep communication channels clear (team rituals, ADRs, documentation).

Question 18

Your project is two weeks from the deadline and you realise it will be late by one week. What do you do?

Accepted Answer

In short: Verify the estimate with the team and find the cause. Inform stakeholders immediately — no surprises — with options: reduce scope (ship must-haves first, defer nice-to-haves), add focused help where it actually speeds things up (not late-stage new joiners on complex code — Brooks s law), remove distractions from the team, parallelise testing, or move the date. Give a recommendation, get a decision in writing, update the plan, and run a retrospective later on why the risk wasn t spotted earlier.

Question 19

A critical production issue occurs on Friday evening. Walk me through how you handle it.

Accepted Answer

In short: Acknowledge and assess severity; assemble the right people (on-call, owners) and appoint an incident lead; open a communication channel and inform stakeholders with regular updates. Prioritise restoring service — roll back the last deployment, toggle a feature flag, fail over, scale up — before deep root-cause analysis. Once stable, monitor, then do a blameless post-mortem the next week with a timeline, root causes (5 Whys), and owned action items (tests, alerts, runbooks, safer deployments). Make sure people who worked late get time off.

Question 20

The client keeps adding requirements without changing the deadline. How do you manage it?

Accepted Answer

In short: Make the impact visible: maintain a prioritised backlog with estimates, show the client what each new request displaces, and agree priorities together (MoSCoW: Must/Should/Could/Won t). Use a change-request process for contractual scope, protect the current sprint, and propose phased delivery — an MVP by the date, the rest in later releases. Document decisions and keep the relationship collaborative rather than confrontational.

Question 21

Your best developer resigns in the middle of a critical release. What do you do?

Accepted Answer

In short: Have an honest conversation to understand the reasons — if it s fixable (role, growth, compensation) and appropriate, explore a counter-offer with my manager, but don t rely on it. Immediately plan the knowledge transfer: document their modules, pair them with others during the notice period, record walkthroughs, and review critical code together. Re-plan the release with stakeholders based on reduced capacity. Longer term, reduce single points of failure by rotating ownership, and look at retention across the team.

Question 22

Two senior developers disagree strongly on using microservices versus a modular monolith for a new product. How do you decide?

Accepted Answer

In short: Bring the discussion back to requirements: team size, expected scale, deployment independence needs, domain boundaries, operational maturity, timeline and cost. Have each present trade-offs against those criteria; if uncertain, run a short spike. For most new products with one team, a well-structured modular monolith is simpler and can be split later along module boundaries. Decide, document the reasoning and the triggers that would make us revisit it in an ADR, and ask both to commit.

Question 23

A team member is consistently working late and seems burned out. What do you do?

Accepted Answer

In short: Talk privately and with care: ask how they re doing and what s driving the extra hours (workload, unclear priorities, perfectionism, personal stress, fear of failing). Reduce or redistribute their load, clarify priorities, remove blockers, encourage time off and normal hours, and check the team s overall planning so this isn t systemic. Point them to company support (EAP) if appropriate, and follow up regularly.

Question 24

You are asked to lead a team working on a technology you don't know well. How do you approach it?

Accepted Answer

In short: Be honest about the gap and learn fast: study the architecture and fundamentals, pair with the team s experts and rely on them for detailed technical decisions, while I contribute leadership strengths — planning, unblocking, stakeholder management, quality practices. I d get hands-on with small tasks to build credibility, use external help (docs, vendor support, other teams) and set myself a learning plan with milestones.

Team Lead, Managerial & Agile Interview