Make the Requirement Annoying

I got tired of a particular kind of interview. The candidate finishes the exercise, I fill in the scorecard, and we both walk out with almost no idea whether we’d work well together. Everyone did their part. Nobody found out much.

The candidate solves a puzzle under a timer, I watch for clues, and we both pretend this resembles engineering. The actual job has docs, search, Slack, fuzzy product language, existing code, and somebody asking on Wednesday whether it can ship by Thursday.

So I took a small interview challenge and turned it into a public project:

• Source code: GitHub repository
• Live demo: interview-eight-rosy.vercel.app

It’s an address book, and it’s ordinary on purpose. The interesting part starts once it works and I move the problem.

The lonely version

The classic format takes away everything engineers lean on all day: the internet, the docs, the helper tools. What’s left is one person, one editor and one timer.

That rewards memory and keeping your cool under pressure. Both help. Neither tells me what happens when two people disagree about a requirement that’s only half written.

And that’s the job. Noticing the ambiguity, asking the slightly uncomfortable question, making a decision you can reverse, and leaving code behind that the next person can pick up without swearing at you.

First, make the boring thing work

We build it together first. An address book is plenty: fetch the data, then search, filter, sort, and render it as responsive cards.

Once it works, I change the brief while we’re both looking at the code. Maybe search has to cope with misspelled names. Maybe results arrive slowly and out of order. Maybe product wants the filter in the URL, by Thursday, naturally.

Now there’s real work to do. We write a tiny spec, argue about trade-offs, sketch an approach and decide what we’re happy to postpone. The candidate doesn’t have to guess which answer is hidden in my head, because I don’t have one either.

That’s when I see who asks the question that changes the task, who can give a vague problem some shape, and who makes a safe decision without pretending it’ll last forever.

What AI changes

AI makes code cheap. It hasn’t made judgment any cheaper. I want to watch the candidate spot the missing failure mode, push back on a vague requirement, and cut the work into pieces we could ship without the next person hating us.

So I watch for the things an agent won’t settle for us:

• Turn a fuzzy idea into a spec small enough to build.
• Split the work into increments that won’t trap the next developer.
• Name failure modes before the demo breaks.
• Explain a technical trade-off without hiding inside jargon.
• Change direction when an assumption dies.

The address book has trapdoors

Pull on almost any corner of this tiny project and a trapdoor opens into another part of the job:

• product thinking (what problem are we actually solving?)
• UX decisions (search behaviour, empty states, mobile-first flows)
• API design (contracts, versioning, error models)
• data modelling (normalisation, indexing, trade-offs)
• algorithm choices (sort/filter strategy, performance implications)
• testing strategy (unit vs integration vs end-to-end)
• reliability (timeouts, retries, graceful degradation)
• security and auth boundaries
• observability (logs, traces, metrics, alerting)
• team collaboration (specs, RFCs, code review style, rollout planning)

We don’t have to visit all of them. One good argument about an empty state tells me more than ten finished algorithm questions.

The question I want to end with

Build version one together, then ask: “where do we take this next, and why?”

I don’t need the candidate to pick my answer. I want to see them pick one, make me understand it, and drop it without drama when the next requirement kills it. There’s always a next requirement. I’m the one writing them.