Most take-home assignments are written once, five years ago, by someone who is no longer at the company. They get passed down, slightly modified each cycle, and nobody quite knows why the deadline is 72 hours or why the candidate has to build a REST API when the role is frontend-only.
This guide is about writing from scratch — or auditing what you have. The goal: an assignment that takes a candidate 2–4 hours, tests what the job actually requires, and produces a signal you can act on in under 5 minutes per submission.
The problem with most take-homes
Before the template, a diagnosis. Most bad take-homes fail in one of three ways:
Scope creep. The brief grew over time. What started as "build a small CRUD API" now includes authentication, pagination, rate limiting, a test suite, a Docker setup, and a README explaining your architectural choices. You've described a three-day project and called it a four-hour assessment. Good candidates with competing offers self-select out. Over-achievers burn a weekend and resent you for it.
Wrong signal. The assignment tests what's easy to grade, not what predicts performance. "Write a linked list implementation" tests whether the candidate studied linked lists. "Add a new feature to this messy legacy codebase" tests everything else: reading unfamiliar code, making tradeoffs under time pressure, communicating decisions in a PR description. One is a textbook exercise; one is a job preview.
No rubric. Without a written rubric, every reviewer grades differently. The engineer who cares about test coverage gives a different verdict than the engineer who cares about naming. The candidate who did Sunday gets scored by the engineer who had a rough Monday. Inconsistency that compounds into biased hiring.
A brief template worth stealing
Here's the structure we recommend. Fill in the blanks for your stack and role.
Assignment: [Role title] — Take-home
Time budget: Please spend no more than 3–4 hours. We mean this. An unfinished solution submitted in 4 hours tells us more than a polished solution submitted in 10.
What we're building: [One sentence. E.g. "A small REST API for managing a reading list, with search and per-user bookmarks."]
Requirements:
- [Requirement 1 — must be testable and unambiguous]
- [Requirement 2]
- [Requirement 3]
- (Optional stretch) [Nice-to-have. Not scored — just there for candidates who finish early]
Tech constraints: Use [language/framework]. Beyond that, use whatever libraries you'd reach for on the job.
How to submit: Push to a public GitHub repo (or share a zip) and reply to this email with the link.
How we grade: We check requirements coverage, whether the app runs on a clean machine, code quality, and test coverage. We also run automated analysis for AI-generated code — not to penalise it outright, but to factor it into our interview questions.
Three things to notice in that template:
- The time cap is explicit and you mean it. Candidates who've been burned by "it should only take a few hours" briefs will test you by submitting at the 4-hour mark. If their solution is incomplete but shows good judgment in what they prioritised, that's a pass.
- Requirements are numbered, not prose. This lets reviewers check them off. It also lets automated tools map each requirement to the code that implements it.
- You tell candidates about the AI detection. Transparency increases trust and changes behaviour. A candidate who knows you're checking will use AI differently — as a tool for boilerplate rather than as a ghostwriter.
What to actually test by role
Not all roles should get the same assignment. Here's what signal each variation produces:
| Role | Best assignment type | What it predicts |
|---|---|---|
| Backend (API) | Build a CRUD API with one tricky edge case | Data modelling, error handling, API design intuition |
| Frontend | Add a feature to an existing React codebase | Reading unfamiliar code, component design, accessibility awareness |
| Full-stack | Small end-to-end feature in a provided scaffold | Prioritisation, integration thinking, making tradeoffs under time |
| Senior / Staff | Review and improve a deliberately messy codebase | Architectural judgment, communication, knowing what not to fix |
| DevOps / Platform | Dockerise + add basic CI to a provided app | Practical tooling, documentation, security hygiene |
The senior assignment is worth expanding on. Instead of asking a senior engineer to build something from scratch — which plays to their strengths and produces a portfolio piece — give them 150 lines of spaghetti and ask: "What are the three most important things to fix here, and fix one of them." The debrief conversation about the other two tells you more than any greenfield implementation.
The scope formula
A useful heuristic: a take-home should be completable by a mid-level engineer in your target role in 3 hours, including reading time.
To calibrate:
- Have an internal engineer time themselves building the solution from scratch.
- Double it (candidates don't know your stack conventions).
- If the result is over 4 hours, cut a requirement.
Most teams skip step 3. Don't. Every requirement you add beyond the core signal is time cost for the candidate and review cost for you.
What the rubric should score
Five dimensions, same weights we publish in our take-home review guide:
| Dimension | Weight | Pass threshold |
|---|---|---|
| Requirements met | 35% | All required items implemented and functional |
| Code quality | 20% | Readable, appropriately structured for the scope |
| Tests | 15% | Core paths covered; not just smoke tests |
| Security | 15% | No hardcoded secrets, no obvious injection vectors |
| AI-written likelihood | 15% | < 80 (below that is grey-zone; above is a debrief topic) |
Hard stops — regardless of total score, these are automatic no-hires:
- App does not run on a clean checkout
- Any security score below 40 (injection, exposed credentials)
- AI likelihood above 80 with no disclosure
The key move is writing the rubric before you see any submissions. Once you've read a strong solution, your standards shift to match it. Write the rubric, lock it, then open the submissions.
Frequently asked questions
How much context should I give candidates about the company's actual stack?
As much as is realistic. If the role will use a Postgres-backed Node API, tell them that. You're not testing whether they can guess your stack. You're testing whether they can build within it. Vague briefs produce generic solutions.
Should take-homes be paid?
If the assignment takes longer than 2–4 hours, yes. If it's scoped correctly (under 4 hours), it's comparable to a technical phone screen in time cost — which you also don't pay for. The stronger argument for a stipend is about signal quality: paid candidates complete at higher rates and submit more considered solutions. If your budget allows it, even $50 improves both completion and diversity outcomes.
What do I do with candidates who submit early (in under an hour)?
Look at what they built. Some candidates produce exactly enough to meet the requirements and nothing more — that's fine, and often a good sign of prioritisation instinct. Others submit early because they used AI heavily. The automated detection will flag the latter. Don't penalise fast submissions as a rule.
How do I handle candidates who ask clarifying questions?
Answer once, then treat silence as consent to interpret. Real jobs involve ambiguous requirements. A candidate who emails to ask whether they should support soft deletes is showing initiative — but you're not required to answer every sub-question. Reply once with your clearest intent, and note in the debrief whether they handled the ambiguity well.
We've been using the same assignment for 3 years. Should we change it?
Yes, but not for the reason you think. The problem isn't that candidates are sharing the solution (though they are — search GitHub for your company name and the assignment title). The problem is that after three years you no longer know whether the assignment still tests what the job actually requires. Reassess the assignment every 6–12 months against the same question: does completing this assignment well predict doing the job well?
Want to skip writing the rubric manually? CodeVerdict grades submissions against your requirements automatically — maps every requirement to code, flags security issues, and generates interview questions in 60 seconds.