What a system design round actually tells you

I went in assuming the best candidates would produce the cleanest diagrams.

Across a lot of sessions, it has turned out closer to the opposite. The people I would hire tend to start with something rough. They put a box down, talk, cross it out, move it, redraw it three shapes later when the conversation makes the first version wrong. By the end the canvas is a mess with a good design somewhere inside it.

The neat ones worry me more than they used to. A diagram that arrives fully formed and never changes is usually a diagram that was decided before the conversation started. That is not thinking. That is recall, and recall is the thing a system design round is least useful for testing.

The tell

The strongest candidates do not start by drawing.

They spend the first stretch working out what the problem actually is. How many users. Read-heavy or write-heavy. What has to be consistent and what can be stale for a minute. What happens at the worst hour of the worst day. Only then do they start putting things on the canvas, and by that point the shape of the answer is already half-determined by the constraints they surfaced.

Weak answers are often the more polished ones. Fluent, confident, well-organised — and generic. The giveaway is simple: you could hand that candidate a completely different problem and get back substantially the same architecture. Load balancer, application tier, cache, database, queue, CDN. It is a sensible diagram. It is also a diagram of nothing in particular, and it has been drawn from memory rather than derived from anything you said.

Once you know to look for it, it is hard to miss. The question to ask yourself at the end of a round is not "is this a good design?" It is "is this a design of this problem?"

The question I have mostly retired

"Design a URL shortener."

It was a good question once. It is now one of the least informative rounds you can run, because almost every experienced engineer has met it, read the write-up, and has an answer ready. What comes back is a memorised checklist delivered smoothly. Two candidates with completely different design ability will give you near-identical answers, which means the round has told you nothing except which of them revised more recently.

The same has happened to most of the canonical prompts. Design Twitter. Design a rate limiter. Design a parking lot. They have all been solved in public, at length, with diagrams.

What still works is a problem with a constraint that makes the standard answer wrong. Not an obscure problem — an ordinary one with something specific attached. The company genuinely cannot lose a single record. The data cannot leave one country. There is a hard cost ceiling. Traffic is flat all week and then twenty times higher for six hours. Any of those breaks the memorised template, and the candidate has to actually reason, which is the entire point of the round.

What most interviewers get wrong

They evaluate the final architecture against the one they would have drawn themselves.

I understand the instinct. It is the only fixed reference point in the room. But it turns a round about reasoning into a round about agreement, and it quietly penalises anyone who arrives somewhere unfamiliar for good reasons. Two engineers can design the same system differently and both be right; that is most of what senior engineering is.

The things that actually carry signal are all in the process rather than the picture. What did they ask before they committed to anything. What did they assume, and did they say so out loud or bury it. When you changed a requirement halfway through, did the design bend or did they defend a decision that no longer made sense. Can they say what they gave up — because every real design gives something up, and a candidate who cannot name their own trade-off has not made one.

This is the same failure as four interviewers asking four versions of the same question. The room feels rigorous. It is measuring one thing repeatedly.

Change something in the middle

The single most useful thing I know to do in a design round is move the ground under the candidate once they are committed.

Halfway through, after the design is up and they are pleased with it, change a requirement. Ten times the write volume. The consistency guarantee they assumed no longer holds. The region they were storing data in is no longer available. Then say nothing and watch.

You learn more in the next four minutes than in the preceding twenty-five. Some people go quiet, then start unpicking the specific part that broke. Some defend the whole design on reflex. Some cheerfully throw away a component they spent ten minutes building because it is now the wrong component — and that willingness is, in my experience, one of the better predictors of how somebody will behave when a real system surprises them at two in the morning.

It is also the part that is genuinely hard to prepare for, which is why we built the rounds to change while the candidate is still in them rather than run a script to the end.

What the canvas is for

Which brings me back to the mess.

I had thought of the drawing surface as a place to produce an artefact — the diagram is the output, so a better diagram means a better candidate. That is not what it is. It is a window into someone's working, and working is not tidy.

The crossings-out are the evidence. They show where somebody changed their mind, what made them change it, and how quickly they were willing to abandon something they had already invested in. A perfect diagram hides all of that. A messy one hands it to you.

I no longer read a clean canvas as competence. I read it as a question I have not asked yet.