Requirements Gathering and Constraints

The Most Important 5 Minutes You'll Ever Spend

Here's a pattern I've seen hundreds of times in system design interviews: the candidate hears "Design a news feed" and immediately jumps to component trees and API shapes. Twenty minutes later, they've built an elaborate architecture for the wrong problem. The interviewer wanted a read-heavy infinite scroll feed, and the candidate built a real-time collaborative editing surface.

The first 5 minutes of a system design interview aren't a warm-up. They're the entire foundation. Skip them, and you're building a skyscraper on sand. Nail them, and the rest of the interview almost designs itself.

Staff-level engineers don't wait for requirements to be handed to them. They extract requirements through structured, deliberate questioning. This is the skill that separates a mid-level "tell me what to build" engineer from a staff-level "let me figure out what we actually need" engineer.

Functional Requirements — What Does It Do?

Functional requirements describe the features and behaviors the system must support. They answer: "What can a user do with this?"

In an interview, you should aim for 3-5 core functional requirements. Not 15. Not every edge case. The core user flows that define the product.

How to Extract Them

Start with the primary user action. What's the single most important thing a user does?

Interviewer: "Design Twitter."

You: "The core action is composing and publishing a tweet.
From there, I see these primary flows:

1. Compose and post a tweet (text, images, links)
2. View a personalized home feed of tweets
3. Interact with tweets (like, retweet, reply)
4. View a user profile with their tweets

I'd explicitly exclude DMs, Spaces, notifications,
and search for now — happy to add if time permits.
Is this the right scope?"

Notice the structure: state what you include, state what you exclude, ask for confirmation. This gives the interviewer a clear signal that you think in terms of scope, not just features.

User Stories vs. Feature Lists

A feature list says "Support image upload." A user story says "A user can attach up to 4 images to a tweet and preview them before posting." The difference matters because user stories expose hidden complexity:

• What image formats are supported?
• What's the max file size?
• Do we resize/compress client-side before upload?
• What happens on a slow connection — do we show upload progress?

Every user story is a thread you can pull to uncover edge cases. In an interview, you don't need to pull every thread — but showing the interviewer you see the threads is what earns staff-level ratings.

Non-Functional Requirements — How Well Does It Do It?

This is where most candidates fall flat. They'll spend 10 minutes on features and zero seconds on performance, accessibility, or internationalization. But non-functional requirements (NFRs) are often more architecturally significant than functional ones.

A news feed that loads in 200ms vs. 5 seconds requires fundamentally different architectures. A dashboard that must work offline vs. always-online changes everything about your data layer. NFRs drive architecture decisions.

Performance Budgets

For frontend system design, you should proactively state performance targets using Core Web Vitals:

• LCP (Largest Contentful Paint): Under 2.5s for the primary content. For content-heavy apps like a news feed, this means the first meaningful post must render within 2.5s
• INP (Interaction to Next Paint): Under 200ms for all interactions. This constrains how you handle filtering, sorting, and real-time updates
• CLS (Cumulative Layout Shift): Under 0.1. This affects how you load images, ads, and dynamic content — skeleton screens, dimension attributes, and font loading strategies

"For a news feed, I'd target LCP under 2.5 seconds on
a mid-tier mobile device over 4G. That means the first
3-5 posts must render from the initial HTML payload or
a single API call — no waterfall of secondary requests
before meaningful content appears."

Accessibility

Don't just say "we'll make it accessible." Specify the level and what it implies:

• WCAG 2.1 AA (industry standard) — 4.5:1 contrast ratio for text, keyboard navigable, screen reader compatible, focus management for dynamic content
• WCAG 2.1 AAA (gold standard) — 7:1 contrast ratio, sign language for media, more stringent timing requirements

For a news feed, accessibility means: infinite scroll must be keyboard-navigable (not just mouse-wheel), new content insertion must be announced to screen readers, and focus must be managed when items are added or removed.

Internationalization and RTL

If the product serves a global audience, i18n is architectural:

