The easiest way to stumble in a system design interview is to start drawing boxes and arrows without first asking what you’re actually building. Strong candidates slow down and begin with context: What’s in scope? What limits do we face? Where will we make trade-offs?
Getting this part right sets the tone for the entire interview. It shows you think like a senior engineer who values clarity over speed, and it prevents you from over-engineering features that were never required.
What to lock before architecture
Before the architecture diagram, lock the minimum context that will change the design. You do not need a full product spec; you need enough to avoid solving the wrong problem.
- Users: Who uses the experience, and are there admin, creator, or viewer roles?
- Core flow: What is the single happy path that must work in v1?
- Scope: Which features are included now, and which are explicitly out of scope?
- Constraints: Which device, network, scale, accessibility, security, and business limits matter?
- Success metrics: Which product and technical outcomes prove the design works?
First 5-8 minutes script
The opening minutes should sound structured, not hesitant. Use a short script to create room for requirements without spending the whole interview there. Think of this as the first 5 minutes system design interview requirements pass: enough to expose scope, risk, and trade-off framing before architecture.
- Restate the prompt: “I’ll design the frontend experience for X, then call out the API contracts I need.”
- Anchor the user flow: “Is the primary flow search, browse, create, or monitor?”
- Separate must-haves: “For v1, which features are required, and which can be stretch goals?”
- Ask frontend constraints: “Do we care about SEO, offline use, realtime updates, accessibility, mobile performance, or localization?”
- Confirm success: “Should I optimize for first load, interaction speed, reliability, developer velocity, or all of them?”
- Close the loop: “I’ll assume X and Y for now, and I’ll revisit them if they change the architecture.”
Clarify the scope
Interview prompts are almost always vague on purpose—things like “Design an image gallery” or “Build a chat system.” If you jump straight into drawing, you’ll likely design the wrong thing. The first move is to narrow the scope into something concrete by asking:
- Who are the users? Consumers, admins, or both?
- What’s the core feature set? The must-haves for v1.
- What’s out of scope? Call it out so you don’t waste time on extras.
For example: if asked to design a chat app, clarify whether it’s 1-to-1 only or if it needs group chats, file sharing, and reactions. By setting boundaries early, you make the problem manageable and show the interviewer you’re thinking like a product owner, not just a coder.
Frontend constraints checklist
Every real system has limits—ignoring them leads to designs that look good on a whiteboard but fall apart in practice. Great candidates surface constraints early and use them to shape their design. Treat this as a frontend system design requirements checklist that separates functional requirements from non-functional requirements before you choose rendering, state, or transport patterns.
| Constraint | Questions to ask | Design impact |
|---|---|---|
| Product goal | Is the goal conversion, collaboration, monitoring, content discovery, or creation? | Changes the primary route, state model, and what you optimize first. |
| Users and roles | Are there viewers, editors, admins, anonymous users, or paid users? | Changes auth boundaries, permissions, navigation, and empty states. |
| Scale | How many users, records, comments, widgets, or notifications are visible at once? | Changes pagination, virtualization, batching, cache keys, and rendering strategy. |
| Devices and network | Do we support low-end mobile, slow networks, or desktop-only usage? | Changes performance constraints, bundle budget, image strategy, prefetching, and graceful loading. |
| Data freshness | Can data be stale for seconds or minutes, or must it be realtime? | Changes polling, WebSocket/SSE, invalidation, optimistic updates, and stale UI. |
| Offline and recovery | Should the app work offline, queue writes, or only recover from transient failures? | Changes offline support, storage, conflict resolution, retry policy, and sync feedback. |
| Accessibility and security | Do we need WCAG support, keyboard flows, announcements, XSS protection, or permission boundaries? | Changes accessibility requirements, component contracts, focus management, sanitization, and API assumptions. |
| Observability and success | Which events, errors, performance metrics, and rollout signals should be tracked? | Changes instrumentation, budgets, alerting, and how you validate the design. |
For example: if you’re designing an image-heavy site for a global audience, constraints like unreliable networks and mobile usage might push you toward aggressive image compression, CDNs, and lazy loading from day one.
Trade-off matrix
Every architectural choice comes with downsides. Interviewers don’t expect you to find a “perfect” solution — they want to see that you can recognize trade-offs, say them out loud, and connect them to the problem at hand.
| Decision | Choose this when | Choose the alternative when | Phrase to say |
|---|---|---|---|
| CSR vs SSR | CSR fits authenticated tools, faster iteration, and lower server complexity. | SSR fits SEO, faster first paint, link previews, or content-heavy pages. | “I’ll start with CSR unless SEO or first paint is a hard requirement.” |
| REST vs GraphQL | REST fits simple resources, stable contracts, and easier caching. | GraphQL fits many view-specific shapes, nested data, and client-driven composition. | “The API shape should follow the view model and caching needs.” |
| Local vs global state | Local state fits isolated UI behavior and one-owner data. | Global state fits cross-route ownership, shared auth/user settings, or synchronized panels. | “I’ll keep state local until ownership crosses component or route boundaries.” |
| Optimistic vs pessimistic updates | Optimistic updates fit reversible actions where perceived speed matters. | Pessimistic updates fit payments, destructive actions, or high-conflict data. | “I’ll optimize the interaction only where rollback is safe and understandable.” |
| Polling vs WebSocket/SSE | Polling fits low-frequency updates and simpler infrastructure. | WebSocket/SSE fits realtime collaboration, live comments, notifications, or streams. | “I’ll match the transport to the freshness requirement instead of defaulting to realtime.” |
| Offline now vs later | Defer offline when the product can show clear recovery and retry states. | Build offline early when mobile, travel, field usage, or draft persistence is core. | “I’ll separate transient failure recovery from full offline-first complexity.” |
The key is to say the trade-off out loud and tie it to context. For example: “For v1, I’d start with CSR to move quickly. If SEO or first paint becomes a priority, we can layer SSR later.” That shows you understand not just the options, but the timeline and context where each option makes sense.
Prompt examples
The same foundations change shape depending on the prompt. Practice asking sharper questions before you open the architecture section.
- Real-time Search: clarify latency target, stale response behavior, cache lifetime, keyboard UX, and empty/error states.
- News Feed: clarify feed ranking, cursor pagination, media loading, realtime updates, moderation, and offline read behavior.
- Notification Toast: clarify global API ownership, stacking, timers, announcement behavior, and queue limits.
Common mistakes before architecture
- Drawing too early: architecture before scope usually solves a different problem.
- Missing non-functional requirements: performance, accessibility, realtime, offline, and security often change the design.
- Over-scoping v1: senior answers separate required behavior from future expansion.
- Naming options without trade-offs: “SSR” or “WebSocket” is not enough unless you explain why it fits.
- Ignoring interviewer priority: if they hint at performance or reliability, move that constraint forward.
Next step
Before you ever draw a box or arrow, lock in the foundations. Strong candidates pause to set the stage instead of rushing ahead. Your mental checklist should be:
- Scope: What’s in, what’s out, and who the users are.
- Constraints: The limits you must respect — scale, performance, devices, business needs.
- Trade-offs: The options you’ve weighed and why you chose one over the others.
Then go deeper on the RADIO requirements step and move into architecture decisions. Getting these three right makes the rest of your design more credible.
FAQ
What requirements should I clarify in a frontend system design interview?
Clarify users, core flow, included and excluded features, device and network assumptions, data freshness, accessibility, security, performance budgets, and success metrics.
How long should requirements clarification take?
In a 45-minute frontend system design interview, spend roughly the first 5-8 minutes on scope, constraints, and trade-offs before moving into architecture.
What frontend constraints matter most before architecture?
The constraints that usually change architecture are SEO, realtime freshness, mobile performance, low-connectivity behavior, accessibility, auth boundaries, data volume, and observability requirements.
How do I explain trade-offs in a frontend system design interview?
Name the decision, connect it to the requirement, state what you gain, state what you give up, and explain when you would revisit the choice.
What mistakes should I avoid before drawing architecture?
Avoid drawing before scope is clear, skipping non-functional requirements, making every feature v1, naming tools without trade-offs, and ignoring interviewer priorities.