Take-Home Assignments: When to Do Them and When to Walk

Sixteen hours of work. No offer. No pay. That invoice never gets sent, but every engineer who has been through a long loop this year has one drafted in their head.

Every time we bring this up on LinkedIn the replies split cleanly in two. Half are engineers describing the weekend they lost to a "four-hour" project. The other half are hiring managers saying take-homes are the fairest test they have. Both are right, which is why the answer to "should I do this one?" is not yes or no. It's a set of conditions.

Here they are, up front:

Do the take-home when it's scoped to four hours or less, it comes after a real conversation with the hiring manager, it replaces a round instead of adding one, and you've been told in writing when you'll hear back.

Walk when it's the first gate before any human has talked to you, the honest estimate is a working day or more, the "assignment" is a feature the company plausibly needs shipped, or the recruiter won't answer basic questions about the rest of the loop.

Everything else, the middle, is negotiable. And most of it is more negotiable than people assume. The rest of this post is how.

Why take-homes got worse in 2026

They didn't go away. They got heavier.

Karat's 2026 survey of 400 engineering leaders puts take-home projects in 45% of US engineering loops, behind live technical interviews at 79% and automated code tests at 63%. That's the same rough share as a few years ago. What changed is what the take-home is being asked to prove.

In the same survey, 71% of leaders say AI is making technical skill harder to assess, and they single out take-home projects and automated tests as the formats whose signal is degrading fastest. The logic is simple. If an average candidate with an assistant can produce in four hours what an exceptional candidate produced alone in 2023, the take-home stops separating anyone from anyone. Meanwhile 62% of organizations still prohibit AI in interviews, and those same leaders estimate that more than half of candidates use it anyway.

Companies have responded in three ways, and only one of them is good for you:

→ Inflate the scope. If a four-hour project no longer discriminates, make it a twelve-hour one with a deployment step, observability, and a design doc. This is where the "weekend tax" comes from, and it's the version you should push back on hardest.

→ Add a defense round. Keep the take-home but follow it with a 45-minute session where you walk through your code and get asked why every choice is correct. This is the sane response, and it means the take-home is now an entry ticket to a live round, not the test itself.

→ Drop it for live pairing. Stripe, Ramp, and a growing set of AI-native companies test in your editor with your tools, then interrogate the result. No homework at all.

So the question for any given take-home is which of those three you've been handed. A modest project with a defense round attached is a reasonable bar. A ballooning project with no human on the other side is unpaid work with a lottery ticket stapled to it.

The hours-cap rule

Set the cap before you open the brief, not after you've sunk a Saturday into it.

Default cap: two hours of focused work. Hard ceiling: four. Two hours is enough to show how you structure a problem, write tests, and handle the edge case they planted. Four is the outer limit of what a company can reasonably ask for free from someone it has not decided to hire. Anything beyond that is the company spending your time to reduce its own decision risk, and it should either pay for the privilege or shrink the ask.

The rule has three parts, and skipping the third is where most people go wrong:

1. Estimate honestly before you start. Read the brief, list the pieces, and write a number down. If the company's stated estimate is "3 to 4 hours" and your honest read is ten, believe your read. Company estimates are written by the person who designed the exercise and already knows the answer.

2. Stop at the cap. Ship what's working, with a README that says what you'd do next and roughly how long it would take. Partial and clean beats complete and rushed, because the follow-up conversation is about your judgment, not your stamina.

3. Say so in writing. This is the step that turns a time-box from a private compromise into a signal. One line in the submission email:

Nobody reasonable reads that and thinks less of you. Plenty of hiring managers read it and think more, because it's exactly the note they'd want from a senior engineer on a real ticket. And if a company penalizes you for scoping to a stated budget, you've learned what working there is like for the price of three hours instead of three years.

When to walk

Some take-homes aren't worth doing at any length. The tells are usually visible in the first email.

Two more that are less obvious:

It's a take-home on top of a full loop, not instead of a round. Calibrd's 2026 interview report puts the average senior software engineer loop at six evaluative rounds. If a company already runs six and adds a project on top, that's round seven, and it belongs on the same list as the behavioral rounds that keep multiplying. A take-home that replaces the algorithms round is a trade. A take-home added to the algorithms round is a tax.

You're one of many, and they said so. "We're sending this to everyone who passed the screen" is a company telling you the take-home has a low conversion rate and it knows it. Gem's 2025 benchmarks put hiring teams at roughly 20 interviews per hire, up 42% since 2021. Multiply your hours by that funnel and the expected value of an unscoped project gets ugly fast.

Walking doesn't have to be dramatic. "I'm going to pass on the project at this stage, but I'd be glad to do a live session or a shorter exercise if that's an option" closes the door politely and, surprisingly often, reopens it on better terms.

The three scripts: shorter, live, or paid

Most engineers treat the take-home as a fixed condition of the loop. It's an opening offer. Three counter-offers, in the order to try them.

1. Ask for the shorter version.

