Explain the TDD red-green-refactor cycle.
Assesses fundamental understanding of Software Testing & QA conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Test-driven development is a short cycle that drives design from tests.
- Red: write a failing test for the smallest next behaviour. It must fail, otherwise it proves nothing.
- Green: write the simplest code that makes it pass, without worrying about elegance.
- Refactor: improve the code and tests, removing duplication and clarifying names, while keeping the suite green.
red -> green -> refactor -> repeat
Because tests come first, the code is testable by construction, interfaces are designed from the caller's perspective, and each requirement has a test. The tight feedback loop encourages small steps and prevents scope creep.
Criticisms are real: it does not suit exploratory or UI-heavy work well, it can produce fragmented designs if driven mechanically, and it demands discipline. Variants exist, such as behaviour-driven development with Given-When-Then scenarios, and test-first is also common without the strict refactor step. The lasting value is the safety net and incremental design.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.