When starting a feature with TDD, how do you choose outside-in or inside-out?

### The question behind the question An interviewer asking this is not checking whether you know two labels. They are checking whether you pick a starting point from the shape of the risk in front of you, or from habit. Test-driven development leaves the starting point open. **Outside-in** begins at an outer boundary, inventing collaborator roles as the need appears and standing them in until they are built. **Inside-out** begins with domain behaviour, built from real objects, and connects the outside world last. The choice is per feature — sometimes per layer inside one feature — and it is reversible. ### What actually decides it **Where is the uncertainty?** If you do not yet know what the collaborators should be, how responsibilities should split, or what the entry point needs, outside-in turns that uncertainty into a sequence of concrete design decisions taken at the moment of need. If the collaboration is obvious and the risk is a gnarly rule — a rating calculation, a deduplication window, a parsing edge case — inside-out gets you to the hard part on the first cycle instead of the fourth. **Is the outer contract already fixed?** An agreed message schema or a published endpoint shape removes the main thing outside-in is good at discovering. There is less to invent at the boundary, so start where the open questions are. **How stable is the collaborator boundary?** Outside-in leaves stand-ins in place, and a stand-in is a frozen picture of a contract. Against a volatile or externally-owned collaborator those pictures rot quietly. Against a stable, well-understood seam they cost little. **Which failure can you afford?** Outside-in's characteristic failure is a green suite over a mismatch — two sides of a seam that never met. Inside-out's is discovering late that the boundary is awkward, after the core has committed to a shape. Ask which of those is cheaper to absorb in this codebase. **How many people are on it?** With an eleven-person team and three pairs on one feature, outside-in has a coordination advantage that has nothing to do with design purity: inventing the roles first publishes the seams, so pairs can take one each and integrate against agreed signatures instead of waiting. Solo on a small feature, that advantage disappears. **Do you already have an outer harness?** If an end-to-end or acceptance-level test can be written cheaply, outside-in has a natural outermost loop to hang the work from. If standing up the boundary takes a day, that is a day before the first red test. ### The answer that lands The strong answer refuses the dichotomy and then says how it mixes them. A common shape: sketch outside-in far enough to discover the seams and to get one honest behaviour running end to end, then switch to inside-out for whichever collaborator carries the real domain difficulty, building it with real objects and its own tests. Afterwards, deliberately re-point some outer tests at the now-real collaborators rather than leaving every seam permanently stood in. ### A worked decision The smart-meter ingest path: accept a reading, discard duplicates in a rolling window, convert pulse counts to kilowatt-hours, persist. The inbound schema was agreed with the device vendor months earlier — no discovery there. The conversion has awkward cases: meter rollover at `999999` pulses, a documented pulses-per-kilowatt-hour constant of `1600`, and readings that arrive out of order. So the team drove the converter and the duplicate window inside-out with real objects, then wrapped them outside-in from the handler to settle the storage and error-reporting seams, which were genuinely open. They also made one rule explicit, having been bitten before: the seam to the store gets a test that exercises the real store, because the previous release rounded every stored reading to two decimal places while the stood-in store in every handler test accepted six — a silent corruption that no green suite had any way to see. ### Judgement, not doctrine Say plainly that the evidence for either school producing better designs is contested, and that experienced teams converge on mixing rather than on a winner. A candidate who argues one school is simply correct is telling you they have only worked one way. A candidate who says "outside-in when the collaboration is the unknown, inside-out when the rule is the unknown, and re-point the stand-ins once the real thing exists" has actually made the call before.