The Take-Home Playbook

A take-home assignment is a work sample graded by strangers. The grader never meets you, never watches you code, and spends limited time on your submission. What they grade is not how much you typed — it's the evidence of judgment your submission leaves behind.

Minimum concept: what the grader can actually see

Strip away the interview mystique and the take-home is brutally simple. A person you have never met opens a repository you built alone, with somewhere between twenty minutes and an hour of attention, and tries to answer one question: would I want to work with the person who built this?

They cannot see your thought process. They cannot ask you why you chose SQLite over Postgres, or why you skipped the CLI, or what the vague sentence in the brief meant to you. They only see artifacts — files. And files are evidence of judgment: what you prioritized under a time budget, what you considered an edge case, how you communicate to a stranger.

This is the minimum concept that reorganizes everything else in this post:

• Working code is the price of entry, not the differentiator. Most submissions run. The ones that advance are the ones where the grader can reconstruct why each decision was made.
• Ambiguity is the test. Take-home briefs are deliberately (or accidentally) underspecified. The grader isn't checking whether you guessed their hidden preference — they're checking what you did with the gap: did you state an assumption, or did you silently guess?
• Time is a constraint to be managed, visibly. Four hours is part of the brief. A submission that nails the core in four hours beats a sprawling one that clearly took twelve, because the job being hired for has deadlines too.

Everything below — the hour-by-hour plan, the README template, the ambiguity playbook, the repo structure — is one system for manufacturing legible evidence of judgment. Let's build it.

Part 1: The 4-hour execution plan

The most common failure mode of take-homes isn't bad code. It's bad budgeting: two hours lost to tooling setup and an over-engineered data model, forty frantic minutes of README at the end, zero tests, and a commit history consisting of one commit titled final final v2.

A four-hour take-home is a tiny project, and tiny projects still need a plan. Here is the plan, as a table you can tape to your monitor. It is a composite pattern distilled from what strong candidates tend to do — not a survey of any company's process.

The mermaid view: the 4-hour plan as a flow

What to cut when time runs short

You will run short of time. Plan for it now, so the cuts are strategic instead of panicked. The ordering below is deliberate: cut from the bottom.

Part 2: READMEs that score

The README is the first file the grader opens and often the only prose they read in full. Think of it as a cover letter for your code: it frames everything they are about to see. A weak README forces the grader to reverse-engineer your intent from the code. A strong README tells them what to look for — and they will look for it kindly, because you've made their job easy.

Strong candidates' READMEs tend to share four sections, in this order:

1. What this is — one paragraph: the problem, the approach, the scope. Written for a stranger.
2. How to run — copy-pasteable commands that work from a fresh clone. This is the section that fails most often, and it's the one the grader hits first.
3. What I assumed — the ambiguities you found and the calls you made. This is where judgment becomes visible.
4. Known limitations + what I'd do next — the honest gap list and the roadmap. This turns "didn't do X" from a weakness into a demonstration of prioritization.

The template

Copy this skeleton for every take-home. Fill it in as you go — write the assumptions section during the 0:00–0:30 design phase, not at 3:40 in a panic.

# Ticket Summary Service

One-paragraph summary: what the service does, who it's for, and the
approach in a sentence. (2-3 lines. If you can't say it in 3 lines,
your scope is too big.)

## How to run

Prerequisites: Python 3.11+, nothing else.

    python -m venv .venv
    source .venv/bin/activate
    pip install -r requirements.txt
    python -m tickets summary data/tickets.csv --serve --port 8000

Then open http://localhost:8000/summary — you should see a JSON payload
with per-category counts for the sample data.

Run the tests:

    pytest -q

## Design notes

- The ingestion step streams the CSV row by row instead of loading it
  into memory, so a 1M-row file won't blow up RAM.
- Summaries are computed in a single pass and cached in memory;
  re-ingesting replaces the cache. (Chose this over a database:
  the brief asks for a summary view, not persistence.)

## Assumptions

1. The brief doesn't say how to treat rows with a missing category.
   I count them under "uncategorized" and report the count, rather
   than dropping them silently. Rationale: dropping data the user
   supplied is a decision the operator should make, not the tool.
2. "Summary" is interpreted as per-category counts plus the 5 oldest
   open tickets. If you meant something richer (trends over time),
   the aggregation layer is isolated in `tickets/aggregate.py` and
   easy to extend.
