Take-Home Assignments and Live Case Studies: The Complete Guide

What it is

A take-home assignment is a piece of work you do alone, unobserved, against a written brief, and then hand over for judgement. A live case study is the same transaction compressed into an hour with the assessor in the room. Both have quietly displaced large parts of the traditional interview loop, and both are graded by criteria that are almost never written in the brief you receive.

That gap between the brief and the rubric is the entire subject of this page. The brief says "build a small service that ingests these CSV files and exposes an endpoint to query them" or "here is a company's revenue data, recommend what they should do next quarter". The rubric asks something different: can this person work without supervision, what do they do when the requirements do not answer a question they need answered, do they know what to leave out, and can they defend a choice without either collapsing or digging in. A candidate optimising the brief and a candidate optimising the rubric produce visibly different submissions, and the second one is hired.

The stage carries an unusual emotional load, and it is worth naming rather than pretending away. Every other round consumes an hour of your evening and is over. A take-home consumes a weekend you did not have, on a problem you did not choose, for an outcome that will frequently be communicated to you as a two-line rejection with no explanation. Candidates resent it because a portion of the practice genuinely is unpaid labour, because the time cost is distributed unevenly across people's lives, and because the silence afterwards makes the whole exchange feel like it went into a bin. All of that is true at the same time as this: a well-designed exercise is one of the fairer instruments in hiring, because it is the only stage where you are judged on work rather than on how you sound. Holding both facts is the position this guide argues from.

The path through the stage has one branch that most candidates never take, and it is the branch that changes the outcome most often.

flowchart TD
  accDescr: The path through a take-home from brief received to decision, turning on whether scope is clarified, an unreasonable ask being negotiated, deferred or declined and returning to clarification, and an agreed one leading to a time box agreed in writing, building inside the box, submitting with a covering note and the playback session.
  BRIEF[Brief received] --> CLAR{Scope clarified}
  CLAR -->|ask is unreasonable| NEG[Negotiate defer or decline]
  NEG --> CLAR
  CLAR -->|agreed| BOX[Time box agreed in writing]
  BOX --> BUILD[Build inside the box]
  BUILD --> SUB[Submit with covering note]
  SUB --> PLAY[Playback session]
  PLAY --> DEC[Decision]

Look at the loop back from the negotiation node. Asking a scoping question, proposing a smaller version, or saying the stated time box does not fit the stated scope is itself graded, and graded well by anybody sensible, because it is the behaviour they need from you on the job. Most candidates go straight from brief to build without a single question, which reads as either incuriosity or fear, and neither is what they were hoping to find.

The formats this covers, and where they diverge

An asynchronous coding exercise is the commonest form in software engineering. You are given a problem, a time suggestion between two and eight hours, and a submission mechanism, usually a git repository or a zip file. Grading is done by reading the code, not running a scorer, which is why it is judged like a pull request from a new colleague rather than like an exam.

A written case or memo appears in product, business analysis, engineering management, consulting-adjacent and strategy-adjacent roles. You get a scenario and a page limit, and the page limit is a real constraint that forms part of the assessment. A three-page answer to a two-page brief has already lost marks before anybody read the argument.

A deck is the same content with a presentation attached, and the presentation half is weighted far more heavily than candidates expect. Two candidates can submit the same analysis and be separated entirely by whether the recommendation arrived in the first sixty seconds.

A live case study or working session runs in real time, an hour to ninety minutes, with the interviewer present and available. It looks like the hardest format and is often the fairest, because you cannot overinvest, you cannot be beaten by a candidate with a free week, and you can ask questions. It also grades something the async formats cannot see: how you think when you do not yet know the answer.

A paired or observed exercise sits between the two. You write code or work a problem with somebody watching, sometimes contributing. It is a proxy for collaboration rather than for capability, and the graded content is almost entirely how you narrate and how you receive a suggestion.

A portfolio walkthrough is the substitute format worth knowing exists, because it is what you will propose when you want to decline a take-home without leaving the process. You present work you have already done, and you take questions on it in the same adversarial register a playback session uses.

Who reads it, and when

The identity of the grader shapes what gets rewarded more than the format does, and you can usually find out by asking.

A submission read by the hiring manager is read as a hiring decision, quickly, probably in twenty to forty minutes, probably alongside four others. They will skim the README, try to run it, read two or three files, and read your covering note carefully. Depth in a corner they do not open is invisible.

A submission read by two or three engineers on the team is read as a code review, more slowly and less charitably, with each reviewer forming a view and then comparing. Disagreement between reviewers is common and is usually about scope: one thinks you did too little, one thinks you gilded it. That disagreement is resolved by whatever you wrote down, which is why the written material is disproportionately powerful.

A submission read by a panel in a playback session is barely read in advance. Some of them will have skimmed it in the ten minutes before the call. This changes your presentation strategy fundamentally: you cannot assume shared context, and the first two minutes have to establish what you built and why before you demonstrate anything.

A case marked against a structured scorecard with named competencies is the fairest and the rarest. When it happens, the competency names are frequently sitting in the invitation email, and reading that email properly is the cheapest mark available in the whole process.

Why we need it

The exercise exists because the traditional interview has a specific and well-understood blind spot: it measures performance in a forty-five-minute conversation with a stranger, and almost no job resembles that. Whiteboard rounds select for recall under adrenaline. Behavioural rounds select for narrative skill, and a candidate who has rehearsed their stories well is measuring their rehearsal, which is the honest reason preparing stories without sounding rehearsed is a skill at all. Neither round tells the hiring manager the thing they most need to know, which is what your work looks like when nobody is watching and the requirements are incomplete.

That is the gap the exercise fills, and it fills it honestly. The output is an artefact. It can be re-read, compared against other candidates, argued about in a debrief, and pointed at when two interviewers disagree. In a loop where a split debrief between strong hire and no hire has to be resolved, the submission is the only piece of evidence everyone can look at again. That evidential quality is why the format keeps spreading despite being unpopular.

There is a second, less discussed reason, which is that the exercise partially corrects for interview polish. A candidate who is nervous, or who is not a native speaker of the interview's language, or who does not perform confidence well, is systematically penalised by conversational rounds and systematically helped by an artefact-based one. Companies that care about this say so. Companies that do not say so still benefit from it.

The third reason is defensive, and it explains why some exercises are badly designed. A hiring manager who has been burnt once by a candidate who interviewed brilliantly and could not do the work will add a stage, and the stage they add is whatever would have caught that specific person. This is how exercises accumulate requirements that made sense for one bad hire in 2023 and nothing since. When a brief feels arbitrary, it frequently is arbitrary, and it is arbitrary for a traceable historical reason rather than out of contempt for your time.

What the format is really testing

The brief describes a deliverable. The rubric measures conduct. Six things are being read off your submission, and only the first is named in the brief.

Competence at the stated task is table stakes and roughly a pass or fail. Nobody is awarding a prize for an unusually good CSV parser. If the thing works and the code is unembarrassing, this dimension is satisfied and stops earning marks.

Behaviour under ambiguity is the biggest single differentiator. Every brief has holes in it, and most are deliberate. What do you do with the hole: guess silently, guess and write down that you guessed, ask, or build for every possibility. Only two of those four score. The same instinct is being probed conversationally when an interviewer asks about a time the requirements were unclear, and the exercise is the version of that question you cannot rehearse.

Judgement about scope is second, and it is where most strong technical candidates lose. More detail below, because the conventional advice on this point is wrong.

Ability to communicate work in writing is graded whether or not the brief mentions it. Your README, your commit messages and your covering note are prose written for a colleague, and if you cannot do that on a two-hour exercise nobody believes you will do it on a six-month project.

Honesty about what you did not do is graded, and it is graded generously. A candidate who says "I did not write integration tests for the export path, and here is why I chose that over cutting the validation" is telling the reviewer that their reports will be trustworthy. A submission with no stated gaps is either dishonest or unreflective, and reviewers assume the former less often than candidates fear and the latter more often.

Whether you are pleasant to work with is read off the whole package: whether the brief was respected, whether the note is defensive, whether the code shouts about how clever it is, whether the tone of a clarifying email was collaborative or lawyerly. This dimension is rarely on the scorecard and always in the room.

Why the brief is not the rubric

Briefs are written to be short, unambiguous about the deliverable, and reusable across many candidates. Rubrics are written to discriminate between candidates. Those are different jobs, and a brief that contained the rubric would defeat the exercise: if the brief said "we are mainly assessing whether you resist the urge to add features", everybody would resist, and the signal would vanish.

So the brief systematically under-describes what matters. It will tell you what to build and say nothing about how the trade-offs should be recorded. It will suggest four hours and say nothing about what happens if you take twelve. It will list requirements and say nothing about whether the list is exhaustive or illustrative, which is the single most consequential ambiguity in the document and the one worth one email.

The practical consequence: read the brief twice, once for the deliverable and once for what it declines to say. Every silence is a decision handed to you, and the decisions handed to you are the assessment.

The grading rubric for a code submission

