The Take-Home Project & Client Presentation

1 · What the take-home round is really scoring essential

Most candidates treat the take-home as a coding test and spend all six hours writing code. They arrive at the presentation with an impressive-looking system that half works, no measurement of whether it helps, and slides they made in the last ten minutes. The panel asks "how do you know it works?" and the answer is a demo of the one example that happens to succeed. That candidate usually doesn't get the offer, even when their code is better than everyone else's.

The reason is that the take-home isn't scoring how much you can build in six hours. It's a small simulation of a client engagement, and the panel is watching for the same things a client would: did you understand the problem before solving it, did you choose a sensible slice given the time, does it actually work and do you know how well, are you honest about what it can't do, and can you explain all of that to people who don't read code? Code quality matters — it should be clean, tested and runnable — but it's one line on the scorecard, not the whole thing.

So plan the time box the way you'd plan a client sprint, and protect the later steps. A useful split for a six-hour brief: about 30 minutes to read and scope, about 3 hours to build the thin slice, an hour to evaluate it, 45 minutes for the write-up, and the rest for the presentation. If the build runs over, cut features — never the evaluation or the write-up. A smaller thing you can measure and explain beats a larger thing you can't.

2 · Scoping in the first 30 minutes essential

A vague brief is deliberate — scoping it is the first thing being tested. "Something that helps the support team" could mean a dashboard, a classifier, a reply drafter, a search tool, or a chatbot. Candidates who pick the most impressive-sounding one and start coding are guessing. The panel wants to see you work out what problem is worth solving, then choose a slice small enough to finish properly. If you can ask the panel questions by email, do it; if you can't, write your assumptions down and state them at the start of the presentation.

Why this works: you grounded the choice in the data, picked one problem with a measurable cost, and made the cuts explicit. That's the work-backward-from-the-outcome habit applied to an interview. It also gives your presentation its opening line: "18% of tickets are misrouted, and those take twice as long. I focused on that."

3 · Building the thin slice intermediate

The goal is one complete path from input to useful output, not a big system with gaps. A thin end-to-end slice means a new ticket goes in and a category suggestion comes out, with a confidence score, and every step in between works. It's small, but it's real, and it can be tested and measured. The alternative — a beautifully designed architecture where the last step isn't wired up — can't be demoed honestly and can't be evaluated at all.

Keep the structure boring and easy to review. The panel will open your repository, and they'll judge it in minutes: can they see what it does, run it in one command, and find the tests? Start with the simplest approach that could work and a baseline to beat — here, a keyword or TF-IDF classifier — and only add an LLM step if it clearly earns its place in the evaluation. A simple baseline is also your safety net: if the clever version underperforms, you still have something that works, and an honest comparison to talk about.

ticket-router/README.md            # what it does, how to run it, results, limits
requirements.txt
data/
  tickets.csv        # the brief's data (or a note on where to put it)
src/
  load.py            # read + clean the CSV, fixed train/test split
  baseline.py        # TF-IDF + logistic regression
  suggest.py         # suggest_category(ticket) -> (category, confidence)
eval/
  evaluate.py        # accuracy + per-category results on the held-out set
  results.md         # the numbers you'll present
tests/
  test_load.py       # empty fields, odd encodings, duplicate tickets
  test_suggest.py    # always returns a valid category + confidence in [0, 1]

The README is short and answers the questions in the order the panel asks them:

README.md# Ticket category suggester

**Problem.** 18% of tickets are filed under the wrong category; those take ~2x longer to resolve.
**What this does.** Suggests a category (with confidence) for a new ticket, for a human to accept.

## Run it
pip install -r requirements.txt
python -m eval.evaluate          # prints accuracy on the held-out set

## Results (held-out 400 tickets)
See eval/results.md.

## Limitations
- Evaluated against existing labels, some of which are themselves wrong.
- Weak on rare categories (fewer than 30 examples).

## Next steps
Confidence threshold tuned with the team; a pilot on live tickets.

Go deeper: testing edge cases · the thin end-to-end slice · ticket classification in a real case study

4 · Evaluating and stating limitations honestly advanced

"How do you know it works?" is the first question in almost every take-home presentation. A demo of a single good example isn't an answer; neither is "it looked good when I tried it." What the panel wants is a number on data the system didn't see during building, compared with something simple, and broken down enough to show where it's weak. That's a small version of a golden-set evaluation, and an hour is enough to do it properly.

