What they're testing
Whether you can work in code you didn't write — which is most of the job.
The short answer~30 seconds
Write characterization tests first: run the function over a spread of realistic inputs and record the CURRENT output as the expectation — even where you believe it's wrong. The goal isn't proving the code correct but building a net so any behaviour change becomes visible. Only then do you extract pieces, one small step at a time, re-running the net after each.
The long answer
Recording the wrong behaviour sounds backwards and is the crux: somewhere someone depends on it, and you need to KNOW when you change it rather than change it accidentally and learn from a ticket. If you decide to fix the behaviour, you change the test deliberately with a reason recorded — a documented change rather than a side effect.
The practical obstacle is usually that the function can't be called from a test because it reads the database directly, calls an API, or uses new Date(). Michael Feathers's technique for this is the "seam": a place where behaviour can be changed without editing the logic — wrap the call in a protected method and override it in a test subclass, or extract it into a parameter. It's ugly and temporary, and it buys you the net you need to clean up the rest.
What they'll ask next
?With limited time, which parts do you cover first?
Exactly the paths you're about to touch, plus the ones most expensive when broken (money, access control, data loss). Don't try to cover all 800 lines — that turns a two-day change into a two-month project which usually gets cancelled halfway.
These lose points
- Refactoring first and testing afterwards. Without the net you don't know what you changed, and old code always has behaviour you didn't predict.
- Proposing a rewrite. Occasionally right, and proposing it before understanding the existing code signals you haven't read it.
Sources
- Michael Feathers — Working Effectively with Legacy Code (seams, characterization tests)
- Martin Fowler — Refactoring: only refactor behind passing tests