Take-home Assignment Strategy

How to approach frontend take-homes — scope control, README quality, testing, and timeboxing without overbuilding.

intermediate3 min readUpdated Aug 4, 2026

interview
take-home

Take-homes reward judgment under a time budget. Many candidates lose by building a framework showcase and missing the product brief.

What reviewers usually score

Meets the brief — MVP complete
Code clarity — structure, names, components
UX completeness — empty/loading/error
Engineering taste — tests, a11y, sensible deps
Communication — README tradeoffs & run instructions

Before you write code (30–60 minutes)

Restate requirements as a checklist
Mark MVP vs stretch
Choose stack they prefer (or neutral Vite+React+TS)
Estimate hours; cut scope until realistic
Note questions; if no contact, document assumptions

Never invent requirements that balloon scope (“also dark mode + i18n + PWA”).

Time budget (example: 6 hours)

Block	Hours	Output
Spec & setup	0.5	Repo, lint, base layout
Data layer	1	API client, types, mock
UI happy path	2	Core screens work
States + a11y	1	empty/error/focus
Tests	0.75	Critical path
README + polish	0.75	Run, tradeoffs, next steps

If happy path slips, cut stretch features, not the README.

Architecture defaults (safe)

src/
  components/   # presentational
  features/     # domain UI + hooks
  lib/          # api, utils
  types/

Prefer feature folders over premature clean architecture
Server state: simple fetch + local state, or TanStack Query if already natural
Styling: CSS modules or light Tailwind — consistency > novelty

Product quality bar

Area	Minimum
Loading	Skeleton or spinner
Error	Message + retry
Empty	Helpful zero state
Forms	Labels, validation messages
Lists	Keys stable; basic responsive
A11y	Keyboard, focus, contrast sane

Patterns: Accessible forms · Testing library.

Testing strategy (high signal, low volume)

Pure logic unit tests (filter/sort/parse)
One RTL flow for the main journey
Skip pixel-perfect snapshots unless asked

Testing pyramid · Unit testing pure logic.

README that gets you interviews

Must include:

How to run (Node version, commands)
Assumptions
Architecture decisions (short)
Tradeoffs & what you’d do with more time
Screenshots optional but useful

Example tradeoff section:

## Tradeoffs
- Client-side filter for MVP; would move to server for >10k rows
- No auth; assumed public API key for demo only
- Virtualization skipped; list expected small per brief

Common take-home fails

Fail	Fix
Over-engineered monorepo	One app
No error states	Matrix of UI states
Giant untyped `any`	Strict TS on your code
Unrunnable without tribal knowledge	README + lockfile
Commit history of “final.zip”	Meaningful commits if git asked
Accessibility ignored	Real buttons/labels

If the assignment is huge

Some take-homes are unpaid multi-day projects. Decide:

Cap hours; deliver excellent MVP + honest README
Or decline if scope is exploitative relative to process

You’re allowed to protect your time.

After submission

Be ready to extend live — same repo
Rehearse architecture walkthrough — Explaining projects
Don’t keep coding silently after deadline unless invited