"Thanks for sending this over. Reading the brief, I'd estimate this at eight to ten hours done properly. I'm glad to spend up to four. Would you rather I scope it to the core flow with a written plan for the rest, or is there a smaller exercise you use for candidates with limited time?"

Many companies have a smaller exercise and hand out the big one by default. You lose nothing by asking, and the answer tells you how the team treats scoping in general.

2. Ask for the live equivalent.

"I'd prefer to do this as a pairing session if that works on your side. It gives you a better read on how I actually work, and it keeps the loop to a fixed time for both of us. Sixty to ninety minutes, my editor and tools, you pick the problem."

This is the strongest counter in 2026, because it's the direction the market is already moving. A team that has thought about AI and assessment at all will say yes. A team that says no is telling you it hasn't.

3. Ask to be paid.

"Happy to take this on. Given the scope, I'd treat it as a short paid engagement, say a day at my normal contracting rate, with the code staying yours either way. That's how I'd approach any project of this size, and it keeps the incentives clean on both sides."

Paid take-homes are more common than the internet suggests, particularly at companies that ask for a day or more. The cost is small next to a recruiter's time, and it filters for teams that respect the asymmetry. Frame it as a business arrangement, not a grievance. The companies worth working for hear it that way.

You won't get all three yeses. You'll get one more often than you'd think, and the no's are useful too: they sort the companies that see you as a colleague-in-waiting from the ones that see you as a queue.

If you do it, do it like a senior engineer

You've scoped it, you've set a cap, you're doing it. A few things separate submissions that lead to offers from submissions that lead to silence.

Write the README first. Assumptions, how to run it, what's tested, what's deliberately out of scope, and what you'd do with more time. Reviewers read the README before the code and often decide there.

Tests over features. A smaller feature set with real tests reads as senior. A bigger one with none reads as a rush job, no matter how good the code is.

Show the trade-offs, not just the choices. A short "why I picked X over Y" section is the most-read paragraph in any submission. It's also the thing an assistant won't write convincingly for you.

Be ready to defend every line. Assume the follow-up round is a code walkthrough and the interviewer has read it closely. If you used AI to generate parts, know exactly what it produced and why it's correct. Karat's leaders estimate more than half of candidates use AI regardless of policy; the ones who get caught aren't the ones who used it, they're the ones who can't explain their own code.

Ask for the decision date when you submit. The iHire 2026 candidate experience report found 53% of job seekers were ghosted by an employer in the past year, up from 38% two years earlier, and about one in eleven of those went silent specifically after the candidate completed an assessment. A written "you'll hear from us by Friday" is your only leverage against joining that group. Get it before you hit send.

The bigger point

A take-home isn't a test you pass or fail. It's the first negotiation of the working relationship, and the company opened with an ask. How you respond, capping it, scoping it, asking for the live version, asking for pay, is data for them and data for you. Teams that hire well recognize a candidate who manages their own time. Teams that don't will keep sending twelve-hour briefs to a hundred people and hiring one.

The upstream fix is to spend less of your search on loops that start with a weekend of homework and more on the ones that start with a conversation. We built ApplyIn to surface postings in the first hours they're live, when the pile is small and a real human is still the one reading applications. Fewer queues, fewer lottery tickets, more loops where a take-home is a trade instead of a tax.

Find fresh engineering postings

FAQ

How many hours should a take-home assignment take?

Cap it at two hours of focused work by default and four at the absolute most. Estimate honestly from the brief before starting, stop at your cap, and say in the submission email how long you spent and what you'd do with more time. A company that penalizes a clearly stated time-box has told you something useful about how it treats scoping.

Is it okay to refuse a take-home assignment?

Yes, and it's often the right move. Decline when it's the first gate before any conversation, when the brief looks like real production work, when the honest estimate is a full day or more, or when the recruiter can't tell you what the rest of the loop looks like. Offer a live pairing session or a shorter exercise as the alternative so the door stays open.

Should companies pay for take-home assignments?

For anything past four hours, yes, and a growing number do. Ask for it as a short paid engagement at your normal contracting rate with the code staying theirs. Frame it as a business arrangement, not a complaint. The cost is trivial next to a recruiter's time, and the companies that say yes are disproportionately the ones worth joining.

Can I use AI tools on a take-home assignment?

Check the policy first; Karat's 2026 survey found 62% of organizations still prohibit AI in technical interviews, while 38% of US teams now allow it. If it's allowed, use it and be ready to explain every generated line in the follow-up round, because that walkthrough is the real test. If it's prohibited, don't, and treat the rule as a reason to prefer companies that test live with tools instead.

What if I never hear back after submitting a take-home?

It happens: iHire's 2026 survey found 53% of job seekers were ghosted in the past year, and roughly 9% of those went silent right after an assessment. Prevent it by getting a written decision date when you submit. If the date passes, send one short follow-up, then move on. Silence after free work is a decision, and it's one you can make first next time by asking for the process up front.

---