• RTL layout support — flexbox and grid direction, icon mirroring, text alignment. This affects your entire CSS strategy
• Content translation — static UI strings vs. user-generated content. Do you need Unicode support for CJK characters, Arabic ligatures, emoji?
• Date/number formatting — Intl.DateTimeFormat, Intl.NumberFormat. Locale-aware formatting throughout

Responsive Breakpoints and Device Targets

State your breakpoint strategy explicitly:

• Mobile-first (320px baseline) — the primary experience
• Tablet (768px) — adapted layout, not just squeezed desktop
• Desktop (1024px+) — full experience with multi-column layouts

Specify device constraints: "I'm designing for mid-tier Android devices (2-4GB RAM, mid-range CPU) as the baseline. High-end devices get progressive enhancement."

Offline Support

This is a binary architectural decision with massive implications:

• Online-only — simpler architecture, real-time data, no sync conflicts
• Offline-capable — service workers, IndexedDB for local storage, sync queue for mutations, conflict resolution strategy

The Clarifying Questions That Impress Interviewers

Good clarifying questions aren't random. They follow a pattern: each question should either narrow the scope or reveal an architectural constraint. Here's the framework:

The SCOPE Framework for Questions

S — Scale: How many users? What's the read/write ratio? How much data per user?

C — Constraints: Must it work offline? Any browser/device restrictions? Existing API contracts we must use?

O — Operations: Who creates content? Who moderates? Are there admin-specific views?

P — Performance: What's the latency tolerance? How fresh must data be? Are there SLAs?

E — Edge cases: What happens when the network drops? What about empty states? What does the error state look like?

Questions That Signal Seniority

These specific questions consistently impress interviewers because they reveal deep frontend thinking:

"What's the expected read-to-write ratio? A 1000:1 ratio
means I'd optimize the read path aggressively — static
generation, aggressive caching, CDN edge delivery."

"Should the UI be optimistic or confirmed? For a like
button, optimistic updates feel instant. For a payment
button, we need server confirmation before showing success."

"What's the target device baseline? If we're targeting
budget Android phones on 3G, that rules out heavy client-
side rendering and pushes us toward server rendering with
progressive enhancement."

"Do we need to support deep linking? If users share URLs
to specific states (e.g., a filtered view), the state
needs to live in the URL, not just component state."

Questions to Avoid

Never ask questions where the answer doesn't change your architecture:

• "What color should the buttons be?" — Doesn't affect architecture
• "Should we use React or Vue?" — You choose the tools, not the interviewer
• "How many engineers will work on this?" — Irrelevant for system design

Scope Management — The Art of Saying No

Scope management is the single highest-signal skill in a system design interview. Anyone can list features. It takes a staff engineer to draw the line between MVP and stretch goals, and to explain why the line is where it is.

The MVP Boundary

Your MVP should include the minimum set of features that makes the product usable for the primary use case. Nothing more.

For a news feed:

• MVP: View feed, compose post (text only), like a post, infinite scroll
• Stretch: Image/video posts, comments, share, real-time updates, notifications
• Out of scope: DMs, stories, live streaming, ads system, recommendation algorithm

State this explicitly to the interviewer. It shows you can prioritize.

Time-Boxing Your Design

In a 45-minute interview, your time allocation should look like this:

If you spend 15 minutes on requirements, you've already lost. If you spend 0 minutes, you've definitely lost. The sweet spot is 5-7 minutes — enough to establish a solid foundation without eating into design time.

Explicit Exclusions

This is an underrated move: explicitly state what you're not building and why. It shows you thought about it and made a deliberate decision, rather than just forgetting about it.

"I'm explicitly excluding the notification system from
this design. Notifications are important but architecturally
independent — they'd need their own WebSocket connection,
service worker registration, and permission flow. I can
sketch that if we have time, but I'd rather go deep on
the feed rendering and data synchronization first."

That single statement tells the interviewer you understand the notification system's complexity, you made a prioritization call, and you're open to discussing it if they want. That's staff-level thinking.

User Types and Personas

Different users have different needs, permissions, and interaction patterns. Identifying them early prevents architectural blind spots.

Common Persona Splits

