How to Approach a Take-Home Coding Assignment

Take-home assignments are where a lot of strong candidates quietly lose offers — not because they can't code, but because they misjudge what's being evaluated. They over-build, they under-document, or they spend twelve hours on something that was meant to take three and still get rejected.

The reviewer is not looking for the most feature-complete submission. They're looking for evidence you'd be good to work with on a codebase they maintain.

Before you start: decide whether to do it

Not every take-home deserves your evenings. Reasonable ones state a time limit, describe what's being evaluated, arrive after you've spoken to a human, and don't resemble work they'd otherwise pay for.

Push back, politely, when:

• There's no time limit — ask for one. "Roughly how long should this take?" is a fair question and the answer is informative.
• It's clearly production work for their actual product. That's free labour and it's worth declining.
• It's the first step, before any conversation. Asking for hours before you know anything about the role is a bad trade — ask for a call first.
• It would take more than about four hours unpaid. Asking "is there a shorter version, or could we pair instead?" is entirely reasonable and often accepted.

Many companies offer a live pairing session as an alternative if you ask. If you interview better in conversation than in isolation, ask.

Declining a genuinely unreasonable assignment rarely costs you a job worth having.

Scope it before you write anything

The most expensive mistake is starting to code immediately.

• Read the brief twice and list the explicit requirements. Build exactly those.
• Note what they said they're evaluating. If the brief says "we care about how you structure code and handle errors," then structure and error handling get your time, and styling gets none.
• Ask clarifying questions. This is not cheating — it's the behaviour they want at work. A short, specific email ("should the API handle concurrent updates to the same record, or is that out of scope?") is itself a positive signal.
• Set a hard time budget and decide in advance what you'll cut. Deciding under time pressure at 11pm produces worse choices.

Build the boring things well

Reviewers form their impression from craft, not cleverness:

• Make it run first time. A clear setup command, tested on a clean machine. Nothing sours a review faster than a submission that won't start.
• Structure it sensibly. Recognisable layout, obvious file names, no everything-in-one-file and no fifteen layers of abstraction for a small exercise.
• Name things well. The cheapest quality signal available.
• Handle errors and edge cases. Empty input, missing fields, failing network calls. This is where most submissions are thin and where you can easily stand out.
• Write some tests. Not exhaustive coverage — tests for the things that actually matter, which demonstrates judgment about risk.
• Commit in logical steps with clear messages. Reviewers often read the history, and one giant commit tells them nothing about how you work.

Do not over-build

Gold-plating is the most common failure, and it reads as poor judgment rather than enthusiasm. If the brief asks for a small API, do not add authentication, a Docker Compose stack, a frontend, a caching layer, and CI.

You'll be assessed on whether you did what was asked, at good quality, within the stated time. Someone who adds twenty hours of unrequested infrastructure has demonstrated they can't scope work — which is a real concern in a colleague.

The correct outlet for extra ideas is the README.

The README is where you win

Most candidates submit code with a two-line README. This is the single biggest opportunity in the whole exercise, because it's where you get to explain your thinking — which is what they're actually trying to evaluate.

Include:

• How to run it. Exact commands, top of the file.
• What you built and which requirements it covers.
• Your key decisions and why — this library over that one, this structure, this data model. Two or three sentences each.
• Assumptions you made where the brief was ambiguous.
• What you deliberately left out, and why. "I skipped auth because the brief scoped it out" shows you read carefully.
• What you'd do with more time. Name the real weaknesses. Reviewers respect a candidate who identifies the same gaps they spotted; it demonstrates you have the standards even when the clock didn't allow them.
• How long it took, honestly.

That section turns a submission from something they must evaluate into something you've already explained. It's also indistinguishable from good professional practice, which is the point.

Using AI tools

Assume you're allowed unless told otherwise, and assume you'll be asked to explain everything you submit.

The practical rule: never submit a line you couldn't defend or modify on a call. Most companies now debrief take-homes live, and the failure mode they're screening for is exactly the candidate who can't explain their own architecture. Use the tools the way you would at work — then read, understand, and take ownership of the result.

If the brief asks you not to use them, respect that and say what you did.

Prepare for the debrief

Most processes follow the submission with a conversation. Prepare for it as seriously as the code:

• Be able to justify every significant decision.
• Know where it's weak and say so before they ask.
• Be ready to change a requirement live — "how would you handle a hundred times the data?" is a near-certain question.
• Be ready to extend it in a pairing session.

Candidates who are honest about limitations consistently outperform those who defend everything.

Small things that matter

• Submit on time, or say early if you need longer. Silence past a deadline is its own signal.
• Don't publish it publicly if the company asked you not to — and consider not doing so anyway, since future candidates will find it.
• Include the time you spent and don't inflate or deflate it.
• Ask for feedback if you're rejected. Many companies give it, and it's the most useful information you'll get all search.

The takeaway

A take-home tests judgment more than skill. Scope it to exactly what was asked, build the unglamorous parts well, resist adding anything unrequested, and put your real thinking in the README — decisions, assumptions, known weaknesses. Be able to defend every line in the debrief. And treat an unreasonable assignment as information about the company, not an obstacle you're obliged to clear.

Ready for your next interview? Create a free profile on JobsList.dev and apply directly to companies.