Every other stage of a hiring process is fixed. The screen is thirty minutes because their calendar says thirty minutes. The panel is four people because four people were free. You cannot move any of it.
The take-home is different, and the difference is structural rather than a matter of goodwill. It is the only stage where you supply the resource being spent. Their cost is one review. Your cost is your weekend. Any time both sides are spending different currencies, there is a negotiation, whether or not anyone opens it.
Almost nobody opens it. I did not for years, because the brief arrives looking like a fact.
What is actually negotiable
Four things, and none of them make you look difficult.
1. The scope, against the stated time. Briefs routinely say "about four hours" and describe eight. This is usually not a trick, it is a brief written by someone who already knows the codebase and forgot how long the setup takes. Asking "if this runs long, would you rather I ship the smaller thing finished, or the larger thing partial" is a normal engineering question. The answer tells you a lot about the team, and it is the same question you would ask in week one of the job.
2. The deadline. The date on the email is almost always the date the sender typed, not a constraint from anywhere. Two extra days is a routine ask and I have never seen it refused. What gets refused is silence followed by lateness.
3. The format. If the brief asks for a repo and you would rather send a repo plus a fifteen minute walkthrough, offer it. If it asks for a deployed app and deploying is two hours of the four, ask whether local is acceptable. You are proposing a cheaper path to the same evidence.
4. Whether it happens at all. If you have public work that already demonstrates the thing being tested, say so and offer it as a substitute. The worst outcome is that they say no, and you have still shown them the work.
The one thing that is not negotiable
The scoring is not a mystery to be reverse engineered, but it is also not yours to change. Nearly every rubric I have seen or been given weights the same four things: does it run from a clean checkout, is the core case correct, is the code readable by someone who did not write it, and did you say what you left out. The fourth one is free and it is the one people skip.
Write the README that says what you did not do. "No auth, out of scope. No pagination, would add it at N rows. Tests cover the parser, not the CLI, because the parser is where the risk is." That paragraph costs ten minutes and it converts every gap from a thing they found into a thing you decided. Those are not the same finding.
How to open it without sounding like you are dodging
One message, sent the day you receive the brief, not the day before it is due:
Thanks, this looks like a good problem. Two questions before I start. It reads like more than the four hours suggested, so if it runs long, would you rather have the smaller version finished or the larger version partial? And I have a conference on Thursday, would Monday work instead of Friday?
That is it. You have asked one engineering question and one logistics question. Nobody has ever read that and thought less of the sender.
The uncomfortable part
This only works if you actually do the task well afterwards. The negotiation buys you a fair brief. It does not buy you a pass, and asking for two more days and then sending something rushed is worse than sending the rushed thing on time.
The question
I have not found anyone who tracks this properly, so I will ask rather than assert. When you have pushed back on a take-home, what happened? I am specifically interested in the cases where it went badly, because I have only ever heard the success stories and that cannot be the whole distribution.
I build AI Applyd. It applies to jobs for you across the twelve ATS platforms we cover, and counts an application as sent only when the employer's own system confirms it.
Top comments (0)