How would you introduce TDD to a team?

WHAT THIS TESTS: This is a behavioral question about influence and pragmatism, disguised as a technical question. The interviewer is evaluating your ability to act as a change agent. They want to see if you can introduce new ideas by building consensus and using data, rather than by asserting authority or dogma. It tests your emotional intelligence and strategic thinking as a senior engineer.

A GOOD ANSWER COVERS: A strong answer proposes a phased, data-driven approach. First, seek to understand the team's current process and constraints without judgment. Second, propose a small, low-risk pilot project on a new feature, volunteering to lead the effort. Frame it as an experiment to gather data. Third, after the pilot, present concrete results focusing on business value, such as reduced bug counts, lower maintenance costs, or faster follow-on development. Fourth, based on the data, propose a gradual adoption strategy, like using TDD for all new services or complex bug fixes, while explicitly not requiring rewrites of existing, stable code.

COMMON WRONG ANSWERS: The most common red flag is the 'TDD dogmatist' who insists on immediate, 100% adoption for all code, ignoring team context and deadlines. This shows a lack of pragmatism. Another is 'the critic' who spends time explaining why the team's current process is bad, which alienates peers. A vague answer like "I'd schedule a meeting to explain the benefits" is also weak; senior candidates must provide a specific, actionable plan. Finally, failing to acknowledge the initial productivity cost of learning TDD is a miss; a good answer addresses this head-on and frames it as a long-term investment.

LIKELY FOLLOW-UPS: Expect follow-ups like: "What if your manager says there's no time for a pilot?" (Your answer should focus on reframing it as an investment to save future time on bug-fixing). "What specific metrics would you track?" (e.g., defect escape rate, time-to-resolution for bugs, cyclomatic complexity). "What if the team is still resistant after a successful pilot?" (Show flexibility; TDD is a means to an end—quality software—not the only means).

ONE CONCRETE EXAMPLE: "On a previous team, I proposed using TDD for a new microservice that had complex business logic. I paired with another engineer and we tracked our metrics. Our initial story point velocity was 10% lower than average. However, the service launched with zero post-release defects, compared to an average of 3-4 for other new services. The subsequent feature additions were also 20% faster because the high test coverage gave us confidence to refactor. I presented this data to the wider team, which led to TDD becoming the standard for any new greenfield project."