How would you introduce Test-Driven Development to a test-after team?

WHAT THIS TESTS: The interviewer wants to know if you can change engineering culture without relying on hierarchy. They are looking for evidence of empathy, experimentation, and data-driven persuasion rather than dogma. The role likely involves joining as a staff engineer or senior lead where authority must be earned.

A GOOD ANSWER COVERS: First, diagnose before prescribing. Interviewers expect you to mention talking to teammates about specific pain points like flaky test suites, long debug sessions, or regressions in production. Second, frame TDD as a risk-reduction tool, not a moral imperative. Connect it to outcomes the team already cares about, such as reducing defect escape rate or shrinking code review cycles. Third, propose a bounded experiment rather than a mandate. A strong candidate suggests a two to four week pilot on a single service, component, or bug-fix category, with explicit success criteria like cycle time, bug count, or developer self-reported confidence. Fourth, describe concrete coaching mechanisms such as pair programming, mobbing, or lunch-and-learns where the team writes a failing test together. Fifth, acknowledge the cost and define a rollback plan. If the pilot slows delivery without improving quality, the team abandons it and documents lessons learned.

COMMON WRONG ANSWERS: Mandating TDD for all new code immediately signals a lack of influence skills. Dismissing the existing test-after coverage as worthless alienates the team and ignores sunk cost. Claiming TDD always improves velocity without caveats sounds like cargo-culting. Proposing a big-bang rewrite of the test suite to fit TDD is unrealistic for a production codebase. Failing to mention the red-green-refactor cycle or confusing TDD with simply having unit tests reveals shallow technical depth.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a senior engineer who refuses to participate. They might probe what metrics you would collect during the pilot. They could ask how TDD interacts with legacy code that lacks testability, or how you would adapt the approach for integration-heavy services versus pure logic modules. Another common thread is whether you would enforce TDD in code review gates.

ONE CONCRETE EXAMPLE: Suppose the team maintains a pricing microservice and recently shipped a regression that overcharged customers. You propose a four-week pilot for all new pricing rules. The team agrees to write one failing unit test before implementation for every new pricing rule ticket. You track three metrics: time from ticket start to merge, number of production incidents related to pricing, and a weekly one-to-ten confidence score from the two engineers on the service. After four weeks, merge time stayed flat but incidents dropped from three to zero and confidence rose from five to eight. You present the data in a team retro and let the team vote on whether to expand the practice to the inventory service.