This is what a hiring manager reads, roughly in this order, with roughly this weighting. It is not a scorecard any single company publishes, but the criteria recur across enough organisations that treating them as the rubric is more accurate than treating the brief as the rubric.

The order matters as much as the contents. A reviewer who cannot run your submission in five minutes has already formed a view, and that view colours the code reading that follows. Everything downstream of "it did not start" is read uncharitably.

Does it run from the README as written

This is the highest-leverage twenty minutes you will spend and the one most commonly skipped. The test is not whether it runs on your machine. It is whether it runs following your own instructions, in order, on a machine that has never seen the project.

Do it literally. Clone into a fresh directory. Follow your own README line by line without using anything you know and did not write down. If you have a container runtime, run it in a clean container. Every candidate believes their instructions are complete and a meaningful proportion of submissions fail on the first command, usually for one of four reasons: a language or runtime version that is not stated, a dependency installed globally on the author's machine years ago, an environment variable or config file that exists locally and is gitignored, or a database or service assumed to be running.

State the versions you developed against. Not because the reviewer will match them, but because when it fails on their machine the version line converts a rejection into a shrug. A reviewer who reads "developed on Node 22.x; the date handling assumes a version with Temporal available" knows immediately what happened and will retry. A reviewer who sees an opaque stack trace and no version information stops.

If your project genuinely needs something awkward, say so at the top and give the reviewer a way around it. "This needs Docker because the integration tests use a real Postgres. If you would rather not, npm test:unit runs the unit suite with no external dependencies and covers the parsing logic." That sentence is worth more than an extra feature.

Is the commit history legible

Most candidates treat git as a delivery mechanism. Reviewers treat it as a window into how you work, and it is the one part of a submission that cannot be produced by a last-minute tidy-up. A single squashed commit tells the reviewer nothing, which is a wasted opportunity rather than a penalty. Forty commits of "wip" is worse, because it shows what a week of your commits would look like on their repository.

What good looks like is unglamorous: a handful of commits, each one a coherent step, each message saying what changed and why anybody should care. The why is the part that scores. A message that restates the diff is redundant with the diff.

Parse dates with an explicit timezone rather than the system default

The sample file has timestamps with no offset. Treating them as local
time made the daily aggregation shift by a day for anyone running this
outside UTC, which the tests caught only because CI runs in UTC.

Assuming UTC is a guess. Flagged in README under Open Questions -
if these files come from regional systems the right answer is probably
a per-source timezone config, which is a product decision.

That message does four things a reviewer notices. It states the change, states the consequence of the alternative, admits the assumption is a guess, and points at where the guess is recorded. It also demonstrates that the candidate found a real subtlety in a boring CSV file, which is the actual signal the exercise was fishing for.

You do not need many of these. One or two commits with reasoning in them, among a set of otherwise ordinary messages, is enough to establish the habit. What you must avoid is a history that implies you wrote the whole thing in one sitting with no thinking in between, because that is what a candidate who copied a solution produces.

Are the tests testing behaviour or coverage

Tests are the fastest read on a candidate's engineering maturity, and the read is not "how many". It is "what did they choose to test, and do the test names describe behaviour or implementation".

A test named testProcessFileReturnsNotNull tells the reviewer the candidate writes tests because tests are expected. A test named rejects a row whose quantity is negative rather than silently coercing it to zero tells them the candidate thought about what could go wrong and cared about which wrong thing happened. The second name is also documentation, which matters on a submission where the reviewer has twenty minutes.

Coverage is a trap on an exercise specifically because it is easy to game and reviewers know it. A submission with ninety per cent coverage achieved by exercising every accessor is scored below one with sixty per cent coverage concentrated on the parsing, the boundary conditions and the one calculation that could plausibly be wrong. The argument for why is the argument in what ninety per cent coverage does not tell you, and it is worth being able to make it out loud in the playback, because "why did you not test the controller" is a standard question and the strong answer is a choice rather than an apology.

Be explicit about the shape you chose. One line in the README beats any number of tests: "Tested the row validation and the aggregation arithmetic thoroughly, since those are where a defect would be silent. The HTTP layer has one smoke test; in a real service that boundary would be covered by an integration suite against a running instance, which I judged out of scope for four hours." That sentence answers the question before it is asked and demonstrates the reasoning behind deciding what to automate rather than asserting a rule.

The failure that reads worst is no tests at all with no explanation. No tests with an explanation is survivable in some contexts and fatal in others, and the explanation has to be a trade-off rather than an omission: "I spent the time on the aggregation edge cases and covered them with tests; I have not tested the CLI argument parsing, which I would do before this shipped."

Is the scope disciplined or gold-plated

More on this below, because it deserves its own section, but stated here as a rubric line: the reviewer is checking whether you built the brief or whether you built the brief plus a demonstration of your range. The second is scored down. Consistently, deliberately, and by reviewers who will not tell you that is what happened.

Are the trade-offs written down

A submission with no recorded decisions is a submission the reviewer has to reverse-engineer, and reverse-engineering under time pressure produces uncharitable conclusions. Every choice you made silently is a choice the reviewer may read as ignorance.

Three to six real decisions is the right volume. A real decision has an alternative that a reasonable person would have chosen, and a reason for going the other way that refers to something specific in the brief. "Used a plain map instead of a database because the brief mentioned one file and no persistence requirement, and a real store would have added setup cost to your review with no benefit to the assessment" is a real decision. "Chose clean architecture for maintainability" is not a decision, it is a slogan, and reviewers discount slogans hard.

The habit this is testing is the one behind what belongs in an ADR and when to write one: recording the reasoning at the moment it is cheap, so that somebody who arrives later can tell a considered choice from an accident. On an exercise, the somebody who arrives later is arriving in twenty minutes and deciding whether to interview you again.

Is there a decision you declined to make and said so

This is the criterion nobody expects and the one that most reliably separates a senior submission from a competent one. Somewhere in the brief there is a question that cannot be answered by an engineer working alone, because it is a product question, a business question, or a question about data that only the company has. The strong move is to notice it, make the smallest reversible choice that lets you keep going, and write down that you have not decided it.

"The brief says duplicate records should be handled but not what counts as a duplicate. I have matched on the reference plus the date, which is the conservative reading. If the reference is globally unique this is over-strict and will drop legitimate rows; if regional systems reuse references it is under-strict. I have not decided this because it is a data question I would ask the owner of the upstream system, and I would want the answer before this ran on real volumes."

That paragraph takes ninety seconds to write and does something no amount of code does. It shows you can distinguish a decision that is yours from a decision that is not, which is exactly the judgement that determines whether a new senior hire creates problems for their first six months. It also protects you: a reviewer who disagrees with your handling now disagrees with a named assumption rather than with your competence.

The failure mode is deciding it silently and confidently. A reviewer who spots an arbitrary product decision made without comment records it as a bug, not as a choice, and there is no way to recover that in a playback session because the artefact says what it says.

Scope discipline, and why candidates get it backwards

The most-graded criterion on a take-home is the one candidates most consistently misunderstand, and the misunderstanding is encouraged by almost every article written on the subject. The advice is "go the extra mile", "show your range", "make it stand out". Applied to a take-home, that advice loses processes.

Doing more than asked is scored down. Not always, not by everybody, but the base rate is strongly negative, and understanding why makes it obvious rather than arbitrary.

Start from what the reviewer is imagining while they read. They are not imagining a competition. They are imagining you on their team, receiving a ticket. If the ticket says "add a filter to the report endpoint" and you deliver a filter plus a caching layer plus a refactor of the serialisation plus a new config system, you have created a review that takes four times as long, a change that is four times as risky, and a conversation with the product owner about why a two-day story took a week. Every senior engineer has worked with that person. Nobody wants to hire them.

Then look at the mechanics of the assessment. A brief that says four hours has been calibrated so that a competent candidate can complete it in four hours. If you spend sixteen, you have not demonstrated more capability, you have demonstrated that your output at four hours is unknown and your estimate of your own throughput is out by four times. That second thing is a real negative signal, because estimation is a job requirement and the exercise just measured yours.

Then the fairness problem, which reviewers are increasingly explicit about. A candidate with a free weekend beats a candidate with two children and a full-time job, on effort rather than on ability, and organisations that notice this correct for it by scoring against the brief rather than against the field. In those processes, extra work is not merely unrewarded, it is penalised as a failure to respect a stated constraint.

And finally the signal that gold-plating actively sends. Building an authentication layer nobody asked for is not evidence you can build authentication. It is evidence you cannot tell what matters, or that you were more interested in showing off your range than in solving the customer's problem. Reviewers phrase this in debriefs as "did not read the brief" or "I am not sure they know what the priority was", and both are hard to come back from.

Note the last row, because "production quality" is the phrase that causes the most damage. It does not mean "everything a production system has". It means "not the shape of code you would be embarrassed to show a colleague". Reviewers who write it are asking for care, not for infrastructure.

What to do with the ideas you are not building

The resolution is not to have fewer ideas. It is to move them out of the code and into the prose, where they cost the reviewer thirty seconds instead of thirty minutes and where they demonstrate the same range without the scope damage.

A short section at the end of the README does the whole job:

## What I would do next, and why not now

- **Persistence.** In memory today. The brief specified a single file and no
  durability requirement, so a database would have added setup cost to your
  review and nothing to the assessment. The store is behind one interface,
  so swapping it is a contained change.
- **Concurrency.** Single-threaded ingest. At the stated file sizes this is
  fine; past roughly a few hundred megabytes I would chunk the read and
  parallelise per chunk, and the aggregation is associative so that is safe.
- **Auth.** Not present. Not in the brief, and adding it would have implied
  a threat model I have not been given.

## Open questions I would have asked

1. Is the requirement list exhaustive or illustrative?
2. What counts as a duplicate record - see the note in `ingest/dedupe.js`.
3. Are these files ever regional, i.e. do the timestamps need per-source
   timezones? I have assumed UTC and the assumption is load-bearing.

This is worth more than any of the three features it declines to build. It shows you thought about scale without pretending you needed it, and it converts the reviewer's private questions into a conversation you have already opened. The judgement it demonstrates is the same one being tested when a candidate is asked about splitting a story that is too big: knowing which slice delivers the value and which parts can wait is a skill, and here you are performing it on your own work.

There is one exception worth stating honestly, because a blanket rule would be wrong. If the brief explicitly invites extension — "add anything you think would improve it", "we are interested in what you choose to do beyond the requirements" — then it means it, and building nothing extra is a miss. The tell is whether the brief opens the door. If it does not, it is closed.

The README and the covering note

Per word, the written material is the highest-weighted part of your submission, and it is the part candidates write last, tired, at midnight. Reversing that order is close to a free upgrade.

Two documents do different jobs. The README lives in the repository and is written for a reviewer who has just cloned it. The covering note goes in the email or pull-request description and is written for the hiring manager who may not clone it at all. Some processes only ever read the second one.

What the README has to do, in order

The first screen has to answer three questions without scrolling: what is this, how do I run it, how do I run the tests. If a reviewer has to scroll to find the run command, the README has failed at its primary job regardless of how good the rest is.

After that, in descending order of value: the decisions you made and why; what you deliberately left out; the open questions you would have asked; and a brief map of the code if the structure is not obvious from the directory names.

What does not belong: a restatement of the brief, an explanation of what CSV is, a paragraph about your enthusiasm for the role, and any framework-generated boilerplate. Delete the generated README. A reviewer who opens a project and finds "Getting Started with Create React App" has learnt something about your attention to detail.

Length: one screen of essentials, then as much as the decisions genuinely need, usually a page in total. A five-page README on a four-hour exercise is its own kind of scope failure.

The covering note

This is three to six sentences in the body of an email, and it is read by the person deciding whether to spend twenty minutes on your repository. Its job is to set the frame in which everything else is read.

Hello Priya,

The exercise is at github.com/example/ingest-exercise, and it runs with docker compose up or npm start if you have Node 22 locally. Instructions and the test command are at the top of the README.

I kept to the stated scope and spent the time on the ingest path, since that is where the brief implied the data would be messiest. Two things I would flag: I have assumed UTC timestamps and I think that is a real question rather than a detail, and I have left persistence in memory deliberately. Both are written up in the README along with the other decisions.

I took a little under five hours. If you would rather I had stopped at four, the last thing I added was the duplicate handling and it is a single commit you can ignore.

Happy to walk through any of it.

Look at what that note does. It gives the run command in the first line, so a reviewer who reads nothing else can still start. It names the scope choice explicitly, which pre-empts the "why no database" question. It surfaces the assumption that could otherwise be read as a bug. It reports the time honestly and makes the overrun auditable. And it is short enough to be read on a phone.

The three failure modes to avoid are all tonal. Apologising ("sorry it's a bit rough, I ran out of time") invites the reviewer to look for roughness. Overselling ("I've implemented a fully production-ready, scalable solution") sets a bar your four-hour exercise cannot clear and makes every gap a broken promise. And pre-emptive defensiveness ("I know some people would have used a database but I disagree with that approach") turns a decision into a position, and positions invite attack.

Why the writing carries the weight

Two reasons, one about the reviewer and one about the job.

The reviewer is time-boxed and reading several submissions. Prose is skimmable and code is not, so the prose is what actually gets consumed. If your reasoning exists only in the code, the reviewer has to infer it, and inference under time pressure is unreliable and unflattering. Writing it down is not a courtesy, it is the difference between being credited for a decision and being suspected of an accident.

The job reason is more direct. Every senior technical role is substantially a writing role. Design documents, incident write-ups, decision records, pull-request descriptions, the messages that let a distributed team function. A candidate who writes a clear, honest, well-ordered page about their own work has demonstrated that capability on real evidence, and there is no other stage in the loop that does. This is the same reason keeping architecture documentation from going stale is a question worth asking at all: the writing is the artefact that outlives the work.

The grading rubric for a deck or written case

Non-code exercises are graded on argument structure, and the criteria are as specific as the code ones. The failure that dominates is the same in almost every weak submission: the candidate presents their analysis in the order they did it, rather than in the order the decision needs.

Is the recommendation in the first minute

This is the most reliable single discriminator on a case submission. Put the answer first.

The reason is not impatience. It is that a reader who knows your conclusion can evaluate your evidence, and a reader who does not is just absorbing facts with no frame to hang them on. Withholding the recommendation for dramatic effect actively degrades the reader's ability to follow the argument, and it also signals that you have not made up your mind, or that you are hedging so you can adapt to the room's reaction. Both are read.

Concretely: the first page or the first slide states what you recommend, in one sentence, with the two or three reasons compressed into a clause each. Everything after that is support. If your exercise has an executive summary slot, that is where it goes; if it does not, make one.

The strong form names the decision and the confidence together. "I would launch in the mid-market segment first rather than enterprise, mainly because the sales cycle fits the runway and the integration surface is smaller. I hold this fairly firmly on the runway argument and less firmly on the integration one, because I had to estimate the integration work from the product pages."

Is the structure an argument or a tour

A tour has this shape: here is the context, here is the data I was given, here is what I did with it, here are some things I noticed, here are some options, here is what I think. It is chronological, and chronology is the order of your work rather than the order of the decision.

An argument has this shape: here is what I recommend, here is the reasoning in the order that makes it convincing, here is what would have to be true for me to be wrong, here is what I would do next. Each section exists because the argument needs it, and a section that supports nothing gets cut.

The test to run on your own draft: take each slide or section and ask what claim it supports. If the answer is "it shows the work I did", cut it or move it to an appendix. Reviewers explicitly notice appendices, favourably, because an appendix is evidence you distinguished between what supports the argument and what merely demonstrates effort.

Are the assumptions stated and falsifiable

Every case answer rests on assumptions because every case brief is missing data. Stating them is table stakes. The graded quality is whether they are the kind of statement that could be checked.

"I assume the market is growing" is not falsifiable in any useful sense, and it does no work in the argument. "I assume the addressable market is roughly the two hundred thousand UK businesses in the size band the product is priced for, which I have taken from the pricing page rather than from any market data, and which is the number I would want to verify first" is falsifiable, sourced, and flagged as fragile. The second version also tells the reviewer where to push, which is a confident thing to do.

Number them. A numbered assumptions list is the single easiest structural upgrade to a case submission, because it gives the reviewer somewhere to aim their questions and it makes your reasoning auditable. It also makes the playback session easier: when somebody challenges a conclusion, you can ask which assumption they are disputing, which turns an argument about your judgement into a conversation about a fact.

Do you know which number moves the decision

This is the criterion that separates a competent case from a strong one, and it is rarely explicit in the brief.

Most case answers depend on several quantities, and they do not matter equally. Usually one or two dominate, in the sense that a plausible change in them flips the recommendation, while the rest could be wrong by half and the answer would hold. A candidate who has identified which is which has done the analysis. A candidate who presents twelve numbers with equal weight has done arithmetic.

Say it out loud in the submission. "The recommendation is not sensitive to the churn estimate; even at double my figure the answer is the same. It is very sensitive to how long enterprise procurement takes, because at nine months the runway does not reach the second cohort. If I could verify one number before committing, it would be that one."

That paragraph is what a hiring manager means when they say they are looking for commercial judgement. It is also what makes a case like choosing between two segments with the same revenue answerable at all, since the revenue figure is deliberately neutralised and the decision has to turn on something else.

The page limit is part of the exercise

If the brief says two pages or ten slides, that is a constraint and constraints are assessed. Going over is not enthusiasm, it is a failure to prioritise, performed on the one artefact whose entire purpose is to demonstrate prioritisation.

If you genuinely cannot fit it, that is information about your argument rather than about the limit. Almost always the fix is that you are including analysis that supports no claim. Cut it or appendix it. And if you use an appendix, say so on the last in-scope page: "Appendix A holds the segment arithmetic; Appendix B is the interview notes. Neither is needed to follow the recommendation."

Time boxes, and what to do when the work does not fit

The stated time box is the most contested part of any take-home, and there are three distinct situations behind the words "I could not do this in four hours". Telling them apart is the whole skill.

