What they're testing
Whether you know fake timers and clock injection — the two tools that make an unreliable class of test reliable.
The short answer~30 seconds
Three rules. One: don't use real time — use fake timers to advance the clock (vi.advanceTimersByTime), so a test for a five-minute debounce runs in a millisecond. Two: don't call Date.now() directly in the code, inject a clock so tests can pin the moment. Three: wait on a CONDITION rather than a duration — waitFor until the expected state appears, with a deadline, instead of sleep(500).
The long answer
Clock injection unlocks tests that are otherwise near-impossible to write: a token expiring at exactly second 3600, a transaction landing across a date boundary, a schedule crossing a daylight-saving change. Those cases are hard to reproduce in production and are exactly where bugs hide — so being able to test them is worth far more than the cost of one extra parameter.
With genuinely async code the commonest trap is the test finishing BEFORE the promise resolves, so it passes while verifying nothing. The tell: a deliberately wrong assertion still passes. So whenever I write an async test I make it fail once — if I can't make it fail, it was never running that assertion.
What they'll ask next
?How do you test a retry with backoff?
Fake timers are mandatory, otherwise the test waits tens of real seconds. And you should assert both the NUMBER of attempts and the GAPS between them — asserting only the final result lets a broken backoff still pass.
These lose points
await sleep(100)then assert. It passes locally and fails randomly on CI, and someone will fix it by raising it to 500.