Why take-homes are back
Take-home projects are returning because interviewers have lost confidence in isolated coding puzzles as a complete signal. AI tools can solve many contained tasks. Candidates can practise common algorithm patterns until the interview becomes a memory test. A take-home, followed by a serious review, can show product judgement, code organisation, test habits and ownership.
That does not make every take-home fair. Some are unpaid work. Some have vague scope. Some ask for production-grade polish while claiming to take "two hours". Candidates on Reddit and Hacker News have been blunt about long processes and take-homes that feel like Jira tickets. The useful stance is not "always refuse" or "always comply". It is to qualify the assignment, time-box it, document decisions and prepare for the follow-up.
The market research points in this direction. Hacker News interviewers discuss modifying a take-home in a follow-up, data engineering candidates report friction around practical assignments, and The Pragmatic Engineer has written about the reality of tech interviews. At the same time, AI interview policy is splitting, with examples such as Meta allowing AI in some interviews and CodeSignal launching AI-assisted assessments.
Qualify the assignment before you start
Ask four questions before accepting a take-home:
- What is the expected time box?
- What criteria will be used to review it?
- Will there be a live follow-up where I explain and modify the work?
- What is the policy on AI tools, libraries and boilerplate?
This is a reasonable email:
Thanks for sending the exercise. Before I start, could you confirm the expected time box, review criteria and AI/tooling policy? I am happy to complete a representative exercise, but I want to keep the scope aligned with what the team intends to assess.
If the company cannot answer, treat that as data. It may still be worth doing the assignment, especially for a role you want, but you should make a conscious decision.
For senior candidates, I would be more willing to negotiate. For junior candidates, I would usually complete a fair assignment because practical proof can offset a thin CV. For everyone, I would avoid multi-day unpaid builds unless the role is unusually attractive or the company pays for the exercise.
Build for review, not for fantasy production
A good take-home is not a startup MVP. It is a reviewable sample of your engineering judgement. You should optimise for clarity, correctness and explainable tradeoffs.
Use this structure:
- A short README with setup, assumptions and tradeoffs.
- A small domain model with clear boundaries.
- Tests around the important behaviour.
- Simple error handling at real boundaries.
- One or two deliberate extension points.
- No speculative infrastructure.
For a frontend assignment, that might mean a clean state model, accessible forms, loading and error states, and a few focused tests. For a backend assignment, it might mean validated inputs, persistence decisions, idempotency where relevant and integration tests. For a data assignment, it might mean data quality checks, lineage notes and a reproducible pipeline.
Here is a small README structure that works:
# Take-home submission
## Setup
pnpm install
pnpm test
pnpm dev
## Assumptions
- The API returns stable IDs.
- Pagination is cursor-based.
- The exercise is scoped to authenticated users but auth is stubbed.
## Tradeoffs
- I used in-memory storage to keep the exercise runnable without external services.
- I added tests around validation and state transitions rather than snapshot-heavy UI tests.
- I did not add background jobs because the requested workflow is synchronous.
## With more time
- Add contract tests for the external API.
- Add persistence migrations.
- Add observability around failed imports.
That format helps the reviewer see judgement quickly.
Use AI honestly, if allowed
AI is now part of the take-home conversation. Some companies allow it because it mirrors real work. Others ban it because they want your baseline skill. The worst option is hidden use that you cannot defend.
If AI is allowed, use it as a collaborator, not a ghostwriter. Good use:
- Generate candidate test cases, then choose and edit them.
- Ask for edge cases against your design.
- Use it to explain unfamiliar library APIs, then verify against docs.
- Use it for boilerplate you understand.
- Ask it to review your README for missing setup steps.
Bad use:
- Paste the prompt and submit the generated project unchanged.
- Add libraries you cannot explain.
- Ship code you did not run.
- Let AI invent APIs without checking docs.
Put a short disclosure in the README when appropriate:
## Tooling note
I used an AI assistant to brainstorm test cases and review the README for clarity.
All implementation decisions, code edits and verification were done by me.
That statement is not a magic shield. It only helps if you can explain the code. Built In's discussion of the AI job-interview cheating debate captures why employers are sensitive here: the issue is not tool use itself, but whether the submission signals real ability.
Prepare for the change-request follow-up
The follow-up is where many take-homes become useful. Interviewers may ask you to add a field, change a business rule, debug a failing test, improve performance or critique your own design.
Before the follow-up, prepare:
- A two-minute architecture walkthrough.
- The top three tradeoffs you made.
- One thing you would change with more time.
- The highest-risk edge case.
- Where you would add monitoring or logging in production.
Then practise modifying your own code quickly. If you cannot change it, you probably overbuilt it.
A good follow-up answer sounds like:
I kept the importer synchronous because the sample input is small and it made the behaviour easier to review. If this moved to production, I would put imports onto a queue, make the operation idempotent by source file ID and expose import status to the UI.
That answer shows scope control and production awareness.
Know when to decline
Declining a take-home is reasonable when:
- The work clearly resembles a real unpaid company task.
- The time expectation is more than a working day without compensation.
- The company refuses to share review criteria.
- The process already has many rounds and the assignment is additive.
- The role is not attractive enough to justify the cost.
Use a polite decline:
I appreciate the opportunity, but I am going to withdraw from the process at this point. The assignment appears larger than I can reasonably take on unpaid alongside other commitments. I would be open to a shorter live exercise or a paid project if that is available.
Candidates report success with firm but professional boundaries, especially at senior levels. There is no guarantee. In a tight market, some companies will simply move on. The point is to make a deliberate tradeoff.
Continue your prep
Take-homes are easier when your core role prep is current: