The recruiter at a Series B fintech (about 70 engineers, NYC, B2B payments) sent me the take-home on a Friday at 2pm. The window was 72 hours but the prompt said budget 6 to 8 hours of actual work. I budgeted 8, used 9, and most of the extra hour was on the README, not the code. The take-home review call a week later was where the offer was actually decided, and the call did not go where I thought it would.

What the prompt asked for

The prompt was a single PDF, three pages. Anonymized here because the prompt is not public:

• Build a small service that ingests merchant settlement files (CSV, one row per transaction, 6 columns including a merchant id, amount in minor units, and a settlement date) and produces a daily reconciliation report per merchant.
• The service must be idempotent: the same file uploaded twice must not double-count.
• The report must flag transactions that fall outside the merchant's expected daily volume range (range provided per merchant in a small config file).
• Include a runbook for what to do when ingestion fails partway through a file.
• Tests, README, and "a 5 line note on what you would do next if you had another 4 hours".

The prompt looked friendly. The trap was the runbook line. I almost skipped it.

How I structured the 8 hours

I wrote the time budget on a sticky note before I started. It is the single thing that made the submission feel finished:

budget
  hour 1: read prompt twice, sketch data model, name files
  hour 2-3: ingestion, idempotency key, basic CSV parser + tests
  hour 4-5: reconciliation logic, flag detection, more tests
  hour 6: failure runbook (the part I almost skipped)
  hour 7: README
  hour 8: review pass, polish, push

The one design call I made early was to use a content hash of the file as the idempotency key, stored in a separate ingested_files table with a unique constraint. That meant retries were cheap and observable; if the same hash showed up twice, the second insert failed at the DB layer and the service logged it and moved on. I wrote a 4-line note in the README explaining why I picked a content hash over a file path or a client-supplied uuid. That note is what they ended up asking me about on the review call.

What the review call was actually grading

The review call was 60 minutes with the engineer who would be my tech lead. I had assumed it would be a code walkthrough; he had the code open but barely scrolled. The first 40 minutes were three questions:

1. "Why did you pick a content hash over a uuid the client supplies? What breaks first when you scale this?"
2. "Your runbook says a partial ingestion is recoverable by deleting the row in ingested_files and re-uploading. What if the partial write already produced a downstream report a customer saw?"
3. "You flag transactions outside the expected range. The expected range is in a static config. What do you do when the config is wrong?"

These were not gotcha questions. They were the actual operational questions the team was living with. He was grading whether I could think about the problem the way someone who would inherit this code on Monday morning would think about it. The first question I half-answered. The second one I admitted my runbook was wrong, and proposed a soft-delete plus a customer-visible "superseded" status, which he said was right. The third one I caught quickly: a wrong config means the flag system is silently broken, so the right thing is to monitor the rate of flags per merchant and alarm when it deviates from baseline, not just trust the config.

The last 20 minutes were architecture extension: how would I make the service handle 50x volume. I picked the smallest change that would buy us time (batched DB writes plus a per-merchant queue) and explicitly deferred Kafka to "after we hire two more engineers". He nodded.

What I changed about how I do take-homes after this one

I got the offer and joined. The take-home itself was 60% of the signal in retrospect; the review call was 40%, but the review call was steered by what I had written in the README. The README is what makes the call go where you want it to go. Three things I now always do:

First, write a "design decisions and tradeoffs" section in the README before writing tests. The tradeoffs section forces me to notice my own assumptions, and gives the reviewer something specific to push on. Generic code with no README invites generic critique.

Second, build the failure runbook as an actual runnable script, not prose. If the prompt asks "what do you do when ingestion fails", the strongest answer is bin/recover-ingestion.sh <file-hash> plus a doc explaining what it does.

Third, time-box the polish. A take-home that is one hour over budget reads as motivated. One that is four hours over budget reads as someone who cannot ship.