The Take-Home Assignment: What Reviewers Actually Open First
A take-home feels like the fair format — no clock, no stranger watching, just the work. Then the rejection arrives with vague feedback, and it makes no sense, because the tests passed.
The asymmetry nobody mentions
Your submission is one of several in a folder, and the person opening it is doing this on top of their normal job. They are not reading every line. They open the README, they run it, they skim the structure, and they look at two or three files.
That is not laziness — it is the only way the format works at scale. But it means effort spent where they do not look is effort that does not count toward the decision.
Once you accept the fifteen-minute budget, the strategy inverts: the goal is not to show everything you can do, it is to make the right things impossible to miss.
What gets opened, in order
The README. Almost always first. If it does not explain how to run the project in under a minute, the review starts annoyed. If the project does not run at all, it usually ends there.
The start command. A single command that works on a clean machine is worth more than any abstraction in the codebase. Anything requiring local setup you forgot to document counts against you, and you will never hear about it.
The entry point. They want to see how you organised the flow — where a request arrives, where the logic lives, where the data goes.
One or two files of real logic. Usually the hardest part of the problem. This is where they judge whether you write code other people can maintain.
The tests, briefly. Rarely read line by line, but checked for existence and shape. A few tests on the tricky parts read better than exhaustive coverage of getters.
Overbuilding is the most common failure
The instinct is to demonstrate range: add a caching layer, an abstraction over the storage backend, a plugin system for requirements nobody mentioned. It reads as seniority to the person writing it and as poor judgement to the person reviewing it.
What it signals is that the candidate cannot tell which problems are worth solving. On a real team that is expensive, because the cost lands on everyone who touches the code afterwards.
The stronger move is to solve exactly what was asked, cleanly, then write two lines in the README about what you deliberately left out. “No caching — the dataset is small enough that it would add complexity without measurable benefit.” That sentence demonstrates the judgement the abstraction was trying to imply.
Write the README as if you will not be there
Because you will not be. Three short sections cover almost everything: how to run it, what decisions you made and why, and what you would do next with more time.
The middle section is the one candidates skip and reviewers value most. Every non-obvious choice is invisible in code — it looks like the only option rather than a decision. Two sentences turn a silent choice into demonstrated reasoning.
The third section is where you get credit for what you did not build. Limitations listed by you read as awareness. The same limitations found by the reviewer read as gaps.
Scope and the clock
If the brief says four hours, spending twelve is not the flex it feels like. Some reviewers explicitly check whether the submission matches the stated budget, because a candidate who cannot time-box will not be able to on the job either.
If you did go over, do not hide it and do not brag about it. State the actual time in the README and say what you would cut to fit the brief.
And if you ran out of time with something unfinished, ship it unfinished with a note. A missing feature you named is a scoping decision. The same gap unmentioned is an oversight.
The follow-up call is the real test
Many take-homes are followed by a conversation about the code, and that call usually carries more weight than the submission itself. It is where they find out whether you understand what you wrote.
Expect the uncomfortable version: not “why did you do this” but “what breaks if the input is ten thousand times larger”, or “what changes if a second data source arrives tomorrow”.
Re-read your own code the hour before. Being unable to explain a decision you made a week ago is a worse signal than any design flaw in it.
Where a copilot fits
Interview Copilot follows the round in real time and puts a structure on your screen while the other person is still talking — what the question is actually asking, the constraint that matters, and the trade-off worth saying out loud. Not a script to read: a scaffold you speak from, in your own words.