What I actually open in a frontend take-home

What I actually open in a frontend take-home

Photo by Lukas on Pexels.

A take-home is not a longer screen. It is a short PR you send to a stranger who already has a full calendar.

I open it the way I open a pull request from someone I have never paired with. Can I run it. Can I find the decision. Can I imagine a teammate extending it next week without a call. Most candidates treat it like a portfolio piece they will never ship. I treat it like the first commit on a team they have not joined yet.

If you already pass live screens and still get quiet rejections after take-homes, this is usually why. The scorecard and the 45-minute screen marks still apply. The take-home adds one more filter: can you leave a trail when nobody is watching.

What a take-home is actually testing

I am not testing whether you can finish every stretch goal. I am testing whether you can scope, name the interface, put ugly paths on the page, and leave a README a tired interviewer can trust at 22:00.

A polished happy path with no loading state, no error path, and a README that says npm start is a soft no. An unfinished UI with a clear contract, honest stubs, and a short note on what you would do next is a yes. Silence in a take-home looks like a missing README, unexplained magic, and a surprise architecture.

Restate the brief before you invent features

Open the prompt. Write one paragraph in your own words: user, finished flow, out of scope. If the brief is vague, choose one interpretation and say so at the top of the README. I mark that sentence harder than a bonus animation.

Do not invent a design system, a state library, and three micro-frontends because the prompt said “build a small app.” Build the smallest thing that proves the interface. Stretch goals are optional. A clear no on scope is a senior signal.

Name the interface in the README

Before I read a component, I look for props, routes, form fields, API shape, and what is stubbed. Put that in the README in five lines. The same habit as naming the interface in a live screen — just written down so I can quote it in the debrief.

If the data is fake, say so. If the API is a JSON file, say so. If accessibility is partial, say what works and what you would finish. Guessing what I wanted is slower than telling me what you chose.

Ugly paths still beat the happy path

Empty, loading, error, disabled submit, empty list. Put them on the page even when the brief only shows the success state. A take-home without an error path tells me you only ever demo the sunny day.

I do not need every edge case. I need evidence you thought about the ones a real user will hit. Mid-level adds retry or a clear message. Senior picks which ugly path to skip because of time and writes that choice down.

Markup and a11y are not a closing remark

Labels, real buttons, headings that are headings, keyboard through the form. I am not running a WCAG audit on your zip file. I am checking whether the defaults are there without a special “a11y section” that apologises for a div with an onClick.

If you used a UI kit, fine. Say which parts you overrode and why. Framework comfort is allowed. Framework instead of the document is not.

Make it runnable in under five minutes

I will spend five minutes trying to run it. Node version, install, start, one happy path click. If that fails, the rest of the work is expensive to defend.

Pin a Node version or note it. Prefer a lockfile. Avoid private packages I cannot install. Do not require a paid API key for the core flow. If you need an env var, ship a .env.example with safe defaults or a mock.

Leave a short decision log, not a novel

Three to seven bullets: what you built, what you skipped, the trade-off you would still make with another day. That is the paragraph I quote. A 2,000-word essay about your love of clean architecture is not.

Link to the live screen habits that still apply: narrate trade-offs, recap what is stubbed, avoid treating LeetCode as the frontend exam. The take-home is the written version of the last five minutes of a screen.

Photo by Markus Spiske on Pexels.

What I do not mark in a take-home

I do not mark a second design system. I do not mark test coverage theatre with zero product states. I do not mark a commit history that looks like one giant dump at midnight with a message of final. A few commits with real messages help; perfect git archaeology does not.

I also do not mark speed alone. A weekend of unpaid work that rebuilds half a product is a signal about boundaries, not seniority. Scope hard. Ship the contract.

How this fits the rest of your prep

Live screens test pairing under a clock. Take-homes test judgement without an audience. Portfolios and GitHub test whether a stranger can find the story — see your developer profile and the GitHub pass.

On CodePrepped, practise the same muscles in the daily loop: Sandbox for the build, Arena for timed judgement, Keywords for the words you put in the README. Pro adds voice practice when you need to defend the take-home on a follow-up call. Live pricing: Basic $19/month or $190/year with a 7-day trial on Basic monthly; Pro $39/month or $299/year.

What to do on your next take-home

1. Rewrite the brief in one paragraph. Put scope and stubs at the top of the README.
2. Name the interface before you add libraries.
3. Ship empty, loading, and error before the last visual polish.
4. Make install and start boring. Five minutes, not fifty.
5. End with a short decision log and the next three steps you would take.

Then stop. Send it. Do not rebuild it the night before because you found a prettier button.

What do interviewers look for in a frontend take-home?

They look for a small, runnable UI with a clear interface, honest stubs, ugly paths on the page, and a README they can trust quickly. Finishing every stretch goal is optional. A polished happy path with no contract is not a pass.

How long should a frontend take-home take?

Long enough to prove the interface, short enough that you still have boundaries. If the brief is unbounded, time-box yourself, write the scope in the README, and stop. A weekend that rebuilds a product is rarely the signal companies think it is.

Do I need tests in a frontend take-home?

Useful tests on the behaviour you claim to own help. A wall of snapshots with no loading or error coverage does not. Prefer a few tests that lock the contract over coverage percentage theatre.

Should I use my favourite state library in a take-home?

Only if it removes real pain in the brief. A naive useState you can defend beats a cache layer you cannot explain in the follow-up call. Name the problem the library solves, then keep the surface small.

What belongs in the README of a take-home?

How to run it, what you built, what is stubbed, the interface shape, accessibility notes, and the trade-offs you would still make. Keep it short. I am reading it between meetings.

How do I practise take-homes without a live brief?

Pick one small UI. Time-box. Write the README first. Ship ugly paths. Record a two-minute walkthrough as if the follow-up call started now. CodePrepped Sandbox plus a voice memo is enough. Repeat the same brief after feedback rather than collecting a new prompt.

What if I cannot finish the take-home?

Ship what you have with a clear decision log. Unfinished work you can defend beats a late “almost done” message. Say what works, what is stubbed, and the next three steps. That is how I argue for you after I close the zip.