The box is honest and you are slower than the calibration. This happens, particularly with unfamiliar tooling, and it is worth knowing rather than hiding. The response is to build the highest-value subset within the box and say what you did not reach.

The box is honest and the scope is genuinely bigger than the calibration. Also common, usually because the brief was written by somebody who already had the domain in their head. Everybody who takes this exercise overruns, and the reviewers know it and have adjusted their expectations informally without updating the brief.

The box is not honest. The brief says four hours and describes two days of work. This is either carelessness or a deliberate filter for people who will overwork, and either way the correct response is to say so before you start.

The critical point, and the one that changes outcomes: what you do about the mismatch is graded, and it is graded more heavily than the extra features you would have built with the extra time. A candidate who spends the stated four hours, submits an incomplete thing, and explains precisely what they prioritised and what they cut is scoring on judgement, honesty and estimation simultaneously. A candidate who spends fourteen hours and submits something complete is scoring on none of those, and has additionally told the reviewer that a stated constraint does not bind them.

The three ways to handle it, in order of preference

Ask before you start. One email, sent the day you receive the brief. This is the strongest move because it is the only one available before you have sunk time, and because the answer materially changes what you do. The words are in the pushback section below.

Time-box hard and report. Set a timer, stop when it goes off, spend the last twenty minutes on the README and the note. Then be exact about what happened.

I stopped at four hours as asked. What is there: the ingest pipeline, validation, the aggregation and the query endpoint, with tests on the parsing and the arithmetic. What is not there: the CSV export, and error handling beyond validation failures. I prioritised the ingest path because the brief said the files are inconsistent, which told me that was where the difficulty was and where a defect would be worst.

The export is maybe an hour, and I have left a stub with a note on how I would do it. If you would like me to finish it, say and I will.

That final offer is worth including. It costs you nothing, it signals willingness without capitulation, and in a surprising number of processes the reviewer says no because they have what they need.

Overrun and declare it. Sometimes you will judge, correctly, that the process rewards completeness and you would rather submit a finished thing. That is a legitimate choice, and if you make it, declare the real number. "This took me about seven hours rather than four; I have said so because you should know what you are looking at, and because I would rather you knew than assumed I am four-hour fast." Reviewers respect the honesty and mildly discount the work. Undeclared overruns are the worst option, because they are frequently detectable from commit timestamps and being caught converts a scope question into an honesty question.

The special case of the invisible time box

Some briefs give no time guidance at all. This is not an invitation to spend a week. It is either an oversight or a test, and in both cases the response is the same: ask, and if you get no useful answer, set your own, state it, and hold it.

The brief does not mention how long you expect this to take. I am planning to spend about four hours and to prioritise the ingest path over the export if I have to choose. Does that match what you had in mind, or would you rather I went further in one direction?

An unanswered version of that email still helps you, because you have documented your own constraint before starting and can hold yourself to it without wondering.

The playback session

The playback, walkthrough or presentation is where most decisions are actually made, and where the largest number of candidates with good submissions lose. The submission gets you into the room; the session decides.

The core misunderstanding is that the session is a presentation of your work. It is a simulation of a design review, and design reviews are interrupted, sceptical and time-limited. Prepare for the interruption rather than for the presentation.

flowchart LR
  accDescr: The playback shape, running from the recommendation or what you built, through the constraint you worked under, showing the thing working, and trade-offs and what you left out, to what you would do next, with a loop back where a challenge to one of your choices means restating the basis and then holding or conceding before returning to the trade-offs.
  REC[Recommendation or what you built] --> CONS[Constraint you worked under]
  CONS --> DEM[Show the thing working]
  DEM --> TRADE[Trade-offs and what you left out]
  TRADE --> NEXT[What you would do next]
  TRADE -->|challenged on a choice| DEF[Restate the basis then hold or concede]
  DEF --> TRADE

The edge that loops back is where the session is won or lost, and it is the part candidates never rehearse: being pushed on a choice, and returning to your thread afterwards rather than abandoning it.

Structure that survives interruption

Assume you have half the time you were given, because you probably do once questions start. That means the first three minutes have to carry the whole thing.

Open by saying what you built or what you recommend, and what constraint you worked under. Twenty seconds. "I built the ingest and query path from the brief, in about four hours, and I chose to go deep on the messy-data handling rather than wide across all four endpoints. Happy to go anywhere you want, but if you let me pick I would show you the validation and then talk about two decisions I am not sure about."

Then show the thing working, briefly. On a code exercise, run it. Actually run it, live, on the smallest realistic input. A reviewer who watches your submission work has a different relationship to it for the rest of the hour. On a case, walk the recommendation and the two reasons.

Then the trade-offs, which is where you want to spend the most time, because it is where the marks are. Do not wait to be asked.

Then what you would do next, kept short, because it is the least interesting part to the panel and the part candidates over-invest in.

Two mechanical habits carry disproportionate weight. Narrate intent before action: "I am going to run the ingest against the file with the broken rows, because that is where the interesting behaviour is." A narrated walkthrough survives something going wrong on screen. And know which ninety seconds of your material is load-bearing, because when you lose half the time you will have to choose, and the panel watches what you keep.

Handling interruption

Interruptions are the assessment, not an obstruction to it. A candidate who visibly resents being interrupted has told the panel what a design review with them is like.

Take the question when it lands rather than deferring it, unless deferring is genuinely better, in which case say why and commit to a moment. "That is the persistence question and it is the most interesting thing here. Can I show you this one behaviour first, ninety seconds, and then take it properly?" Then actually take it. A deferred question you never return to is a worse outcome than an interrupted thread.

Answer the question asked. Under pressure candidates answer a nearby question they are better prepared for, and experienced interviewers notice immediately, because they asked a specific thing and got a rehearsed thing. If you do not understand the question, say so and ask them to put it differently. That is not weakness; it is what the same person would want from a colleague in a review.

And come back to your thread. "That was the persistence one. Where I was going was the validation, which is the other decision I wanted to flag." Reviewers score whether you kept control of the session, and picking up a dropped thread is the visible evidence of it.

Being challenged on a choice

This is the set piece. Somebody will say "why did you do it that way" about something you chose deliberately, or something you chose carelessly, and the two need different answers.

Where you chose deliberately, restate the basis rather than the conclusion. "I used an in-memory store because the brief specified one file and no durability requirement, and I judged that a database would cost you setup time in review without telling you anything more about how I work." That is a defence that refers to evidence. Then ask what they are worried about, because the challenge usually has a specific concern behind it and answering the concern beats defending the choice: "Is the worry about the volumes, or about whether I would reach for the right thing on a real service?"

Where you were wrong, concede quickly and specifically. This is the counterintuitive part: a clean concession scores well. "You are right, that is a race and I did not see it. If two ingests overlap, the aggregate is wrong and it fails silently, which is the worst kind. The fix is to make the accumulate step atomic; I would want a test that runs two ingests concurrently and asserts the total, and I do not think that is more than half an hour." That answer is better than a successful defence, because it demonstrates that you can receive a correction and turn it into a plan, which is the behaviour the whole loop is trying to predict and the same thing being probed by the hardest feedback you have received.

What fails is either extreme. Defending an indefensible choice tells the panel you will do that in code review. Immediately abandoning a defensible one tells them you will not hold a position under pressure, and a senior engineer who folds whenever challenged cannot be trusted with a decision. Panels sometimes push on a choice that is correct precisely to see which way you go.

When somebody finds a bug live

They will, in a meaningful fraction of sessions, and sometimes on purpose. The next thirty seconds is graded more heavily than the bug.

Acknowledge it plainly, before doing anything else. "That is a bug. Let me look at what is happening." Silence while you scroll is what almost everybody does, and it converts a small technical problem into a credibility problem, because the room watches you avoid the subject.

Then work out which of three things it is, out loud, because the classification is the interesting part. Is it a defect, meaning the code is wrong and you would fix it. Is it a stated limitation, meaning you knew and wrote it down, in which case point at where you wrote it down. Or is it a difference in expectations, meaning it does what you intended and you intended something they disagree with, which is a design conversation and not a bug at all.

Then say what you would do, at the right granularity. "It is a defect. The validation runs before the trim, so a field with trailing whitespace fails a check it should pass. One-line fix and a test with a padded field." If you can fix it live in under a minute and the format allows, offer to. If not, do not start, because a candidate debugging live for six minutes has lost the session to something small.

The one thing not to do is minimise it. "That would not happen in practice" is heard as an unwillingness to own a defect, even when it is true, and the true version is available without the defensiveness: "It is real and I would fix it. It needs a file with trailing whitespace in that column, which I would guess is uncommon but not impossible, so I would put it behind the validation fix rather than at the top of the list."

The questions you have not prepared for

Every playback contains at least one of the following, and each catches candidates who prepared only their own material. Full answers appear under ## Questions below, but the categories are worth knowing in advance: what you would delete, what took the longest, what you would do differently with the same time again, what you have not tested, and what you disagreed with in the brief.

Those five questions have something in common. None of them is about what you built. They are all about your relationship to your own work, and that is what the session is measuring.

The live case study

A live case is an hour with an interviewer, a problem, and no preparation time. It is a different instrument from a take-home and rewards different behaviour, and treating it like a compressed take-home is the standard error.

What it grades that the async version cannot: how you behave when you do not yet know the answer. An async submission shows a destination. A live case shows the route, including the wrong turns, and the route is more predictive of what you will be like to work with.

Thinking aloud, properly

"Think aloud" is the universal advice and it is under-specified, because there is a version of thinking aloud that scores badly. Narrating every passing thought produces noise, and an interviewer cannot tell a considered path from a random walk if they hear both at the same volume.

What works is narrating structure rather than content. Say what you are about to do and why, do it, then say what you concluded. "I want to size this before I choose an approach, because if the volume is small the whole design question goes away. So first, roughly how many events a day are we talking about." That is three sentences and it lets the interviewer follow, contribute, and grade your reasoning rather than your output.

Announce the map before walking it. "There are three things I need to get right here: how the data gets in, how it is stored, and what happens when a source is late. I think the third one is where the difficulty is, so I want to do the first two quickly and spend the time there. Does that match how you see it?" That single move does more for a live case than any amount of technical depth, because it shows you can decompose a problem and allocate attention, and it invites a correction while a correction is still cheap.

And say when you change your mind, explicitly. "I said file-based ingest a minute ago. Given the late-arrival requirement I think that was wrong, because reprocessing a whole file to fix one record is expensive. I would rather take these as individual events." Interviewers score visible self-correction highly. It is very hard to fake and it is exactly what they want from a colleague.

Using the interviewer as a resource

The single largest difference between a strong and a weak live case is whether the candidate treats the interviewer as an examiner or as a colleague with information.

They have information you need. They know the constraints they left out, they know which part of the problem they consider interesting, and they usually know the answer they had in mind. Almost all of that is available for the asking, and asking is scored positively in every well-run live case because checking a constraint before building on it is the behaviour they are hiring for.

What to ask, and roughly when. At the start: what the scale is, what is in scope, what they would like you to spend the time on. Mid-way: whether an assumption you are about to build on is safe, and whether you are going somewhere useful. Near the end: whether there is an area they wanted to cover that you have not reached.

Before I go further, I have been assuming these files arrive once a day and are complete when they arrive. If they trickle in, or if a later file corrects an earlier one, that changes the design quite a lot. Which is closer to the truth?

I have spent about fifteen minutes on the ingest side. I could keep going deeper there or move to the query side. Which is more useful to you?

The second one is worth internalising. It is polite, it costs ten seconds, and it prevents the commonest way to fail a live case, which is spending forty minutes on the part the interviewer did not care about and never reaching the part they did. Interviewers almost always answer it honestly.

What not to do is ask them to make your decisions. "What would you do here?" hands the problem back and is read as an inability to commit. The distinction is between asking for facts, which is collaboration, and asking for judgement, which is abdication.

A confident wrong answer against a reasoned uncertain one

This comparison decides more live cases than technical knowledge, and the scoring is not close.

A confident wrong answer is one delivered without qualification, on a shaky basis, with no signal that the candidate knows it might be wrong. It fails badly, and not primarily because it is wrong. It fails because it is unmarked. An interviewer hearing it learns that this candidate's assertions do not carry reliability information, which means every future statement from them has to be independently verified. That is expensive in a colleague and disqualifying in a senior one.

A reasoned uncertain answer states a position, states what it rests on, and states how sure it is. "I would go with the queue rather than direct writes. I am fairly confident about that if the write volume is spiky, less confident if it is smooth, and the thing I would check first is the peak-to-average ratio, because if it is close to one the queue is complexity for nothing." That is a decision, not a hedge, and the uncertainty is attached to a specific quantity you could go and measure.

The failure mode on the other side is real and should be named, because "express uncertainty" gets over-applied. A candidate who qualifies everything, commits to nothing, and answers every question with a list of options has also failed, and failed on a dimension that is harder to fix. Uncertainty has to be attached to something specific and has to resolve into a decision. "It depends" is only an answer when you then say what it depends on and what you would do under each branch, and then say which branch you would bet on.

The formula that works: commit, name the basis, name the condition that would change it, then stop.

When you are properly stuck

You will be. What is graded is the recovery, not the sticking.

Say you are stuck rather than performing progress. "I am going round in circles on the ordering guarantee. Let me say what I think I know and where the gap is." Then do exactly that, out loud, because narrating the boundary of your knowledge frequently locates the missing piece and, when it does not, gives the interviewer somewhere to help.

Then reduce the problem. Solve a smaller version, or a version with one constraint removed, and say that is what you are doing. "Let me do this assuming a single source first, get that right, and then add the multi-source case back." Interviewers reliably score this well because it is what senior engineers do, and because it produces something rather than nothing.

And accept the hint. If an interviewer offers a direction, take it, and say you are taking it. Refusing help to prove independence is read as ego, and the person offering is trying to get you to the interesting part of the problem before the hour runs out.

Where the line is between a fair exercise and free work

This is the part of the subject where advice tends to become either compliant or polemical, and neither is useful to somebody holding a brief at nine on a Friday evening deciding whether to spend their weekend. So: a fair exercise genuinely exists, exploitative ones genuinely exist, and there are five tests that separate them.

Length. Somewhere around four hours, unpaid, is where most people's sense of proportion sits for a mid-to-senior role, and the number that matters is your total across the process rather than the number in the brief. A three-hour exercise on top of four interviews is a different ask from a three-hour exercise instead of two of them. Past roughly a day of unpaid work, the exercise has stopped being a screening instrument and started being a labour transfer, whatever it is called.

Whether it is on the company's real product or roadmap. This is the sharpest test and the easiest to apply. A synthetic problem, or a real problem abstracted enough that the output has no value to them, is an assessment. A brief that hands you their actual data, their actual codebase, an unbuilt feature from their actual roadmap, or a live customer problem, is asking you to do work. The tell is often specificity: generic briefs are reused across candidates, and a brief that has clearly been written for their situation this quarter probably has a use for the answer.

Whether it will be used. Related but distinct, and you are allowed to ask. If your deck would be genuinely useful to them regardless of whether they hire you, that is a commercial transaction with the price set at zero. Design, content, data and strategy roles are where this bites hardest, because the deliverable in those disciplines is directly usable in a way that a CSV parser is not.

Whether it is paid. Paying for candidate time is the clean solution to all of the above and some companies do it. It is not a requirement for an exercise to be fair, and treating payment as the only acceptable arrangement will remove you from a lot of reasonable processes. But an unusually long exercise that is unpaid, on real work, is three signals pointing the same way.

Whether the same is asked of everyone. An exercise applied to every candidate at a level is a process. An exercise applied to you specifically, when the referred candidate skipped it, is a signal about how you are being read, and it is a fair thing to ask about. The answer also tells you something about how consistently the organisation makes decisions.

Two honest caveats before the scripts. First, most exercises you receive will sit in the left column, and reading exploitation into a standard four-hour coding problem will cost you good processes and reputation. Second, some pushback will lose you the process even when the pushback was correct, because some hiring managers read any negotiation as difficulty. You cannot get the benefit of the question without accepting that risk. What you can do is ask in a way that maximises the chance of a good answer, which is what the next section is for.

Pushing back, in the actual words

Every script below is written to be sent or said roughly as written. They share a shape, and the shape is the point: state that you intend to do the exercise, ask one specific question, propose a concrete alternative, and leave the decision with them. A pushback with no proposal attached is a complaint; a pushback with a proposal is a negotiation, and negotiations get answers.

Send them to the recruiter unless you have a direct line to the hiring manager, and send them the day you get the brief rather than the day before the deadline.

Asking what the time box really is

The most useful message in this whole guide, and the least risky. Almost nobody sends it.

Thanks for this, it looks like an interesting problem and I am happy to do it.

One question before I start. The brief suggests four hours, and reading it through I think the ingest, the validation and the query endpoint is about that, with the export and the error handling on top. Would you rather I kept to the four hours and stopped where I stop, or spent longer and covered all of it? I would rather ask than guess, since it changes what I prioritise.

Also, is there a part of it you care most about? If the messy-data handling is the interesting bit for you I would spend my time there rather than spreading it evenly.

Why this works. It opens with commitment, so nothing that follows reads as reluctance. It demonstrates that you have decomposed the brief and formed an estimate, which is a competence signal delivered for free. It gives them a binary rather than an open question, and binaries get answered. And the second paragraph is a gift to you regardless of the answer, because "we mainly care about X" collapses your scope problem entirely.

The answer is also diagnostic. A hiring manager who says "four hours, and we care most about how you handle the broken rows" has told you they designed the exercise deliberately. "Take as long as you need, we want to see your best work" means the box is not real and the exercise is a completeness competition, which is information you can act on. Silence for four days means the process is disorganised, which is worth knowing before you spend a weekend on it.

Proposing a smaller scope

Use this when the mismatch is large enough that no prioritisation inside the box produces something coherent.

Happy to do this. Before I start I want to flag a scope question, because I think the brief is bigger than the four hours.

As written it is four endpoints, the ingest pipeline, the validation rules and a deployment setup. My honest estimate is a couple of days to do all of that at a standard I would be willing to show you.

What I would propose instead is the ingest and one endpoint, done properly, with tests and a written note on how I would approach the rest. That is four hours and I think it shows you more than a thin version of everything would. If you would rather have the full breadth I will do that, but I wanted to raise it rather than quietly deliver a quarter of it.

The estimate is the load-bearing part. "This is too much work" is an opinion. "This is two days, here is the four-hour version I would build instead, here is why that version tells you more" is professional judgement with a proposal attached, and it is exactly the conversation you would have with a product owner about a sprint commitment. The instinct being demonstrated is the one behind being handed far more work than you could deliver, and demonstrating it live is worth more than describing it in a behavioural round.

Do not apologise, do not use "unfortunately", and do not attach a grievance. The moment the message contains a complaint about the industry it stops being a scoping conversation.

Asking whether the work will be used commercially

Reserve this for briefs that are on real work. Asking it about a synthetic exercise reads as suspicion of a process that has done nothing to earn it.

One thing before I start, and I hope it is a straightforward question. The brief is quite specific to your product and roadmap, which is genuinely more interesting than a generic exercise. Can I check that the output is only used for assessment and not something the team would take forward? Happy either way, I would just want to know which conversation we are having, since if it is work you would use I would rather we treated it as a paid piece.

The construction that makes this askable is complimenting the specificity first, so the question lands as clarification rather than accusation. And "which conversation we are having" is a useful phrase because it frames two legitimate options rather than an allegation.

Read the answer carefully. A confident "no, we throw them all away, and we do not keep them after the decision" is the answer a normal company gives in one line without thinking about it. Hedging, a long explanation of how they could not possibly use it, or irritation at being asked, all tell you something. So does an honest "actually yes, and we should pay you for it", which happens and is a good sign about the organisation.

Asking to be paid

Ask when the exercise is long, on real work, or both. Frame it as a norm rather than as a personal demand, and make the yes easy.

This looks like a solid piece of work, probably a day given the data cleaning. I am up for it, and for something at that length I would want it to be paid at my normal day rate. I appreciate that may not be something you do, so two alternatives if not.

I could do a three-hour version scoped down to the ingest and one analysis, which I would be happy to do unpaid. Or I could walk you through a similar piece of work I have already done, in as much detail as you want to go, including the parts that went wrong.

Any of the three works for me. Which is easiest for you?

Three properties make this land. It is specific about what triggers the request, which is length rather than principle. It offers two unpaid alternatives, so the answer is not yes or nothing. And it closes with a question that assumes the process continues.

Expect no more often than yes. Many organisations have no mechanism to pay a candidate and the person you are asking cannot create one, so a no is frequently about procurement rather than about respect. What matters is how the no arrives. "We are not set up to do that, but the scaled-down version works for us" is a company behaving well. Offence at the question is the answer, and it is a useful one.

Requesting an alternative format

This is the highest-yield pushback and the least used, because it gives them what they want by another route. You are not refusing assessment, you are offering more of it.

I would like to keep going with this and I want to be straightforward about the take-home. I have two other processes running alongside a full-time job, and I do not think I can give a weekend exercise the attention it deserves right now.

What I would offer instead, and I think it would tell you more. Either a ninety-minute session where we work a problem together, live, with you asking whatever you want as I go, which I would honestly prefer because it is closer to the job. Or a walkthrough of a project I have already built, where I take you through the code, the decisions, what I got wrong and what I would change. I can send the repository in advance so you can read it cold, which gives you the same artefact the take-home would have given you.

Both are open to whatever depth you want to go. Would either work?

The reason this succeeds so often is that it addresses the hiring manager's real requirement, which is evidence, rather than their stated requirement, which is a submission. A paired session gives them more signal per hour than a take-home does. Some managers prefer it and have simply never been asked.

One warning: a portfolio walkthrough only works if you have something to walk through and are prepared to be interrogated on it properly. Offering it and then presenting a shallow tour of a tutorial project is worse than doing the take-home. And it is easier to run than a take-home in one respect and harder in another, because you cannot control which part they push on.

Declining without burning the relationship

Sometimes the answer is no. Decline in a way that leaves the person able to come back to you, because hiring managers change companies and recruiters have long memories.

Thank you for this, and for the time everyone has spent so far. I have decided not to do the exercise, so I would like to withdraw rather than leave you waiting.

To be straightforward about why: at around a day of work it is more than I can take on unpaid alongside my current commitments. That is a judgement about my own capacity rather than a criticism of your process, and I know it is a normal ask.

I have enjoyed the conversations and I would be glad to talk again if something comes up where the process fits differently. If it is ever useful, I am happy to be walked through by someone or to do a shorter session instead.

Three things this deliberately does not do. It does not criticise the practice, because criticising it invites a defence and turns a withdrawal into an argument. It does not leave a door ajar it does not mean, but it does leave one open. And it withdraws explicitly rather than going quiet, which is the difference between a candidate they remember well and one they remember as unreliable.

Ghosting is the version most people choose and it is the worst option available. It costs a two-minute email to keep a relationship you may want in two years.

How to read the answer you get back

Every one of these messages is a probe as much as a request. You are asking a question whose content matters less than how the organisation handles being asked, because you will be asking questions like this for the whole time you work there.

A good answer is fast, direct, and treats the question as normal. It gives you a real number or a real no. It sometimes adjusts the process, which tells you the process is theirs rather than a policy they are enforcing. And it does not mention your commitment, your enthusiasm or your hunger, because a hiring manager who is comfortable with the question does not need to test your keenness with it.

Warning signs are consistent. A time box that becomes vague when questioned ("as long as you need to do your best work") is a completeness competition being conducted under a false constraint. Any answer implying that asking is a bad sign is telling you exactly what raising a scope concern will feel like in month three, and it is the single most reliable signal in the whole exchange. Multiple people giving you different answers means nobody owns the process. Silence for a week followed by a deadline reminder means the same. And "everyone else managed it" is an appeal to peer pressure rather than an answer, deployed by someone who does not want to defend the ask.

The reframe worth holding onto: you are also assessing them, and this stage is one of your best instruments for it. Companies behave in a hiring process roughly the way they behave at work, and the way they respond to a reasonable question about scope is a preview of every sprint planning session you will attend. That is the same logic behind treating an offer with a twenty-four-hour deadline as information about the company rather than merely a constraint to manage, and behind raising notice period, relocation and remote expectations early enough to see how they are handled.

Managing the take-home when you have several processes running

Worth a paragraph on its own, because it is the commonest practical reason a take-home is impossible rather than merely unwelcome. Three exercises in one fortnight is not something anybody can do well, and the answer is sequencing rather than heroics.

Say so, in a way that is honest without being a threat. The question are you interviewing elsewhere has already established the fact in most processes, so using it as a scheduling constraint is not a revelation.

I have two other processes at a similar stage and I would rather do this properly than rush it. Could I send it by the end of next week rather than this one? If your timeline does not allow that, tell me and I will work out how to fit it.

That gets a yes far more often than candidates expect, because a hiring manager would much rather wait five days than read a rushed submission. And do not use a competing process as leverage. A scheduling constraint is reasonable; an implied threat converts you from a candidate into a negotiation.

When no feedback comes

The commonest ending to a take-home is a two-line rejection with no detail, or nothing at all, and it is the part candidates find hardest to accept because they have produced an artefact and expect an artefact in return.

Understand why it happens before deciding what to do about it, because the reason shapes the ask. Detailed feedback on a submission is legally cautious territory in many organisations, and legal or HR guidance frequently prohibits specifics. It is also expensive: written feedback on a code submission takes the reviewer half an hour to write carefully, per candidate. And there is a self-interested reason nobody says out loud, which is that specific feedback on a reused exercise leaks the exercise. If the rubric goes out to twenty rejected candidates a quarter, the exercise stops working within a year.

So the default is silence, and it is usually policy rather than contempt. That does not make it pleasant, and it is a legitimate thing to weigh when deciding whether to accept the next one.

How to ask in a way that sometimes works

Generic requests fail. "Could you share any feedback on my submission?" is easy to decline with a template because it asks the recipient to do open-ended work. What sometimes works is a request narrow enough to answer in one line, aimed at a specific person, with a named hypothesis they can confirm or correct.

Thanks for letting me know, and no hard feelings about the outcome.

One narrow question if you have a moment. I made a deliberate call to keep the storage in memory and spend the time on the validation instead. If that call was the thing that went against me I would genuinely like to know, because I make that kind of trade-off regularly and I would rather calibrate it. A yes or no is plenty and I will not follow up further.

Why the narrow version gets answered when the broad one does not. It takes ten seconds to reply to. It offers a hypothesis, so the reply is a confirmation rather than a composition. It explicitly closes the loop, so the recipient is not committing to a correspondence. And it is about a decision rather than about your ability, which is much easier to comment on without legal exposure.

Send it to the hiring manager or the engineer who reviewed it if you have their address, rather than to the recruiter, because the recruiter does not have the information and is the person the policy is written for.

Two other framings sometimes land. Asking about the process rather than the person: "Was the exercise the deciding stage, or was this more about the shape of the role?" And asking forward rather than backward: "If a similar role came up in six months, is there something you would want to see different?" Both are easier to answer than a critique.

If you get nothing, accept it in one message and stop. Pushing converts a neutral outcome into a memorable negative one, and the person you are pushing genuinely may not be permitted to answer.

Doing your own debrief

Since feedback is unreliable, the useful habit is to grade yourself against the rubric on this page within a day of submitting, while you still remember your choices.

Five questions produce almost all of the value. Did it run from a clean clone following my own instructions, and did I check. Did I stay inside the stated scope, and if not, can I name what I added and why. Did I write down my decisions somewhere a reviewer would find them in twenty minutes. Is there a decision in there I made silently that was not mine to make. And how long did it really take, against what the brief suggested.

Keep the answers. A take-home you did in March is the raw material for the covering note in July, and more importantly, the exercise is reusable as a portfolio piece for exactly the alternative-format proposal above. A candidate with three well-documented small projects they can be interrogated on has a permanent way out of the next unreasonable brief.

What interviewers ask

The questions in this stage cluster into six archetypes, and each one is a probe for a specific signal rather than a request for information. Knowing which is which tells you what a good answer has to contain.

The pattern across all six is that almost none of them ask you to demonstrate knowledge. They ask about your relationship to work you already did, which is why they cannot be answered from preparation about the technology and can be answered well by anybody who thought about their own choices while making them.

One cross-cutting signal appears on scorecards in every format, phrased differently each time: whether you distinguish what you verified from what you assumed from what you guessed. A candidate who reports all three in the same register is a candidate whose status updates cannot be trusted. "The aggregation is tested and I am confident in it; the timezone handling is an assumption I flagged; the performance claim in the README is a guess from the file sizes and I have not measured it" is three sentences that do more for your credibility than any feature.

The second cross-cutting signal is tone about the exercise itself. Panels notice candidates who are visibly resentful, and they notice candidates who are enthusiastic in a way that does not survive a follow-up question. The register that works is straightforward interest in the problem plus honesty about the constraint you worked under, which is available to you whatever you privately think about take-homes.

Questions

The questions below are phrased the way interviewers put them. Answers name what the panel grades, because on this stage that is frequently not what the question appears to be about. The playback questions in the middle of this list are where most candidates with good submissions are caught.

Walk us through what you built.

Open with what it does and the constraint you worked under, in two sentences. Then say which part you chose to go deep on and why that part, referring to something in the brief. Then run it, briefly, on the smallest input that shows the interesting behaviour. Then spend most of your time on the two or three decisions you are least sure about, and finish with what you would do next in one sentence. Offer them the wheel early: "that is my plan for the next ten minutes, but go wherever you want."

What is graded is whether you can compress and whether you volunteer the uncertain parts. A candidate who narrates their code file by file has told the panel what their design reviews will be like. A candidate who leads with the decisions they are unsure about is doing what a colleague would do, and it also directs the session towards ground you have prepared.

How long did this take you?

Say the real number. If it was over the stated box, say that too and say what you would have cut to fit. "About six and a half hours. If I had held to four I would have stopped before the duplicate handling, which is the last commit, and I would have written the note about it instead."

This is graded on honesty and on calibration, and both are checkable. Commit timestamps are visible, so an understated number is a risk with no upside. The secondary signal is whether your estimate of your own throughput is realistic, because a candidate who is consistently out by a factor of three on a four-hour exercise will be out by the same factor on a sprint. Reviewers are far more relaxed about an overrun than about a number that does not match the repository.

Why did you not use a database?

Answer with the basis, not the conclusion. "The brief specified one file and said nothing about durability, so the store was not the interesting part of the problem. Adding Postgres would have cost you setup time in review and told you nothing more about how I work. It is behind one interface, so replacing it is a contained change and I wrote that down in the README."

Then find the concern behind the question: "Is the worry whether I would reach for the right thing on a real service, or something about the volumes here?" The graded content is whether the omission was a decision. An answer of "I ran out of time" on something you deliberately excluded is a wasted opportunity, and an answer that concedes the choice was wrong when it was defensible tells them you will not hold a position. This question is very frequently a test of whether you can defend correct restraint.

What would you delete from this if you had to cut it in half?

Name something specific and say what it costs. "The retry logic in the ingest. It handles a failure mode the brief did not mention, and if I had to lose something it would be that, because the validation and the aggregation are the parts a defect would hide in. The cost is that a transient read failure would surface as an error rather than being absorbed, which on a batch job is arguably the better behaviour anyway."

The signal is whether you can criticise your own work at the level of a specific artefact rather than in general terms. "I would tighten it up" is not an answer. Candidates who identify the part they added because it was interesting rather than because it was needed score well, because that self-awareness is what makes them safe to give scope to. Answering "nothing, it is all necessary" fails, because on any real submission something is.

What did you leave out, and why that rather than something else?

Give the list and the reasoning behind the ordering, since the ordering is the answer. "No export, no auth, and the error handling stops at validation failures. I dropped the export because it is mechanical work that tells you nothing about my judgement, and I dropped auth because implementing it would have meant inventing a threat model you did not give me. The error handling was the closest call, and if I had another hour it is what I would spend it on."

Graded on whether you have a priority rationale at all. A candidate who lists omissions with no ordering logic did not prioritise, they just ran out of time in a particular order. The strongest answers name the closest call, because that is where the judgement lives.

The brief did not say what counts as a duplicate. What did you do?

Say what you noticed, what you chose, and where you recorded it. "It is genuinely ambiguous, and it changes the output significantly. I matched on reference plus date, which is the conservative reading, because dropping a legitimate row silently is worse than keeping a duplicate that somebody can see. I have not treated it as decided, though: it is in the README as an open question and there is a comment at the dedupe call, because it is a data question for whoever owns the upstream system rather than something I should settle alone."

This is the highest-value answer available in the whole stage. Three things are graded: that you noticed the hole, that you chose something reversible rather than either guessing confidently or building for every case, and that you recorded it. The failure is having decided it silently, which reads to a reviewer as not having noticed. It is also worth saying that you considered emailing to ask, and why you did or did not.

Did you consider asking us about that instead of assuming?

Be honest about the calculus. "I did, and I nearly sent it. I decided the assumption was cheap to reverse and I did not want to block on a reply over a weekend, so I chose one direction and flagged it. On a real ticket I would have asked, because the cost of asking is ten minutes and the cost of getting it wrong compounds. If you would rather candidates asked, I would prefer that too."

The graded content is whether you have a rule for when to ask, rather than a habit of never asking or of asking everything. The rule that reads well is about reversibility and blocking: ask when the answer is expensive to reverse or when you cannot proceed, assume and flag when it is cheap and you can. A candidate who says they would never interrupt with a question has described somebody who builds the wrong thing quietly.

We noticed this breaks if two requests come in at once. What do you make of that?

Concede immediately and specifically, then classify and cost it. "You are right, and it is the worst kind because it fails silently. The accumulate is a read then a write with no lock, so two overlapping ingests lose one of the increments and the total is quietly wrong. Making that step atomic is a small change; the harder part is the test, which needs two concurrent ingests asserting the total, and I would want that test because otherwise the fix is unverified. Half an hour for both, and I would put it above the export."

Graded almost entirely on the first four words. Defending it, minimising it, or claiming it would not happen in practice all fail even where the last is true. Naming the failure mode precisely, saying whether it is silent or loud, and costing the fix demonstrates that you can receive a correction and turn it into a plan, which is the behaviour they are trying to predict.

How would this change if the volume were a thousand times larger?

Reason from your own design rather than reaching for a list of technologies. "The bottleneck moves twice. First the file read, which is single-threaded and would need chunking; the aggregation is associative so parallel chunks combine safely, which is why I structured it that way. Then the in-memory store, which stops fitting, and at that point it is a real database and the interface I put it behind is the seam. What does not change is the validation, which is per-row and scales linearly. The thing I would want to measure before doing any of it is whether the peak matters or only the daily total, because those need different designs."

The signal is whether your reasoning is grounded in the code you wrote or in generic scaling vocabulary. Candidates who answer with a list of infrastructure have not engaged with their own design. Naming what does not need to change is a strong move, and so is naming the measurement you would take first, since it demonstrates the same instinct as choosing between a modular monolith and microservices on evidence rather than on fashion.

Why did you write the tests you wrote and not others?

State the principle and then apply it. "I tested where a defect would be silent. The validation and the aggregation arithmetic are both places where a wrong answer looks like a right answer, so those have real cases including boundaries. The HTTP layer has one smoke test because a break there is loud and immediately visible. I have not tested the CLI parsing at all, which is a gap I would close before this shipped but not one I would trade the aggregation cases for."

