How would you introduce TDD to a team?

WHAT THIS TESTS: This question assesses your skills in technical leadership and influencing change. The interviewer isn't just looking for a definition of TDD. They want to see if you can act as a change agent pragmatically and empathetically. They are testing your ability to diagnose a team's process, build a case for improvement, and execute a gradual rollout strategy that minimizes disruption and builds consensus, rather than imposing a rigid dogma.

A GOOD ANSWER COVERS: A strong answer has four parts. First, start with empathy and investigation: seek to understand the current workflow and its pain points (e.g., long QA cycles, high bug counts in production). Second, build a case for TDD by connecting it to those specific pain points, not just abstract "best practices". Third, propose a gradual adoption strategy. This means starting small, perhaps with one volunteer pair on a new, non-critical feature or a bug fix. Fourth, define how to measure success. Suggest tracking metrics like bug escape rate, time to merge, or even developer sentiment before and after the pilot.

COMMON WRONG ANSWERS: A major red flag is advocating for a "TDD mandate" or an immediate, team-wide switch. This ignores the learning curve and the reality of existing projects and deadlines. Candidates who lecture on the theoretical purity of TDD without connecting it to the team's actual problems sound dogmatic and lack senior-level pragmatism. Another mistake is failing to define a measurement strategy; without metrics, you can't prove the change was beneficial. Finally, describing TDD incorrectly (e.g., just writing tests first, but not the red-green-refactor cycle) shows a lack of fundamental knowledge.

LIKELY FOLLOW-UPS: Expect questions like: "What if the pilot fails or the metrics get worse? What would you do?". "How would you handle a senior engineer who is resistant to this change?". "On which types of projects is TDD less effective?". "How does TDD fit with integration or end-to-end tests?".

ONE CONCRETE EXAMPLE: "I'd propose we try TDD on the upcoming 'User Profile V2' feature, which is new and isolated. We'll track the number of bugs found by QA for this feature compared to the last similar-sized feature, which had 8 QA-found bugs. We'll also do a 30-minute mob-programming session to walk through the red-green-refactor cycle on a simple function so everyone sees it in action. If we see a reduction in bugs and the team feels productive, we can discuss adopting it for the next new service."