Scoping the Problem

"Design Twitter" is not a question, it is an invitation to ask questions. Candidates who start drawing boxes immediately are answering a problem nobody posed, and it is the most common way a strong engineer produces a weak interview.

Establish scale before architecture. Ten thousand users and ten million users are different systems. Ask for daily active users, read/write ratio, and payload size, then do the arithmetic out loud — 10M DAU each posting once a day is roughly 115 writes per second, and reads at 100:1 make 11,500 reads per second. That number is what justifies every later decision, and stating it converts opinion into reasoning.

Cut scope explicitly. "I'll design the posting and timeline read paths, and treat search and notifications as out of scope unless you want them" shows judgement and buys you time to go deep. Interviewers rarely want breadth; they want to see one thing designed properly.

Name the non-functional requirements. Latency target, availability target, consistency needs, retention. These decide the architecture more than the features do — "must serve a timeline in under 200ms" forces precomputation, and saying so makes your fan-out-on-write decision obvious rather than arbitrary.

Write assumptions down where the interviewer can see them. It makes them correctable, and an interviewer correcting an assumption early is the cheapest feedback you will get.

Separate the constraints from the preferences. "It has to survive Black Friday" is a constraint and it changes the design. "It should use the same database as the other service" is often a preference wearing a constraint's clothes, and it is worth establishing which before you design around it. The question that settles it is what happens if we do not: a constraint has a specific answer, and a preference has a shrug.

The same move works outside an interview, where the ambiguity is larger and nobody is grading you. A ticket reading "make the export faster" is the identical shape of problem: who is asking, how slow is it now, how fast is fast enough, and which exports actually matter. Half an hour turning that into a bounded problem routinely saves a week of building the wrong thing — and it is the part of the job most easily mistaken for not having started.

The underlying signal: can you turn an ambiguous request into a bounded problem? That is the job, at work and in the interview.