In a take-home submission, what do reviewers actually learn from the tests you include?

## Tests are a priorities document On a real team, a test suite accumulates. In a take-home, every test was written on purpose inside a few hours, so the suite reads as a direct statement of what you believed was worth protecting. That is why reviewers weight it far beyond pass or fail - a suite of nine well-chosen tests tells them more about your engineering instincts than another hundred lines of feature code would. ## What to cover when you cannot cover everything Work outward from the brief. If a remote-first scale-up's data brief asks you to ingest messy event files, deduplicate and aggregate, the words *messy* and *deduplicate* are the rubric telling you where correctness matters. A defensible suite for that brief might be nine tests: three on the malformed-row path (a missing field, an unparseable timestamp, a truncated line), two on deduplication (exact duplicate, near-duplicate that must not collapse), two on the aggregate arithmetic including an empty input, and two end-to-end tests that run a small fixture directory through the whole path. Total runtime under 40 seconds, one command to invoke. Contrast that with 140 assertions spread across getters, constructors and configuration objects. Coverage looks impressive; the suite protects nothing that could plausibly go wrong; and the reviewer concludes you write tests to satisfy a tool rather than to manage risk. ## The properties reviewers notice **One documented command.** If the README's test command does not work, the tests effectively do not exist. This is the same clean-machine discipline the run instructions need. **Speed.** A suite that takes minutes will be read rather than run. Keep integration-ish tests to small fixtures. **Readable names and arrangement.** A test whose name states the behaviour lets a reviewer understand your intent without reading the body - useful, because they may only skim. **Determinism.** Tests that depend on wall-clock time, network access or iteration order fail on the reviewer's machine and turn a strength into a liability. Inject the clock, use fixtures, avoid live calls. **No test-only cheating.** Assertions that mirror the implementation line for line, or that were clearly written after the fact to pass, are visible and are read as decoration. ## Saying what you did not test The README should carry a short line: which areas are covered, which are not, and what you would add first with more time. This is the cheapest signal in the whole submission. A reviewer who sees no tests around, say, concurrent writes has two hypotheses - you did not think of it, or you thought of it and ranked it below the deduplication logic - and only your README can tell them which. Stating the gap also protects you from the opposite failure: piling on tests in the last hour so the suite looks thorough, which usually produces the shallow coverage described above and eats the time the README needed. ## When the brief says nothing about tests Include some anyway. A brief that omits testing is not granting permission to skip it; for most engineering roles it is a baseline expectation, and its absence is one of the most frequently cited reasons a submission is scored down. The exception is a brief that explicitly says not to write tests, or one so small - a single pure function - that the tests would outweigh the exercise. Even then, one line in the README explaining the decision costs nothing. ## The shape to aim for Few, deliberate, fast, deterministic, named for behaviour, aimed at whatever the brief emphasised, with the gaps written down. That shape survives the time pressure of a four-to-eight hour exercise and gives the reviewer something to talk about in the follow-up conversation, which is often where the take-home is actually decided.