The take-home says four hours and is clearly twelve, do you do it, timebox it, or decline?

Yes, I have declined and been hired by the same companies. It is far less career-ending than it feels.

How to do it without it reading as a refusal to be assessed - offer an alternative rather than saying no:

Point at existing work. A repository, something you have shipped, an open source contribution. Many places accept this happily and never mention the exercise again.

Offer a live session instead. An hour pairing on a problem of their choosing. This is often better for you - they see how you think and ask questions, which a submitted zip file cannot show.

Ask for a smaller version. I am glad to do this and I can commit about two hours; is there a reduced version, or shall I do the core and we discuss the rest.

That last one succeeds surprisingly often, because the person on the other end frequently knows the exercise is oversized.

What to avoid: declining without offering anything, and complaining about the industry in the email. Both are read as difficult rather than as principled.

And if they insist on the full thing with no flexibility and no conversation first, that is information. You are early in a process with a company that has already decided your time is cheaper than theirs.

Timebox it to the stated time, and then write down what you did not do. That last part is the whole technique and it changes the outcome.

What I submit:

Working code for the core requirement, done properly rather than broadly. Better to have one path that is clean, tested and thought about than five features half done.

A readme with a section headed what I would do with more time. List the edge cases you spotted and did not handle, the tests you would add, the thing you would refactor, the trade-off you made and why.

That section does more work than the code. It demonstrates that you saw the same things a longer submission would have covered, that you can prioritise under a constraint, and that you can communicate about your own work - which is most of what a reviewer is actually assessing.

Say how long you spent, honestly, in one line at the top.

What this also does is protect you from the version where you spend twelve hours and it is still not enough, because there is always more. A take-home has no natural end and the person setting it often has not done it themselves recently.

And a reviewer who penalises an honest four-hour submission against a stated four-hour brief has told you something useful about the place.

The filter I use, because the real problem is volume rather than any single one: where in the process does it arrive?

Before any human conversation, decline or ask to move it later. A take-home as a screening filter is asking for a weekend from strangers, and it is the version most likely to be a black hole. It also tells you the process is designed around their convenience.

After a first conversation, before the final stage: this is the normal and defensible position and I do these.

As the final stage, with the team, discussed live afterwards: the best version. The discussion is where the value is for both sides, and it means the code will actually be read by someone who talks to you about it.

So the questions worth asking before starting: how many candidates are at this stage, will I get feedback either way, and will we discuss it with the team afterwards. Reasonable companies answer all three.

And be willing to spend the budget unevenly. Two take-homes at real effort for jobs you want beats five at half effort. A submission that is obviously going through the motions is worse than not applying, because it costs you the weekend anyway.