A take-home caps you at four hours: how do you decide what to cut?

## The cap is part of the spec A take-home with a stated four-hour cap on a catalog-import exercise is not really asking whether you can write an importer. It is asking what you build when the budget is fixed and the wish list is not — which is the everyday condition of the job. Candidates who read the cap as a polite suggestion and submit twelve hours of work usually believe they have shown enthusiasm. From the reviewer's chair they have shown that a stated constraint did not bind them, and they have made their submission incomparable with everyone else's. ### Spend in this order **1. The core path, correct, end to end.** Decide the narrowest thing that is unambiguously the point of the exercise — for an import: read the feed, validate rows, aggregate quantities by SKU, surface the rejected rows — and get it working before anything else exists. A partial pipeline that works from input to output is a submission; four beautifully separated layers with no path through them is not. **2. Tests where a reviewer cannot take you on trust.** Not uniform coverage; targeted coverage. The reviewer will trust that you can loop over rows. They will not trust, without seeing it, that you handled a duplicate SKU appearing in two batches, a quantity that nets to exactly zero, a malformed row in the middle of an otherwise good file, or an empty feed. Those are the tests that carry information. Two tests at the exact boundaries are worth more than twenty around the happy path. **3. Legibility.** Names that say what the thing is, one obvious entry point, and a documented way to run the program and its tests. Reviewers read under time pressure too; anything that costs them ten minutes to figure out costs you more than it saved you. **4. Only then, breadth.** A second input format, richer reporting, a configuration layer. ### What to cut first, and what never to cut Cut **speculative structure** first: the interface with one implementation, the plugin seam for the source nobody asked for, the configurability for values that will never vary. This is the most common four-hour sink and it is invisible to the candidate, because building it feels like senior work. In a scoped exercise it reads as the opposite — an inability to distinguish the requirement from the imagined generalisation. Cut **breadth of feature** next: fewer supported cases, done properly, is a defensible submission. Do not cut **correctness of what you claim to have built**. A feature that is present and quietly wrong is worse than the same feature absent with a line in the notes saying it was out of scope, because the first misleads the reviewer and the second informs them. Do not cut **tests down to zero**. This is the classic wrong trade — dropping tests to fit one more feature. The extra feature adds a little breadth; the missing tests remove the reviewer's ability to believe any of it, including the parts that are genuinely fine. Do not cut **the written record of your decisions**, which is the artifact that converts a truncated submission into a deliberate one. ### Handling the cap honestly If you overrun, say so plainly and say by how much — a note that the core took four hours and you spent forty extra minutes on the boundary tests is a small, verifiable, honest number. Silence about an obvious twelve-hour submission is the version that damages you, because the reviewer can usually tell, and now they are also weighing candour. If the scope genuinely cannot be met in the cap, that is often the exercise's actual question. The strong move is to meet the cap and document the gap; the weak move is to meet the scope and ignore the cap. ### The reviewer's chair Reviewers usually spend far less time reading than you spent writing. They are asking: can this person pick the important part, make it actually work, prove it, and tell me what they traded away. Nothing on that list is *finished everything*. Two submissions arrive; one implements every listed feature with no tests and a half-broken edge case, the other implements the core cleanly with four sharp boundary tests and a short note listing the three things deliberately left out and what the production version would add. The second wins nearly every time, and the candidate who wrote it usually stopped an hour earlier.