A consulting firm gave me a take-home problem instead of a list of interview questions. One vague brief, no template, no right answer on file. I did not send back a memo describing what I would do. I built the thing, ran it live in the interview, and was hired before the call ended.
The brief, in their words: clients get so excited that the moment they sign, they start sending questions and tasks the firm does not yet have the background to handle. That was the whole test. The real problems were mine to find.
The fork nobody announces
Every take-home like this hides the same quiet decision, and it gets made before you write a single word. You can describe a solution: a tidy document listing what you would do, which asks the reviewer to imagine the result and trust that you could deliver it. Or you can build a working version: harder to make, and almost impossible to ignore, because it shows the result instead of promising it.
The bet is simple. A description competes with every other candidate's description, and they all draw on the same pool of the reviewer's imagination. A working tool competes with nothing, because nobody else in the process brought one.
What I built
A live onboarding diagnostic, in plain HTML, one file, no backend. It asks the questions a good operator asks in week one, flags the gaps as the answers come in, and assembles a phased fix from what it heard, with a ready-to-use template behind each piece. I styled it to their brand, and I told them plainly that it was theirs to keep whatever they decided.
Building it did something a memo never would have: it forced me to actually understand the problem. A memo can stay vague wherever your understanding is vague. A tool cannot, because every screen demands a concrete answer: which question comes first, what counts as a gap, what the fix actually contains. The single vague brief turned out to be hiding more than a dozen distinct process gaps, and I only know that because the build made me enumerate them.
The call itself
The test was framed as a presentation. I turned it into a working session instead. I asked the tool's discovery questions out loud and let them answer in their own words. I typed their answers straight in as we spoke, so they watched their own situation take shape on the screen. Then the solution assembled itself from what they had just told me. Nothing generic, nothing pre-baked, all of it theirs.
That one move changed the room more than the tool did. A candidate being tested became a colleague solving a problem, and that is a far better room to be in. It is also a room you can choose to create.
What actually sold it
Two things, as far as I can tell. They could see it working: usable, real, shaped to how they operate, nothing left to take on faith. And the work stayed with them: they ended the call holding a tool they could keep, and a first-hand picture of how I think and how I ship.
Worth being precise about the evidence here. This is one hire, one room, one firm whose pain happened to be process-shaped, which is exactly the shape a tool answers. The method travels; the guarantee does not. What generalises is the trade underneath it: effort spent before the meeting converts into credibility inside it at a rate nothing else matches.
If you are facing a test like this
Build, do not just describe. A working thing beats a perfect memo. Make the smallest real version you can: one workflow, one file, real content throughout, their palette, their words.
Turn the test into a working session. Ask, capture, and let the answer come from them. Collaboration beats performance even when the artifact is ordinary.
Solve their problem, not a generic one. Adapt to their exact language and let them keep the result. Specific is what feels real.
Show up having already started. Arrive with something real in your hands, not a plan to make one later.
And know when not to. If the brief is judgement-shaped rather than process-shaped, the analysis is the deliverable and a tool wrapped around thin analysis advertises the thinness. If they set a two-hour limit, honour it. If the scope has two readings that produce two different tools, ask first. The full version of that chapter, and the build checklist I now run before any interview like this, is in the playbook below.