Honesty is part of the score, not a weakness to hide. Every take-home solution has gaps — the time box guarantees it — and the panel knows that. What they're testing is whether you know where the gaps are and say so before they find them. A candidate who says "it's weak on rare categories, here's why, and here's what I'd do about it" is far more convincing than one who presents a single accuracy number and hopes nobody asks about the rest.

All the numbers above are made up for this example — in your own take-home they come from your evaluation script, and you show the script. Ending the evaluation on "what I'd do with more time" (better labels for the rare categories, a confidence threshold chosen with the team, a two-week pilot) turns the limitations into a plan.

Go deeper: the evaluation pyramid · building a golden set · evaluation in production

5 · The write-up intermediate

Many panel members will read only one thing you produce, and it's the write-up. The engineer on the panel may open the code; the product manager and the person playing the client won't. One page, in plain language, that a busy reader can follow in three minutes is worth more than a long document nobody finishes. Write it for the least technical person in the room, and put the result near the top rather than making them read the method first.

writeup.mdProblem      18% of tickets are misrouted; they take ~2x longer to resolve.
What I built A category suggester an agent can accept or override.
Result       84% accurate on 400 unseen tickets (keyword rules: 63%);
             95% accurate on the 70% of tickets where it's confident.
How          TF-IDF classifier; an LLM re-check on low-confidence tickets
             adds 4 points at extra cost — optional.
Limits       Weak on rare categories; labels are imperfect; not tested live.
Not built    Chatbot, auto-replies, dashboard — possible later steps.
Next         Two-week pilot with one team; measure misrouting and time to
             resolve against the current baseline.

Why this works: the reader gets the problem, the result, and the decision they're being asked to make before they reach anything technical. The "Not built" line answers "why didn't you also do X?" before anyone asks it.

Go deeper: writing at the right altitude · metrics executives care about

6 · The presentation professional

The presentation is where a good take-home turns into an offer — or doesn't. The panel is usually playing the client: they want to know whether this helps them, whether they can trust it, and whether they'd want you in the room with their real stakeholders. A tour of your code answers none of those. A clear story does: here's your problem, here's what I built, here's proof it works, here's where it doesn't, here's what I suggest next.

Keep to about six slides for 15–20 minutes, and leave at least a third of the slot for questions. Rehearse the timing out loud at least once; nearly everyone runs long the first time.

Demo safely. Live demos fail at the worst moment — Wi-Fi, an API rate limit, a laptop update. Run the demo locally where you can, have the outputs pre-computed for your chosen tickets, and keep a short screen recording as a fallback. If something breaks, switch to the recording calmly and say so; how you handle a failure is part of what's being watched (see the client-simulation round).

Speak to the panel as a client. Use their words ("tickets", "routing", "agents"), not yours ("TF-IDF", "F1"). When a technical detail matters, give the plain version first and the technical term second. Look at the person who asked the question, not the screen.

Go deeper: talking about ROI · presenting risks · presenting your work in a portfolio

7 · Handling the Q&A and pushback professional

The questions are where the panel tests whether your choices were judgment or luck. Expect challenges to your approach, your numbers, and your timeline, sometimes delivered with deliberate impatience to see how you react. The pattern that works for all of them: acknowledge the question, give the reason behind your choice in one or two sentences, say what would change your mind, and offer a concrete next step. Never get defensive, and never promise something you can't back up.

Why this works: each reply shows you understood the trade-off, keeps the client's goal in view, and turns pressure into a concrete next step. The last question is a classic test — saying "yes, next week" sounds eager but tells the panel you'd overpromise to a real client. The same skills are drilled in depth in FI3 · Client simulation.

8 · Tech-lead — what separates a hire from a strong hire tech-lead

Most candidates who reach this round can build something that works; the difference is in the choices around it. A hire delivers a working solution with tests, a measured result, and a clear presentation. A strong hire does all of that and shows the judgment a client would pay for: they picked the problem that mattered most, cut scope early and said why, owned the trade-offs instead of hiding them, and left the client with a decision and a path rather than just a demo.

In practice, that shows up in a few specific signals. They tie the work to a business number from the start ("misrouting costs twice the resolution time"). They compare against a simple baseline instead of presenting a number on its own. They name limitations before anyone asks, and propose how to close them. They think about the people who'll use it — the support agents who need to trust the suggestion, the team lead who needs to measure it. And in the Q&A they disagree politely when they should, rather than agreeing to whatever the panel suggests.

None of this needs more code. It needs the same habits as the rest of this track: understand before you build, measure what you claim, and communicate so that a client can act on it. That's why the take-home is so often the deciding round — it's the job in miniature.

Go deeper: managing the pull to over-build · scaling the method · growing to tech-lead

Knowledge check check yourself