Why offline coding exists

I'll be honest. The first take-home I shipped for a client, I spent the whole weekend on a four-hour task. Got the offer. Never did that again, and I now tell every developer I mentor the same thing: the clock the client wrote down is the clock you should respect.

Some clients prefer tasks that look like a real ticket instead of a live call. You get a brief, you go away, you come back with something. The length varies. Sometimes 2 to 4 hours, sometimes a full day, often a weekend window. That weekend window does not mean code for two days straight. It means they want to see what you do when you have room to think.

What the client is actually watching is how you structure code and how you handle the messy parts end to end. It is less stressful than live coding, with a quieter trap: nobody is going to stop you from over-building. The discipline has to come from you.

What clients expect

I once received a take-home for a logistics dashboard: a paginated table of shipments, a filter, a detail drawer. Six hours suggested. The candidate who got hired did not finish the filter. He shipped a clean table, a working drawer, a README that said "filter not wired, would use a server query param, see line 42 for the stub". The other three candidates finished everything and submitted spaghetti. He won.

So what is the client actually reading? Not flashy UI. They want to see that you can deliver working features inside the window, organize code so someone else can open the folder without sighing, handle the real states (loading, error, empty), and document the approach in a short README.

Even an incomplete solution wins if the codebase is tidy and the notes are honest. That combination tells the client you would be reliable on a real ticket.

How to approach these tasks

Here is the actual sequence I run when a take-home lands in my inbox. I read the brief twice, then I write back the same day with one or two questions, even small ones (it shows I started thinking already, and it buys me a real answer before I burn hours on a guess). Then I open a fresh repo, push an empty commit, and write the README before any code. The README is just headings: Approach, Trade-offs, What I skipped, What I would do with more time. Those headings become the brief I am writing toward.

Only then do I open the editor. Basics first, then the boring states (loading, error, empty), then one polish pass. If the clock runs out mid-feature, I stop, write a sentence in the README about where I stopped, and submit.

That sequence is not clever. It just keeps me from over-building, which is the only thing that has ever cost me a take-home.

Common pitfalls

Most candidates I have reviewed fail for reasons that have nothing to do with coding. They submit a zip with no README. They reach for Redux, a state machine, and a custom router for a screen that has one button. They skip the empty state because "the data is always there in the mock". They hand in a Sunday-night submission for a Friday brief and call it polish.

Now, you might think more libraries equals more senior. It reads as the opposite. A reviewer opening your package.json and seeing twelve dependencies for a CRUD table thinks one thing: this person will install a npm package every time we ask for a feature. The senior move is the boring stack used confidently, with a short note explaining why.

Wrapping it up

When you submit, include the code (organized, no dead files) and a short README that covers your approach, the key trade-offs you made, and what you would do with another day. That is the whole package.

Next lesson we look at the live coding interview, which is the same skill under a stopwatch with someone watching. If you want to pressure-test what you just read, grab a real take-home brief from a public repo (the Toptal and Frontend Mentor ones are honest enough) and run my sequence on it tonight. If you push it up, send me the link. I will read it and write back.