Authenticated vs. Anonymous: Anonymous users see a degraded experience (no personalization, no mutations). This affects your rendering strategy — anonymous users can get static/cached pages, authenticated users need personalized server-rendered or client-rendered content.

Admin vs. Regular User: Admins need moderation tools, analytics dashboards, content management. This is often a completely separate app or route group, not just extra buttons on the same UI. Don't mix admin and user architectures.

Power User vs. Casual: Power users want keyboard shortcuts, dense information displays, bulk actions. Casual users want simplicity and progressive disclosure. The same feature might need two different interaction patterns.

Creator vs. Consumer: On a platform like YouTube, creators need upload flows, analytics, and editing tools. Consumers need a feed, player, and search. The creator experience is often 10x more complex and should be code-split aggressively.

How Personas Affect Architecture

Persona: Anonymous user viewing a news feed

Implications:
- No auth token → can use CDN-cached pages
- No personalization → same content for all anonymous users
- Server-rendered HTML for SEO and performance
- No mutation capabilities → read-only API calls
- Conversion funnel: prompt to sign up after scrolling

Persona: Authenticated power user

Implications:
- Auth token in every request → no CDN caching for personalized content
- Personalized feed → server-rendered with user-specific data
- Full mutation support → optimistic updates for likes/retweets
- Keyboard shortcuts → global key listener, focus management
- Preferences → stored server-side, synced on login

Scale and Constraints

Scale in frontend system design isn't about database sharding or server clusters. It's about how the client handles volume: large DOM trees, frequent updates, memory pressure, and degraded network conditions.

Client-Side Scale Concerns

DOM volume: A feed with 10,000 items cannot render all 10,000 DOM nodes. You need virtualization (react-window, tanstack-virtual) to keep only visible items in the DOM. State this proactively — it tells the interviewer you understand the rendering cost of large lists.

Update frequency: A real-time dashboard updating 50 metrics per second needs batched updates to avoid layout thrashing. You can't re-render on every WebSocket message. Debouncing, requestAnimationFrame batching, or a streaming architecture with selective updates becomes necessary.

Memory constraints: A chat application open for 8 hours accumulates messages. Without a sliding window (keeping only the last N messages in memory and fetching older ones on scroll-up), you'll exhaust mobile device memory. Specify your retention strategy.

Data volume per item: A photo gallery where each item has a 5MB high-res image needs lazy loading, progressive image loading (blur-up or LQIP), and possibly a virtual scroll that unloads off-screen images.

Network Conditions

Always specify your network baseline. The difference between "fast 4G" and "slow 3G" changes your entire strategy:

Technology Constraints

In an interview, you pick the technology — but you should justify your choices based on the requirements you just gathered.

Framework Selection Rationale

Don't just say "I'll use React." Explain why:

"Given the requirements — a read-heavy news feed with SSR
for SEO, real-time updates, and aggressive code-splitting —
I'd use Next.js with React Server Components. RSC lets me
keep the feed rendering on the server (zero client JS for
the post content), stream the initial page for fast LCP,
and hydrate only interactive elements like the like button
and comment form."

Browser and Device Support

State your support matrix. It has real architectural impact:

• Modern browsers only (last 2 versions): You can use modern CSS (container queries, :has(), subgrid), ES2022+ without heavy polyfills, and native features like IntersectionObserver and ResizeObserver
• Including IE11 or older Safari: You need polyfills, transpilation to ES5, and fallbacks for CSS Grid, custom properties, and modern APIs. This adds 50-100KB to your bundle

API Constraints

Sometimes the API already exists and you're designing around it:

• REST with pagination: Your feed needs cursor-based pagination UI, loading states, and a strategy for new items appearing while scrolling
• GraphQL: You can request exactly the fields you need per component, reducing over-fetching. But you need a client-side cache (Apollo, urql) that adds to bundle size
• WebSocket/SSE for real-time: You need connection management, reconnection logic, message buffering, and a strategy for initial load (HTTP for first paint, then WebSocket for updates)

Worked Example — "Design a News Feed"

