FDE Take-Home Assignment Preparation: Score the Rubric Before You Code
Updated · Tech checked
Take-homes are graded on README clarity, error handling, assumption documentation, and tests as much as working code. Budget strictly, ship a complete small thing, and write the 'with more time' section - that's the FDE signal.
The short answer
Companies use take-homes because FDE work is unsupervised scoped delivery - so the take-home is judged as a delivery artifact, not just code. The rubric under every decent take-home: does it run, does it fail gracefully, could a teammate pick it up, did the candidate document judgment calls?
Before you code
- Confirm scope in writing (one short email: "To confirm: X, Y in; Z out; ~4h budget").
- Read for hidden requirements: "handle duplicates," "report errors" are requirements, not suggestions.
- Set your time box and decide upfront what "done" means at 80% - a complete, documented 80% beats an untested 110%.
What to build (in priority order)
- Working core path with correct output.
- Failure handling: bad input, empty input, upstream timeout, duplicates.
- Tests for the ugly cases.
- README: assumptions, run instructions, design notes, "with more time" list.
- Small polish: type hints, consistent naming, no dead code.
The README skeleton that scores
# Task: [one line]
## Run
[exact commands, no mystery env]
## Assumptions & decisions
- [each judgment call, one line why]
## Known limitations
- [honest list]
## With more time
- [prioritized next steps]Submission checklist
- [ ] Fresh-clone run verified (delete cache, re-run)
- [ ] No secrets, no absolute personal paths
- [ ] Errors surfaced (exit codes, messages), not swallowed
- [ ] One paragraph in your email noting the trade-offs you made
Never inflate scope beyond the stated hours to "impress." Time-boxing honesty is itself the FDE competence being tested.
Continue: System design scenarios · Interview guide