Cruxly › System design › Running the Design Interview

Scoping the Problem

narrow the prompt before you build anything

You have been given a three-word prompt: "design a chat app", "design a ride service". It is deliberately under-specified. Your first job is to turn it into a problem with edges.

Work through the sections, then use them as your live script for the first eight minutes of a real interview.

Why the prompt is vague on purpose

The vagueness is the test. An interviewer who wanted a spec would have given you one.
What they want to see is whether you can choose a spec and own it.

Same prompt, same forty minutes. The only difference is that one candidate decided where the effort would go.

Two candidates get "design a chat app."

Candidate A — no questions asked. Builds a system that stores messages, delivers in real time, handles group chat, does read receipts, supports media, works offline, and syncs across devices. Result: forty minutes of shallow boxes.
Candidate B — scoped in 90 seconds. "I'm going to build one-to-one text messaging with delivery and read receipts, for mobile clients that go offline. I'm explicitly not doing group chat, media or search — tell me if you'd rather I swap one in."

:::key What just happened in ninety seconds

The second candidate now has a problem small enough to design properly, and has demonstrated judgement before drawing a single box.
The offer to swap is what makes it collaborative rather than presumptuous.

:::

Functional requirements: pick three

Write down the three things the system must do, phrased as a user action and its observable effect:

A user sends a message to another user; the recipient sees it within a second if online.
A user who was offline receives everything they missed, in order, on reconnect.
A sender can see whether their message was delivered and whether it was read.

:::key Why exactly three

Two is thin enough that the interviewer will add work themselves.
Five will not fit in the time, and you end the interview having designed nothing to sufficient depth.
If you genuinely need a fourth, drop one first — the count is a budget, not a target.

:::

"We need a message queue."
→ a component. A decision you haven't earned yet.

"A user who was offline receives everything they missed, in order,
 on reconnect."
→ observable behaviour. The queue is now something you can argue for.

Non-functional requirements: pick two to optimise for

These are the ones that actually shape the architecture, and candidates skip them.

Naming which two you optimise for, out loud, is the requirement — the other three don't vanish, they become named, accepted costs.

Property	The question to ask	What it forces
Latency	What is unacceptably slow, in ms?	Caching, edge placement, denormalisation
Availability	What happens if it is down for 5 minutes?	Replication, failover, graceful degradation
Consistency	Can two users legitimately see different answers?	Quorums, single-writer, conflict resolution
Durability	Is losing one record a bug or a disaster?	Replication factor, write acknowledgement
Scale	How much does this grow in two years?	Partitioning strategy

:::key Pick two, and name the sacrifice

You cannot maximise all five, and saying so explicitly is a strong move rather than a hedge.
Now every later decision in the interview has something concrete to point back at — and when you trade something away, it reads as deliberate rather than as an oversight.

:::

Write down the non-goals

Say them out loud and leave them visible on the board:

Out of scope: group chat, media attachments, full-text search, end-to-end encryption, web clients.

Writing down non-goals doesn't avoid the hard question — it moves it from a moment you have no time left, to a moment you do.

This does three things:

It stops you accidentally designing them.
It tells the interviewer you know they exist — so they won't score you down for the omission.
It gives them a menu: if end-to-end encryption is the thing they wanted to probe, they'll now say so early, while there's still time to respond.

The questions worth asking

Ask few, ask sharp. Every question should be one whose answer changes your design.
If the answer wouldn't change anything, don't spend the time.

Ask this	Because it changes…
"Roughly how many users, and is traffic global or one region?"	Partitioning, and whether you need multi-region at all
"If a user is offline a week, do they get everything or a cap?"	Whether per-user storage is bounded
"Is it acceptable for a message to be delivered twice?"	Whether you need idempotency keys — a whole component

Don't ask this	Why
"What's the tech stack?"	Almost never matters at this level
"Do we have a budget?"	Unanswerable in an interview
"Should it be scalable?"	Yes. Always yes.

:::warn When they deflect — and they often will "You decide."

Decide out loud and move on. "Then I'll assume 50 million users, mostly one region — I'll flag where that assumption matters."
Never stall waiting for permission. The deflection is frequently itself part of the test.

:::

How to say it in the interview

"Before I design anything, I want to pin down scope — I'd rather build a small system well than a large one vaguely. Let me propose three user-facing features and check with you whether that's the right cut."

Checklist

Stated three functional requirements as user-observable behaviour
Named two non-functional properties to optimise, and what is being traded away
Wrote non-goals on the board explicitly
Asked at most four questions, each one whose answer changes the design
Stated the assumption yourself when the interviewer deflected
Said the time budget out loud

Practice this interactively