What do reviewers read from the commit history of a take-home repository?

## Why an optional signal is worth ten minutes Many take-home reviewers never look at the version-control history; some open it first. Because the cost of getting it right is close to zero and the downside of getting it wrong is concrete, it is one of the better-value habits in take-home craft. ## What good history communicates A sequence of commits is a record of the order in which you attacked the problem. A reviewer scanning a submission for a remote-first scale-up's data brief - ingest, deduplicate, aggregate - can see whether you built a skeleton and deepened it, or thrashed. Roughly a dozen commits across a six-hour build, each with a message naming a behaviour rather than a file, reads as an engineer who works in steps. Messages that only say update, fix or wip forfeit that entirely. It also carries the decisions the README summarises. When a commit message says that deduplication now keys on a composite identifier because raw event ids repeat across files, the reviewer sees a reasoned choice at the moment it was made. ## The things that actually cost you **Secrets and real data.** A committed key, token, connection string or extract of real personal data is the one take-home mistake that can end a process on its own, because it is read as a judgment failure rather than a style preference. Check what you are adding before you add it, and keep an ignore file from the first commit rather than cleaning up later - removing a secret in a later commit does not remove it from the history. **Generated noise.** Dependency directories, build output, editor and OS files, local environment files. They bloat the repository and make the diff unreadable, and their presence suggests the same thing will happen in a real codebase. **One squashed commit for everything.** Legal, and sometimes required if the employer asks for an archive rather than a repository, but it discards a free signal. If the submission format forces it, say in the README how you worked. **A contradiction with your README.** This is the one that bites. A candidate who spent roughly 31 hours across nine days, built far past the brief, and then wrote about six hours in the README leaves 17 commits stretching across those nine days as evidence. The overbuild was a scoping problem; the mismatch turns it into a credibility problem, which is much worse and much harder to recover in a follow-up conversation. If you overshot, put the real number in the README and let the history agree with it. **Rewritten history to look tidy.** Rebasing to clean up a genuinely messy sequence is normal practice. Manufacturing a plausible-looking sequence of timestamps for work that happened differently is fabrication, and clustered rewrite timestamps make it detectable. The upside is tiny and the downside is your credibility. ## Practical checklist before you submit - An ignore file added in the first commit, covering dependencies, build output and local environment files. - No credentials, tokens or real datasets anywhere in the history, not just the final tree. - Messages that name behaviour: what changed and why, not which file moved. - Commits that group logically - core path, then error handling, then tests, then README - rather than one per hour or one for everything. - A final scan of the diff against an empty repository, so you see exactly what the reviewer receives. ## If the employer wants a zip file Some companies request an archive, occasionally to anonymise submissions. Include the history directory if they permit it, and if they do not, keep the same discipline anyway - the artefacts, secrets and ignore-file rules matter independently of whether anyone reads your commits.