Let's walk through a complete requirements gathering for the classic news feed problem. This is what the first 5-7 minutes of a staff-level interview sounds like.

Step 1: Clarify the Product

"Before I start designing, I'd like to clarify the product scope. When you say 'news feed,' I'm thinking something like Twitter's home timeline — a personalized stream of posts from people you follow, displayed in reverse-chronological or algorithmic order. Is that the right mental model, or are we talking about something different like an RSS reader or a news aggregator?"

This immediately shows you don't make assumptions. The interviewer might say "yes, like Twitter" or redirect you — either way, you've avoided building the wrong thing.

Step 2: Define Functional Requirements

"Great. Let me define the core functional requirements for our MVP:

1. View feed — An infinite-scrolling list of posts from followed users, newest first
2. Compose a post — Text content with an optional single image attachment
3. Interact with posts — Like and unlike (toggle), with visible like count
4. View user profiles — Tap on an author to see their posts

I'm explicitly scoping out: comments/replies, retweets/shares, notifications, DMs, search, trending topics, and the follow/unfollow flow (I'll assume the user already follows people). I can add any of these if we have time. Does this scope work?"

Step 3: Define Non-Functional Requirements

"For non-functional requirements:

Performance: LCP under 2.5s on a mid-tier Android phone over 4G. That means the first 5 posts must render from the initial server response — no client-side waterfall before meaningful content. INP under 200ms for like interactions.

Accessibility: WCAG 2.1 AA. Keyboard-navigable feed, screen reader announcements for new posts and like confirmations, focus management when reaching the end of loaded content.

Responsive: Mobile-first design, 320px minimum. Three breakpoints: mobile (single column), tablet (single column with wider margins), desktop (feed plus sidebar).

Offline: Online-only for MVP. Users see cached content if they revisit a previously loaded feed, but no offline posting."

Step 4: Identify User Personas

"Two primary personas:

Reader (90% of users): Scrolls the feed, likes posts, visits profiles. Read-heavy. We optimize the read path for this persona — server-rendered feed, aggressive prefetching.

Creator (10% of users): Composes posts. The compose flow is write-heavy — we need image upload with progress, draft autosave, and optimistic post insertion into the feed."

Step 5: Establish Scale and Constraints

"Scale assumptions — I'd like to confirm these:

Users: Let's say 10M DAU with 10% peak concurrency (1M concurrent users). For the frontend, this means CDN-level caching is critical — if even 10% of page loads hit the origin server, that's 100K requests per second during peak.

Data volume: Average user follows 200 accounts. Feed query returns 20 posts per page. Each post is roughly 1-2KB of JSON (text + metadata). So the initial API payload is about 30-40KB — well within budget.

Network: I'll design for 4G as the baseline (10-15 Mbps down, 50ms RTT). For 3G fallback, I'll ensure the initial HTML payload is under 50KB compressed so even slow connections get first paint quickly."

Step 6: Technology Decisions

"Given these requirements:

Framework: Next.js with React Server Components. The feed is read-heavy and benefits from server rendering for LCP. RSC lets me keep post content rendering on the server with zero client JS per post. Only interactive elements (like button, compose form) ship client-side JavaScript.

Rendering strategy: Hybrid. Server-render the initial feed page for fast LCP. Client-side fetch for subsequent pages during infinite scroll. Stream the initial page using React Suspense boundaries — the header renders immediately, the feed streams in as data arrives.

State: URL state for the active view (feed vs. profile). Server state via RSC for feed data. Minimal client state for optimistic like toggles and the compose form draft."

Putting It All Together

Requirements gathering isn't a checklist you memorize. It's a thinking framework that becomes instinctive with practice. The goal is to transform a vague prompt into a precise engineering specification in under 7 minutes.

Every question you ask should pass this test: Does the answer change my architecture? If yes, ask it. If no, skip it.

Every requirement you state should pass this test: Does this constrain a design decision? If yes, include it. If no, it's decoration.

The candidates who get staff-level ratings aren't the ones who ask the most questions or list the most requirements. They're the ones who ask the right questions and state the requirements that matter.