When I close a frontend take-home early

Most take-homes do not fail on missing features. They fail when I lose trust early — in the first open, the first empty state, or the first README claim that the code does not keep. Here is when I close the tab.

I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers actually open. This sits next to what I actually open in a frontend take-home, what I ask after you finish, and questions I hope you ask. Same bar. Earlier cut.

Photo: cottonbro studio / Pexels.

I am not hunting for perfection

I expect incomplete work. A take-home is a time box, not a production launch. I close early when the signal is noisy: I cannot tell what you chose, what you skipped, or whether the happy path even runs. Incomplete with a clear assumptions list still gets a fair read. Incomplete with mystery errors does not.

If you shipped one polished flow and named three deliberate cuts, I stay. If you sprayed half-wired routes and hoped breadth would impress me, I leave.

The first sixty seconds that lose me

Before I judge architecture, I do the same pass every time:

• clone or open the deploy link,
• follow the README until something renders,
• hit the primary happy path once,
• glance at empty, loading, and error for that path.

I close early when setup fights me for more than a few minutes without a documented escape hatch, when the deploy 404s on the route the README promises, or when the app boots into a white screen with a console error that the README never mentions. That is not “I am picky about tooling.” That is “I cannot evaluate the product judgment if I cannot see the product.”

README claims the code does not keep

Soft kills look like this:

• “Fully accessible” with no keyboard path through the main flow,
• “Production-ready” with any plastered across the data layer,
• “Handles offline” when there is no offline path at all,
• a feature list that includes screens the router never reaches.

I would rather read “keyboard and focus were out of scope for the time box; empty and error states are in.” That sentence raises trust. Overclaiming drops it faster than a missing feature.

Empty and error states that feel abandoned

I open the empty state on purpose. A spinner that never resolves, a blank list with no copy, or a red console dump when the mock API fails tells me how you behave when the demo is not flattered. In a live screen I can ask follow-ups. In a take-home, those states are the follow-up.

You do not need a design system. You need one honest empty message, one recoverable error, and a loading state that does not look like a crash. Candidates who only polish the seeded happy path often lose here.

Assumptions I cannot find

If I have to reverse-engineer why you skipped auth, pagination, or mobile layout, I am doing your product writing for you. Put the assumptions where I will see them: top of the README, or a short ASSUMPTIONS.md. Name the user, the MVP path, and the cuts. Link the cuts to time, not to taste.

Weak substitute: a long architecture essay with no running UI. Strong substitute: a short list, then a working slice that matches it.

Structure that makes review expensive

I close early when:

• business logic lives only inside giant page components with no seams,
• naming is inconsistent enough that I cannot search for the main flow,
• dead files and commented experiments outnumber the path I am meant to review,
• there is no obvious entry component for the feature you asked me to judge.

I am not asking for enterprise folders. I am asking to find the decision quickly. If your best thinking is buried under unused experiments, I may never reach it.

Tests that prove the wrong thing

Zero tests will not auto-fail a short take-home if the UI is clear. Misleading tests will. A suite that asserts class names while the main mutation is untested, or snapshots of the marketing shell with no coverage of the interaction I care about, reads as theatre. One or two tests around the risky behaviour beat twenty shallow ones.

What keeps me reading after a rough start

I stay when the happy path works, the README matches the build, and the cuts are explicit. A visible trade-off note next to a simpler state model is often stronger than a fashionable library choice. Same for accessibility: one protected focus path on the primary dialog beats a checklist you did not implement.

If something is broken, say so above the fold in the README with the command you tried and what you would do next with another hour. That is ownership. Silence around a broken path is not.

How this differs from the live screen

In a pair interview I can interrupt and re-scope. In a take-home, your artefacts are the interview. The README is your clarifying questions. The empty state is your follow-up answer. The commit history, if you include it, is whether you built in slices or in one opaque dump. I wrote more on the open order in what I actually open; this piece is about the early exits in that order.

What a pass looks like under time pressure

A pass I can defend in the debrief:

• one MVP path runs locally or on a deploy without heroics,
• assumptions and cuts are written where a tired reviewer will see them,
• empty, loading, and error exist for that path,
• claims in the README match the code,
• I can find the core decision in a minute of searching.

That is enough to earn a live conversation. Fancy animation is optional. Trust is not.

What a soft no looks like

Common early closes:

• broken install with no pinned node version or lockfile note,
• deploy link that does not match the repo tip,
• README feature list that the UI does not honour,
• happy path only, with crashes on empty data,
• no assumptions, so every gap looks like an accident,
• a refactor mid-submission that leaves the main flow half-migrated.

I would rather hire someone who shipped a small true thing than someone who gestured at a large false one.

How to practise the early-trust pass

Do not wait for a company prompt. Take a tiny UI brief and time-box ninety minutes:

1. Write five assumptions before you code.
2. Ship one path with empty, loading, and error.
3. Delete one feature you wanted but cannot finish; record the cut.
4. Cold-open your own README the next morning and follow it like a stranger.

If you trip on your own setup, fix the docs before you add scope. CodePrepped’s daily loop and Code Arena bouts are built for short reps with visible states — the same muscles a take-home rewards. Silent algorithm drills will not train the trust pass.

Should I include a live deploy?

If the brief allows it and you can keep it in sync with the repo, yes. A stale deploy that contradicts main is worse than local-only with crisp run steps.

Will you fail me for missing tests?

Not by default on a short frontend take-home. I will judge the states I can see. If you add tests, aim them at the behaviour that could break users, not at implementation trivia.

Is a long architecture section helpful?

Only after the app runs. Architecture notes that explain a trade-off I can see in the code help. Essays that replace a working slice do not.

What if I run out of time mid-refactor?

Stop and leave the last green path runnable. Note the refactor as a next step. A half-migrated tree is one of the fastest ways I close early.