Make the Requirement Annoying

I got tired of interviews where a candidate completes the exercise, I fill in the scorecard, and both of us leave with almost no idea whether we’d work well together.

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

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

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

The address book is deliberately ordinary. The interesting moment comes after it works, when I move the problem.

The lonely version

The classic format removes the things engineers use all day:

• no internet
• no docs
• no helper tools
• one person, one editor, one timer

It rewards memory and composure under pressure. Those traits help. They still don’t tell me what happens when two people disagree about an incomplete requirement.

The job is noticing ambiguity, asking the slightly uncomfortable question, making a reversible decision, and leaving code behind that another person can pick up without swearing at you.

First, make the boring thing work

Start with a shared build. An address book is enough:

• fetch data
• search
• filter
• sort
• render responsive cards

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

Now we have to write a tiny spec, debate the trade-offs, sketch an approach, and decide what we’re willing to postpone. The candidate no longer has to guess what answer is hidden in my head because I don’t have one either.

I can see who asks the question that changes the task, who can give ambiguity a shape, and who makes a safe decision without pretending it will be permanent.

What AI changes

AI makes code cheap. It does not make judgment cheap. I want to see the candidate notice the missing failure mode, push back on a vague requirement, and split the work into something we could ship without making the next person hate us.

I pay attention to 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

The same small project has trapdoors into almost every 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 need to visit all of them. One good disagreement about an empty state can tell me more than ten completed 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 choose my answer. I want to see whether they can choose one, make me understand it, and abandon it without drama when the next requirement kills it.