What is the difference between a full stack take-home assignment and a live coding interview?

A take-home is asynchronous work, usually three to six hours of building a small app, judged on decisions you can justify later: schema, error handling, tests on the hard part and a README that runs. A live coding round is 45 to 60 minutes judged on how fast you get a working vertical slice and how you recover when something breaks in front of someone.

Which is harder, a take-home or a live coding round?

They fail different people. A take-home is harder if you have limited evening time, because the real cost is often double the stated budget. A live round is harder if environment friction or nerves slow you down, since half the signal is collected in the first fifteen minutes. Neither is easier overall, so choose the format you can rehearse.

How is the take-home plus live walkthrough hybrid scored?

The submitted code is the entry ticket and the walkthrough is the verdict. A typical two-hour call spends ten minutes on your demo, twenty to thirty on why you made specific choices, then forty-five to sixty watching you extend your own codebase live. Most rejections happen in that extension segment, not in the code you sent.

Can I use AI to write a take-home assignment?

Some companies allow it and ask you to disclose it, others forbid it, so read the brief. The practical problem is separate from the policy: a take-home is work you defend line by line on a follow-up call, and code you did not reason about collapses at the first question about why you chose that schema or where the transaction boundary sits.

What do reviewers look at first in a full stack take-home?

Usually the README, then a fresh clone and an attempt to run it, then the commit history, then the diff. A project that does not start on a clean machine is often scored before any code is read. Seed data, a working setup command and a short section naming what you deliberately left out carry more weight than extra features.

How long should a full stack take-home actually take?

Stop at the stated budget and write down what you would do next. Briefs that say four hours are frequently completed in ten or more, and reviewers can often infer effort from commit timestamps. A scoped submission with an honest trade-offs section reads as senior judgement, while an over-built one invites questions about code you rushed.

Full Stack Take-Home vs Live Coding: What Each Format Grades

A take-home grades decisions you can still defend a week later. A live round grades your first ten minutes and how you behave when your own stack trace appears on a shared screen. The increasingly common hybrid, a short take-home followed by a scoped two-hour live walkthrough of your own code, is scored almost entirely on the second half. The honest consequence: a take-home is work you must defend line by line, so live assistance belongs in the walkthrough round, not in writing the submission.

The three formats side by side

Consultancies skew towards take-homes, early stage startups towards live rounds, and much of the middle has moved to the hybrid, which is cheaper than a four-hour onsite and harder to outsource than a repository.

	Take-home	Live coding	Hybrid
Stated time budget	3 to 6 hours	45 to 60 minutes	2 to 4 hours building, then a 90 to 120 minute call
Realistic cost	Often double the brief, plus a follow-up call	The hour, plus rehearsal	Close to the brief, the code is deliberately small
What it rewards	Schema choices, error handling, tests on the hard part, a README that runs	A working vertical slice fast, thinking out loud, reading an error calmly	Changing your own code under observation
What fails candidates	Will not start on a clean clone, one giant commit, tests only on trivial CRUD	Forty minutes of data layer with nothing rendered, silence while stuck	Slow navigation of your own repo, no answer to "why this way"
Where the score is decided	The first five minutes of review	The opening questions and the first thing that runs	The live extension segment, not the submitted code
Recovery from a bad start	Good, rewrite before submitting	Poor, the clock is the constraint	Good in the build, poor in the call

What a full stack take-home is actually graded on

Most briefs share a shape: a small domain with real records, an API over a database, a list view with filtering and pagination, and one hard thing bolted on. The hard thing is the point: optimistic concurrency on an edit, a background job, an idempotent write, role-based access. Everything else is scaffolding, and reviewers work in a predictable order.

The README, then a fresh clone. They paste your setup command into a terminal with none of your environment on it. If install, migrate, seed and start do not work in that order, the review is mostly over. Ship seed data: a list view with no rows cannot be assessed.
The commit history. One 900-line commit called "solution" reads as either a paste or a panic. Six or seven commits with sane messages let a reviewer follow your reasoning.
The hard thing. If the brief asked for concurrent edits, they look for a version column or a transaction, not for how prettily you wrapped the list component.
The tests. Forty tests on CRUD getters and none on the concurrency case is the most common self-inflicted wound. Two tests on the hard part outrank twenty on the easy part.
The trade-offs section. Three or four lines naming what you left out and why. The cheapest signal of seniority in the submission, and it sets the agenda for the follow-up call.