Graded on whether there is a rationale rather than a target. Coverage numbers as a justification are a negative signal on an exercise, because they are trivially inflated and reviewers know it. The other thing being read is your test names, so if they describe behaviour, point at them.

What was the hardest part?

Pick something real and technical rather than something about the process. "Working out what the file actually meant. Three of the sample rows have a quantity that does not match the line total, and there is no rule in the brief for which one is authoritative. Deciding that was harder than any of the code, and it is the thing I would have asked about first."

Graded on whether the difficulty you name is the one they consider difficult. Interviewers usually know where the interesting part of their own exercise is, and a candidate who names the trivial part has revealed they never reached the interesting one. Saying "nothing was hard" fails on any exercise worth setting, and reads as either inattention or bravado.

If you did this again with the same four hours, what would you do differently?

Name a process change rather than a feature. "I would write the README first. I spent the last twenty minutes writing up decisions I had made three hours earlier and I had lost some of the reasoning, so a couple of the notes are thinner than the thinking was. And I would have sent you one email about the duplicate rule on day one instead of assuming, because the answer would have changed about forty minutes of work."

The graded quality is whether you reflect on how you worked rather than on what you produced. Answering with a feature list ("I would have added the export") is answering a different question and suggests you are measuring yourself against the brief rather than against your own process. The self-knowledge here is the same thing being probed by the work you are proudest of and why that one, where the reasoning behind the choice is worth more than the choice.

The brief said four hours. Is that realistic?

Answer honestly and specifically, and put a proposal on it. "Not for all of it, no. The ingest and one endpoint properly is four hours; the full brief including the deployment setup is closer to two days. That is why I did the ingest well and stopped, and said so. If you want to keep it at four hours, I would cut the deployment section from the brief, because it is the part that adds time without telling you much about the candidate."

Graded on whether you can disagree with them usefully. The failure at one extreme is agreeing when it plainly was not realistic, which tells them you will accept an impossible commitment silently. The failure at the other is complaint without proposal. Offering an improvement to their exercise is a strong move, because it demonstrates you can give feedback upwards on something they own, which is the behaviour behind influencing without authority.

You went well over the time we suggested. Talk us through that.

Own it and explain the choice rather than the accident. "I did, about seven hours against four. I made a judgement that you would rather see the duplicate handling working than read a note about it, and I may have got that wrong. What I should have done is ask, and I did not. What is true is that four hours gets you the ingest, the validation and the query endpoint, which is the first four commits, and everything after that is the extra three hours."

The saving move is making the overrun auditable, so they can see the four-hour version inside the seven-hour submission. Graded on whether you understood that the box was a constraint rather than a suggestion, and whether you can accept a mild criticism without either collapsing or arguing. Answering "I enjoyed it so much I lost track of time" is heard as an inability to work to an estimate.

We gave you a scenario and no data. What did you assume, and which assumption worries you?

Give the numbered list, then single out the fragile one and say what it would take to check it. "Four assumptions, all in the appendix. The one that worries me is the second, that procurement in this segment runs about three months. I took that from the two case studies on their website, which is a weak source and probably biased towards fast wins. If it is nine months the recommendation flips, because the runway does not reach the second cohort. It is also the cheapest one to check, since two customer calls would settle it."

Two things graded. Whether the assumptions are falsifiable and sourced rather than decorative. And whether you know which one carries the recommendation, since a candidate who cannot rank their own assumptions has not tested their argument. Volunteering the fragile one before being asked is the senior version of this answer.

Which number in your analysis would change your recommendation?

Name it, name the threshold, and name what would not matter. "The procurement cycle length. At three months the answer is enterprise-first; somewhere around six it flips to mid-market and stays there. Nothing else in the model is that sensitive: the churn figure could be double and the answer holds, and the pricing assumption barely moves it. So if I had one week and one question, it would be that one."

This is close to a pure test of whether you did sensitivity analysis or arithmetic. A candidate who says "all of them matter" has not tested their own model. Naming the number that does not matter is as strong as naming the one that does, because it shows you checked rather than guessed at the ranking.

Your recommendation is on the last slide. Why?

Do not defend it. "Because I presented it in the order I did the work, which was the wrong choice. The recommendation should be on the first slide with the two reasons under it, and everything else should support it or move to an appendix. If it is useful I can give you the one-slide version now, in about thirty seconds."

Then do it. The graded moment is whether you can take a structural criticism without arguing, and whether you can produce the front-loaded version on demand, which proves you have an argument rather than a pile of analysis. Explaining that you wanted to build to the conclusion fails, because it defends a choice that made the reader's job harder.

Take us through your reasoning as you go. Where do you want to start?

Announce the map before walking it. "Three things I need to get right: how data gets in, how it is stored, and what happens when a source is late or corrects itself. I think the third is where the difficulty is, so I want to move quickly through the first two and spend most of the time there. Before I start, roughly what volume are we talking about, and are the late corrections a real requirement or something I should not worry about?"

Graded on whether you decompose before diving, whether you allocate attention deliberately, and whether you check your allocation with them. Candidates who begin drawing boxes immediately are answering before they have scoped, and forty minutes later they are deep in the part the interviewer did not care about. Asking which area matters is not weakness; it is the cheapest mark in the round.

You have been going for twenty minutes. Where are you?

Give a status in three parts: what is settled, what is open, what you plan next. "Ingest is settled, individual events rather than files, because of the late-correction requirement. Storage I have narrowed to two options and I have not chosen, because the choice depends on whether we need to query the raw events or only the aggregates, which I was going to ask you. Next I want to do the late-arrival handling, which is the part I think you care about."

This is graded on whether you can report on your own work in progress, which is a daily job requirement and something remarkably few candidates can do cleanly. The tell of a weak answer is a candidate who has to reconstruct where they are, which means they were not tracking it. Naming the open decision and the fact it is blocked on a question is the strongest element here.

I think there is a problem with your approach. What is it?

Do not guess wildly and do not freeze. Reason out loud towards it and ask for the direction if you do not find it. "Let me look. The risk I am most aware of is the ordering, because I have assumed events arrive roughly in sequence and if they do not the aggregate is wrong until a rebuild. Is that the one, or is it something on the storage side? I would rather you pointed me than have me guess for five minutes."

Graded on composure and on whether you can locate a weakness in your own design under pressure. Naming the risk you already knew about is a strong outcome even if it is not the one they meant, because it shows you were tracking risks rather than being surprised by one. Asking for the direction after one honest attempt is fine; asking immediately reads as helplessness, and guessing for five minutes wastes the round.

The exercise we send takes most people about a day. Is that a problem for you?

Answer straightforwardly and put a proposal on it rather than either capitulating or refusing. "A full day unpaid is more than I can commit to alongside my current role, so let me offer two alternatives. I could do a scoped-down version, maybe three hours on whichever part matters most to you, or I could walk you through a project I have already built, sending you the repository in advance so you can read it cold. Either gives you an artefact and questions on it. Which is easier for you?"

Graded on whether you can raise a constraint without drama and whether you bring a proposal. Both extremes are read: agreeing to something you then do badly or resent, and refusing with nothing offered. The proposal is the whole answer. Note that this question is sometimes asked to check exactly this, because a candidate who cannot negotiate a workload in an interview will not negotiate one with a product owner.

Would you be willing to work on a real feature from our backlog as the exercise?

Say what makes it acceptable rather than yes or no. "Depends on two things. If it is small and disposable, and you are not going to merge it, I am happy to, and honestly it is more interesting than a synthetic problem. If it is something you would ship, that is work rather than assessment and I would want it treated as a paid piece. Can I ask which it is?"

Graded on whether you can distinguish assessment from delivery, and on how you raise it. The version that fails is an accusation; the version that works is a clarification with both options presented as legitimate. Some interviewers ask this specifically to see whether candidates notice the difference, and answering with an unqualified yes is occasionally the wrong answer to a deliberate question.

We did not give you feedback last time you applied. Why are you back?

Answer without grievance, and be specific about what changed. "The role is a better fit than the last one, and I wanted another go. I did ask for feedback and did not get any, which I took as policy rather than anything personal. What I did instead was look at what I submitted a few months later, and the honest answer is that the write-up was thin: I had made reasonable decisions and not recorded them anywhere a reviewer would find them in twenty minutes. That is the thing I would do differently."

Graded on whether you can be denied something and remain reasonable about it, and on whether you did your own debrief in the absence of theirs. A candidate who is still aggrieved about a rejection months later has answered a question about their temperament. A candidate who audited their own submission and can name the specific weakness has demonstrated more than any feedback would have given them.

Do you have any questions about the exercise?

Ask the three that change what you do. What is the real time box and would they rather you stopped or finished. Which part of it they care most about. And whether the requirement list is exhaustive or illustrative, because that single answer determines whether extra work is invited or penalised. If it is a case, add what format they want and what the page limit really is.

Asking these is scored higher than almost anything you could build, and it is the cheapest mark in the stage. A candidate who takes the brief as given and prepares in silence has demonstrated precisely the behaviour that produces a technically excellent submission answering the wrong question, which is the same reason do you have any questions for us is never a formality. Most candidates say no and leave the mark on the table.