Take-home test assignment: when to do it and when to decline

After the screening call you get an email: "Here is the test assignment, you have three days." Inside is a two-page description that looks like a full weekend of work. Meanwhile you have two other processes, a day job, and no certainty that anyone will even open your solution.

Take-homes come up in interviews both before and after you do them. The Sobes question bank has a screening question, "Which do you prefer: the test assignment right away, or an online meeting first and then the assignment?", and questions from the defense: "Why did you do the test assignment this way? Why is it structured like this?" and "What methods did you use to solve the assignment? Did you use AI?". So the assignment almost always has two parts: submit the code, then explain it.

When to take it

A take-home makes sense when three conditions hold:

• The scope is reasonable: up to 4 hours for a regular position, up to 8 for a complex or highly paid one.
• Someone has already talked to you. There was at least a screening call, you know the salary range and the format, and the company has spent time on you.
• You know what happens next: who reviews it, when they reply, whether there's a review call.

One more argument in favor: a take-home is easier than live coding if you write poorly while being watched. Here you can think, rewrite, and submit something you're not embarrassed by.

When to decline

• The assignment arrived as an auto-reply to your application, before any conversation. It went to everyone, and the chance that each solution gets read is small.
• The scope is clearly over 8 hours and unpaid.
• The task looks like real production work: an integration with their specific API, a landing page for their product, an analysis of their actual data with a request for recommendations. A practice task is different in that the company has no use for the result.
• The deadline is rigid and not negotiable, and no feedback is promised.

Declining doesn't have to end the process. Offer an alternative:

Thanks, I've looked at the assignment. By my estimate it's about 15 hours, and I can't set aside that much right now. I can show a similar project on GitHub and walk through it on a call, or do a reduced version: API and tests only, no frontend. Which option works for you?

The message has an estimate and two ways forward, and no complaints. Some companies agree, especially when they're interested in the candidate. If they don't, you've saved a weekend.

What to clarify before you start

Five questions worth sending by email right away:

1. How long the team expects the assignment to take.
2. What the review criteria are: it works, it's tested, architecture, presentation.
3. Whether there are limits on the stack and libraries.
4. Whether AI assistants are allowed.
5. When and in what form you'll get feedback.

Nobody treats questions before the start as a weakness. This is how any task is handled at work, and the reviewer notices. And if your email goes unanswered for three days, that's information about the company too.

Name the deadline yourself, with a margin: "I'll send it by end of day Monday." If you're running several processes, put the deadline into the application tracker so the take-home doesn't collide with another interview. How to lay out parallel processes across a week is covered in the article on managing multiple interview processes.

How to split the time

For a four-hour assignment the plan looks roughly like this:

• 20 to 30 minutes: read the task twice, write down requirements and assumptions, decide what you definitely won't do.
• 2 to 2.5 hours: the main scenario end to end, from input to result. Working first, pretty second.
• 40 minutes: tests for the core logic and edge cases.
• 30 minutes: README, a run from a clean clone, a read-through of the diff.

The main mistake here is spending three hours on a perfect architecture and submitting without tests or instructions. The reviewer will open the repository for ten to fifteen minutes. In that time they need to run the project and understand your decisions.

What you must submit

• A README: what's done, how to run it, how to run the tests.
• A one-command start. docker compose up or make run, with no "install Postgres 14 and edit the config."
• Tests. Eight is fine, as long as they cover what can really break.
• A list of assumptions: "The task doesn't say what to do with duplicates. I treat them as an error and return 409."
• A "What I'd do next" section: three to five items you deliberately left out within the time limit.
• A clean commit history. Not one commit named "done" and not forty named "fix."

The last two get read most carefully. They show that your simplifications were decisions and not oversights, and the defense conversation usually starts from them.

About AI

If AI isn't prohibited, there's no reason to hide it: "did you use AI" is asked directly at the defense. What looks bad is code the author can't explain.

Yes, I did. I generated the project skeleton and some of the tests. I wrote the calculation logic myself because it had non-obvious rounding cases. I read all the generated code and rewrote two places, and I can show which ones.

The answer shows where the line is and that you own every line. The rule is simple: the repository shouldn't contain anything you can't talk about for five minutes.

How to defend a take-home on a call

The defense works like a code review where you are the author. Reread your code before the call, because details fade within a week. Prepare answers to four questions:

• Why this structure and these libraries.
• What happens at a hundred times the load.
• What you'd redo with one more day.
• Where the weak spots are.

Answer the last one yourself, before they find them:

The weakest spot here is that I keep state in memory. For a take-home it made startup simpler, but with two service instances it breaks. In a real project I'd move it to Redis, and that's on my "what's next" list.

If the reviewer finds a bug, don't get defensive. Agree, say how you'd fix it and which test should have caught it. Often you're then asked to add something right on the call, and the techniques from the article on thinking aloud in live coding help here. Reading someone else's code and phrasing comments has its own article: the code review interview.

What to do before you send it

Clone the repository into an empty folder and do exactly what the README says. If it doesn't start on the first try, it won't start for the reviewer either. Then open the full diff and read it as if it were someone else's: commented-out code, debug output, forgotten TODOs. Finally, say a two-minute summary of the solution out loud: what you did, what you assumed, what comes next. The defense will start with it.