How to turn a vague prompt like 'design a chat application' into a concrete functional and non-functional requirements list, before drawing a single box.
Published September 22, 2026
Every HLD prompt is deliberately vague — "design a chat application," "design Twitter." The first few minutes of a strong answer are spent making it precise, not designing anything yet.
A weak candidate starts sketching boxes immediately. A strong candidate asks clarifying questions first, because "chat application" alone is compatible with wildly different systems — one-on-one messaging (WhatsApp-scale), group channels (Slack-scale), or massive broadcast channels (Discord-scale) — each implying a completely different architecture. Questions worth asking out loud:
The interviewer usually has specific answers in mind and will narrow the prompt once you ask — the value isn't the questions themselves, it's demonstrating you won't design blind.
Two things to nail down for any prompt, before anything else:
Who are the actors? — e.g. for chat: sender, recipient, (optionally) an admin managing a group. Naming actors explicitly prevents designing a system that silently assumes only one type of user exists.
What are the core use cases? — the minimal verb list the system must support. For chat: send a message, receive a message, view chat history, see online status. Deliberately exclude anything not confirmed in scope (e.g. file attachments) rather than silently designing for it — scope creep in an interview costs you time you don't have.
This is the list that actually drives architecture decisions, not the functional list:
Stating these three explicitly, out loud, before any high-level design is what justifies every later choice — "I'm using WebSockets because we agreed sub-100ms delivery is required" is a design decision with a stated reason; a WebSocket diagram with no stated latency requirement is a guess that happens to be popular.
The most common HLD interview failure isn't a bad final design — it's a good design for the wrong requirements, because none were confirmed. Spending two minutes here is what prevents spending the remaining twenty designing something the interviewer didn't ask for.
Q: What if the interviewer doesn't answer your clarifying questions and just says 'you decide'? A: State your assumption explicitly and move on — e.g. "I'll assume group chats up to 100 members and sub-second delivery, since that's the common case for this kind of system" — this still demonstrates the reasoning, just without waiting on an external answer.
Q: How many clarifying questions is too many? A: Enough to fix the requirements that actually change the architecture (scale, latency, consistency) — not an exhaustive interrogation. Two to four sharp questions read as senior; ten generic ones read as stalling.
Q: Should functional or non-functional requirements be gathered first? A: Functional first — you need to know what the system does before you can meaningfully ask how well it needs to do it. Asking about latency for a feature that turns out to be out of scope wastes the question.
Q: Does this step change for a well-known system (e.g. 'design Twitter') where the answer seems obvious? A: No — even a famous system has scope ambiguity (does 'design Twitter' include the recommendation algorithm? Direct messages? Media uploads?). Stating assumed scope is just as necessary; "obvious" is exactly where unstated assumptions cause the most divergence between what you design and what's expected.