A four-hour brief answered with Docker Compose, CI, a component library and an auth service invites a reviewer to ask which parts you rushed. Stop at the budget and list what you would build next.

What a live full stack round measures instead

Live rounds are either a bare project where you build a thin feature end to end, or an existing service where you add an endpoint and wire it to a screen. The grader watches a process rather than reading an artefact.

The behaviour separating passes from fails is the vertical slice: one route returning hard-coded JSON, rendered, then made real. Forty minutes on a repository layer and a DTO mapper without a rendered row fails rounds you were capable of passing. Interviewers also score whether you clarify before typing, whether you narrate while stuck, and whether an error message makes you read it or flinch. Knowing your editor and how to restart a dev server buys minutes you cannot recover later.

How the hybrid is scored

The hybrid exists because take-homes stopped being reliable evidence of authorship. A short brief, deliberately smaller than a classic take-home, then a call of roughly two hours in four segments.

About 10 minutes: you demo

You share your screen and run the thing. Scored loosely, but it starts badly if the app will not launch on your own machine. Have it running before the call.

20 to 30 minutes: why, not what

They read your code with you and ask about specific lines. Why this schema, where the transaction boundary sits, what happens on a duplicate submit. "That is the convention" scores near zero. Naming what you traded away scores well even when the choice was imperfect.

45 to 60 minutes: extend it live

The segment that decides the outcome. Typical asks: add pagination to the endpoint you wrote, add one field end to end through migration, API and UI, make a write idempotent, fix an N+1 they noticed, or write the test for the case you skipped. In your own codebase, at your keyboard, while they watch.

10 minutes: your questions

Weighted less than candidates think, though asking how they handle migrations or on-call lands better than asking about culture.

The tells a panel reads as "did not really write this" are behavioural, not forensic. Hesitating over where a file lives. Being unable to run your own test suite. Explaining a function in general terms when asked about one line. None is proof, but together they move a borderline candidate to a no.

Preparing takes half an hour. Clone your submission into a fresh directory and run it from the README you wrote. Read the diff as if reviewing a stranger. Write down the three decisions you would attack, and answer each. Pre-open the files an extension will touch.

Where live assistance belongs, and where it does not

A take-home is not a test you pass by submitting; it is a claim you underwrite in a conversation. Help that goes into the submission comes back as debt in the walkthrough, collected under time pressure by someone reading the code with you. If you use assistance while building, use it the way you use documentation, to understand a pattern you then implement and can explain. Check the brief: some companies permit AI with disclosure, others prohibit it.

The walkthrough and the pure live round are different. There you reason out loud about a codebase you know, and a prompt holding a definition or a complexity argument is closer to a notes page than a ghostwriter. That is what Code Copilot is for, and here are its limits:

Windows 10 and 11 only. No macOS, Linux, mobile or browser-extension build. If you interview on a Mac, none of this is available to you.
Capture exclusion covers screen sharing and recording, nothing more. The overlay is excluded from capture at the operating system level, so it does not appear in Zoom, Teams, Meet, OBS or screenshots while staying visible on your own monitor. It does nothing about a webcam, a lockdown browser, eye tracking, a proctor in the room, or a second-device camera.
It cannot rehearse for you. Nothing on screen makes you fluent in a repository you skimmed. In the extension segment, code leaves your hands at conversational speed or not at all.
The rules belong to the company. If the brief is ambiguous about tooling, ask before the call.

Choosing, when you get a choice

Take the take-home if your strengths are structural, if you interview badly while observed, and if you have two clear evenings. Take the live round if your calendar is full or you can scaffold your stack without looking things up. If it is the hybrid, treat the build as the smaller half.

The take-home gets you the meeting. The meeting gets you the offer. Budget your effort accordingly.

Practice that works: one small end to end feature a week under a timer, then explaining your own diff out loud until the explanations get short. For the half of the process that is not code, the company Q&A generator builds a question bank for a named company and role, and the question banks cover the follow-ups after a code review. The free tier is 5 minutes a day with no card; plans start at $39 a month.

Full stack take-home vs live coding: what each format actually grades