3. Timestamps are assumed to be UTC ISO-8601. Anything unparseable
   is logged to stderr and skipped, with a skipped-row count in
   the summary output.

## Known limitations

- No authentication on the endpoint (out of scope for a 4-hour build;
  in production this would sit behind the org's gateway).
- In-memory cache only — a restart loses the ingested state.
- Single-process; no concurrency handling beyond the stdlib server.

## What I'd do next (with more time)

1. Persist ingestion state (SQLite) so restarts are safe.
2. Add a `--since` filter for incremental summaries.
3. Structured logging + a `/health` endpoint, per the deployment
   checklist in our monitoring lesson.

## Repo layout

    tickets/          # the package: ingest.py, aggregate.py, api.py
    tests/            # pytest suite for ingestion + aggregation
    data/             # small sample CSV (2KB), not real customer data
    README.md         # you are here

Before / after: the same candidate, two READMEs

The examples below are composites. The "before" is what a capable engineer writes when they treat the README as an afterthought. The "after" is the same project, documented with the template. Same code — different grade, because the evidence of judgment is different.

# tickets

ticket summary thing

run: python main.py

Notice what the strong README never does: it never apologizes ("sorry this is rough"), never blames the brief ("the instructions were unclear"), and never invents completeness ("fully production-ready"). Confidence without absolutes — the same editorial standard as the rest of this curriculum.

Part 3: Handling ambiguity

Here the curriculum's DNA pays off directly. From Stage 1, this course has drilled one reflex: clarify the ask before you build (Scoping & Success Metrics; Discovery). The take-home is the same skill under harsher conditions: you cannot ask the customer a follow-up question, so you must do the next best thing — state your assumptions explicitly, document the tradeoffs, and never silently guess.

Why "never silently guess"? Because a silent guess has two failure modes and no upside. If you guess right, the grader can't tell you reasoned it out — it looks like luck. If you guess wrong, it looks like you didn't notice the ambiguity at all. An explicit assumption, by contrast, is gradable evidence: the grader sees the gap, sees your reasoning, and can evaluate the quality of your judgment even when they'd have chosen differently.

The working method, compressed:

1. Spot the gap. During the 0:00–0:30 read, mark every sentence in the brief that could mean two things. If a sentence makes you pause, that's a gap.
2. Pick the most defensible reading — the one a reasonable operator would expect — and note the alternative you rejected and why.
3. Write it in the README's Assumptions section, numbered, with a one-line rationale each.
4. Isolate it in the code. Put the ambiguous decision behind a small function or a named constant, so a different reading is a one-line change. Graders notice this; it reads as "designed for the customer to overrule me," which is exactly the FDE posture.

Three composite ambiguity scenarios

Each scenario below is a composite based on common patterns in take-home briefs. For each: the vague brief line, what a weak response looks like, and what a strong candidate does.

Scenario 1: "Handle large files efficiently"

The gap: "Large" is undefined — 10MB? 10GB? — and "efficiently" could mean memory, speed, or both. The brief gives no numbers and no environment.

Weak response: Loads the whole CSV into a list of dicts, adds a comment saying # efficient enough, and moves on. Or the opposite failure: builds a chunked parallel processing pipeline with worker pools for a problem that might involve a 2MB file — impressive machinery, unjustified by anything in the brief.

Strong response: Streams the file row by row (constant memory, one pass), states the assumption — "Assumed 'large' means bigger than RAM is comfortable with; streaming handles anything from KB to GB with the same code. If 'efficiently' meant latency under a deadline, I'd add chunked parallelism — noted in 'What I'd do next.'" — and isolates the ingestion in one function so the strategy is swappable. The grader sees a measured response to an unmeasured requirement.

Scenario 2: "The API should be intuitive"

The gap: "Intuitive" is in the eye of the beholder. REST purists, RPC pragmatists, and CLI-first operators will all read this differently.

Weak response: Picks whatever style the candidate used last, with no explanation. The grader, who prefers a different style, reads it as a coin flip.

Strong response: Chooses one convention and documents the choice: "Assumption: 'intuitive' means a resource-oriented endpoint (GET /summary) returning JSON with stable field names, since the consumer is likely another script or a dashboard. Rejected a CLI-only design because the brief says 'exposes an endpoint.'" Field names are documented with an example response in the README, so "intuitive" is verifiable, not asserted. Bonus signal: the example response in the README matches the actual output byte-for-byte — graders do check.

Scenario 3: "Include appropriate error handling"

The gap: "Appropriate" for whom? The end user, the operator, the developer integrating the API? Every audience wants different errors.

Weak response: Wraps everything in try/except Exception: pass, or lets raw tracebacks leak to the API consumer. Both are evidence the candidate didn't think about who reads the error — a lesson this curriculum covers in Debugging Like a Detective.

Strong response: Separates audiences explicitly: malformed input rows are logged to stderr with line numbers and counted in the summary (operator audience); the API returns a clean 422 with a short, safe message (consumer audience) — never a traceback, never an internal path. The README's assumptions section names the policy in one line: "Errors are classified by audience: operators get details in logs, API consumers get safe summaries." That one line is worth more than a page of exception handlers.

Part 4: Repo structure template

Graders form an impression of your engineering habits within seconds of seeing the file tree. The template below is deliberately boring — and boring is the point. It mirrors the packaging conventions from Packaging, Envs, Logging & CLIs: a real package, a real test suite, pinned dependencies, and nothing committed that shouldn't be.

take-home-tickets/
├── README.md              # the graded cover letter (see Part 2)
├── requirements.txt       # pinned: requests==2.32.3, pytest==8.3.4
├── .gitignore             # .venv/, __pycache__/, *.pyc, .env, data/*.csv
├── tickets/               # the actual package
│   ├── __init__.py
│   ├── ingest.py          # CSV reading: streaming, row validation
│   ├── aggregate.py       # summary computation: pure functions, easy to test
│   └── api.py             # thin HTTP layer: routes call aggregate, nothing else
├── tests/
│   ├── __init__.py
│   ├── test_ingest.py     # happy path + malformed rows + empty file
│   └── test_aggregate.py  # counts, edge cases (no tickets, ties)
├── data/
│   └── sample_tickets.csv # tiny sample (a few KB) so the grader can run it
└── NOTES.md               # optional: your 0:00-0:30 scratch design notes,
                           # left in deliberately — shows your thinking

Three rules that separate strong submissions from sloppy ones:

1. No secrets, ever. If your code needed an API key during development, it comes from an environment variable, and .env is in .gitignore. Committing a key — even a "test" key — is the fastest way to fail a take-home at a security-conscious company. The Secrets & Security Basics lesson exists for exactly this reason.
2. Small, honest commits. git log --oneline should read like a work diary: scaffold package layout, ingest CSV with streaming reader, add summary endpoint, handle malformed rows + tests, write README. One giant initial commit at 11:58 p.m. tells the grader nothing about your process — and the process is part of what's being graded.
3. The sample data is tiny and obviously fake. A 40MB CSV in the repo, or real customer-looking data, raises eyebrows. A 2KB sample with names like "Test User" signals you thought about what you're shipping.

NOTES.md deserves a word: leaving your scratch design notes in the repo is a deliberate, slightly unusual move — and that's why it works. It shows the grader your 0:00–0:30 thinking verbatim: the gaps you spotted, the options you weighed, the things you chose not to build. It's the closest a take-home gets to letting the grader watch you think.

Part 5: What graders actually score

A note on framing, because this curriculum doesn't invent data: there is no published survey of "how companies grade take-homes" cited here, and you should be skeptical of anyone who claims there is. What follows is a composite pattern — what strong candidates' submissions tend to demonstrate, mapped to the signal each artifact sends. Use it as a checklist for your own submission, not as a claim about any specific company's rubric.

Productionize: your reusable take-home checklist

The curriculum's "productionize" step means turning a one-off effort into a repeatable system. Here is yours — a checklist to run before every take-home submission, in order:

1. Fresh-clone test: clone into a new directory (or a new terminal with a clean env) and follow your README verbatim. If any step needs something not in the README, the README is wrong — fix the README.
2. Secret scan: git log -p | grep -iE "api[_-]?key|secret|token|password" and eyeball the hits. Check .env is ignored and untracked.
3. Assumption audit: re-read the brief once more and check every "hmm" moment has a numbered assumption in the README. Unwritten assumptions are silent guesses.
4. Commit hygiene: git log --oneline reads as a sensible story; no WIP, no fix without context, no 200-file "cleanup" commit.
5. Scope check: for every file and feature, ask "did the brief ask for this, or did I want to show off?" Cut or document.
6. The stranger test: read your README as if you've never seen the project. Would you know what it does, how to run it, and what the author decided — in five minutes? If not, rewrite.