Use case

Take-home projects, reviewed as a diff

A timed sitting and a multi-file project across three days have almost nothing in common past the word “assessment”. This is the second one: a real repository against a deadline, a workspace the candidate opens with a link, and a review that shows what they changed rather than what they submitted.

Get started free Timed assessments instead

Candidate account: None; A single-purpose link that grants exactly one assignment and nothing else.
Works across: Days, devices; Laptop, then desktop, then a phone to re-read the brief. The link survives all of it.
After the deadline: Frozen; Every write is refused and the tree is read-only. One place in the code decides that.
Authorship verdict: Not claimed; The review reports how much the edit stream accounts for. A person draws the conclusion.

What the candidate gets

A workspace, not an email attachment and not a private repository invitation you have to chase.

Before they start: the shape, not the question

They see the title, the deadline and roughly how long it should take, so they can decide when to begin. They do not see the brief or the starter code, because the brief is the question and reading it three days early changes what is being measured.

After they start: a real tree

Starter files, a file tree they can read and write, and the ability to run the entry point. The clock is the deadline rather than a countdown, so a candidate with a job and a life can work in the evenings.

No login, one purpose

The link is a long random token, and it grants access to exactly one assignment. It carries no company, no role and no other record — which is what makes it safe to send to somebody who will never have an account here.

At the deadline: frozen

After the deadline or after submit, every mutating route refuses and the tree is read-only. There is one place in the code that decides this, so no route can quietly drift from the rule.

The review is a diff, not a folder

Reading a submitted project as a directory listing is how a reviewer ends up scoring the starter code.

The review opens on what changed: files added, modified, deleted and untouched, with lines added and removed, and a real unified diff per file rather than a code block with a colour on it. An added file with no diff is an empty file the candidate created, and the interface says that rather than showing nothing — a small thing that saves a reviewer from concluding the tool is broken.

Alongside it: working sessions, timed by the server rather than by the candidate's clock, with active minutes and event counts. A project built across four evenings and one built in ninety minutes at 2am the night before are different submissions, and both are legitimate — but a reviewer should know which one they are reading.

The score itself comes from a scorecard you defined with the assessment, so two reviewers are marking the same criteria rather than each inventing their own.

The authorship question, answered honestly

Every buyer asks it and most vendors answer it dishonestly. An unsupervised assessment cannot tell you who wrote the code. It can tell you what it observed.

The workspace records an append-only edit stream while the candidate works. At review time, the submitted content is matched against what that stream actually produced, and the result is reported as one of three bands.

Band	What it means	How to read it
Fully accounted for	Nearly all of the submitted content can be rebuilt from the edit stream the workspace recorded.	The ordinary result, and note what it does NOT say. The replay applies pastes, so this band covers a project pasted in from a local editor just as well as one typed in the browser — which is why it is reported next to a count of how much arrived in blocks, and never on its own. Evidence about the record, not proof of authorship.
Partly unaccounted for	A substantial part of the submission has no edit history behind it.	Extremely common and usually innocent: work drafted in a local editor and pasted in, a generated scaffold, a config file copied from documentation. A question, not a finding.
Largely unaccounted for	The recorded stream accounts for very little of what was handed in.	Worth asking about directly. It is also exactly what an honest candidate who built the whole thing locally looks like, which is why it is a band and not an accusation.

This is a measurement, not a verdict — and the difference is the whole pointA candidate who prefers their own editor, has an unreliable connection, or simply drafts in a text file before pasting produces the same signal as one who did not write it. Any product that turns this number into a cheating determination is selling you a false positive with a confident interface on it. What it is genuinely good for is knowing which submissions to ask about, and what to ask.

What a take-home cannot prove, in this or any product

It cannot be proctored. There is no camera, no screen recording and no supervision, by design — the whole point is that the candidate works in their own environment, at their own hours. Every claim to the contrary in this category is either about a different product shape or is untrue.
It cannot exclude an assistant, human or otherwise. In 2026 that is true of every unsupervised assessment on earth, and a hiring process that pretends otherwise is making decisions on a fiction.
It cannot measure speed. A deadline measures whether somebody organised three days around your assessment, which is a fact about their circumstances more than their ability.
It cannot be long without becoming a filter for free time. A take-home that costs eight unpaid hours does not select for the best engineer, it selects for the one with the fewest obligations.

What it can do is show you how somebody works in a codebase, which no timed puzzle does — and the follow-up conversation, where they extend or debug their own submission live, is what turns that into a decision. That conversation is also the single most reliable authorship check anyone has ever found. If you want the supervised half of the process too, that is proctored assessment.

Designing one people actually finish

Completion rate is the metric nobody publishes, and it is where most take-home programmes quietly fail.

Say the time budget and mean it. Publish the expected minutes with the assessment, and score against that budget rather than against what somebody with a free weekend produced.
Ship real starter code. A repository that already runs removes an hour of environment setup that measures nothing. It also makes the diff readable, because the reviewer knows exactly what was there before.
Make the brief the question. Ambiguity a candidate has to resolve is the most informative part of a take-home, and it is invisible in the code — ask for a short note on what they assumed and what they would do next.
Give the time back. Where a take-home replaces a technical round, say so to the candidate. Where it is added on top of four other rounds, expect the good candidates to decline, and they will be right to.

Elsewhere on this site

Campus and volume hiring

A roster, an assessment window, and one live console that answers the only question that matters on the morning: how many turned up.

Remote and distributed hiring

One-way video screening, live interviews in the browser, and scheduling that works in the candidate’s clock rather than yours.

Security and data protection

Tenant separation, retention, erasure, sub-processors — and the certifications this product does not hold.

Pricing

The plan ladder, what one assessment means as a billing unit, and how a plan actually gets set today.

Set one up against a repository you already have

Take a small piece of real work, strip it back to a starter tree, write the brief, and send it to one person. The review is where you will know whether this shape of assessment tells you anything — and it takes an afternoon to find out.

Get started free See pricing