Clarifying Requirements and Scoping the Problem

The plain-language idea

"Clarify requirements" is the first step of the interview framework, and it's worth breaking into three concrete pieces for a frontend-specific prompt:

• Functional requirements — what the feature must actually do. For "design a feed," does it need infinite scroll, real-time updates as new items arrive, or is simple paginated loading enough? Each of those is a meaningfully different build.
• Non-functional requirements, frontend-flavored. Not database throughput — things like target devices (mobile web vs. desktop vs. something native-adjacent), offline expectations, and a rough sense of concurrent scale, since scale is what determines whether client-side caching or real-time sync are worth their complexity at all.
• What's explicitly out of scope. A strong candidate names something they're deliberately not designing for, rather than trying to cover everything. Scoping something out is a demonstration of judgment, not a gap in the answer.

See it in a real thing: "design a notification system"

A strong candidate doesn't start designing — they ask questions first, and each answer meaningfully changes the resulting design:

• "Is this push notifications too, or just in-app?" If push is in scope, the design needs a service worker and a backend push provider integration; if it's in-app only, it's a much smaller surface — a badge count and a dropdown fed by existing data.
• "Does this need to be real-time, or is a periodic poll acceptable?" Real-time implies a persistent connection (WebSocket or SSE) and the complexity of managing it; a poll every 30-60 seconds might be entirely sufficient for a notifications feed that isn't time-critical, and it's dramatically simpler to build and reason about.
• "Does read/unread state need to sync across a user's devices?" If yes, "read" has to be a piece of server state the client reconciles against, not local component state — a genuinely different data model than if each device tracks its own read state independently.

Notice that none of these questions are about being thorough for its own sake — each one directly changes what gets built next.

What people usually miss

Watch out

• Naming what's out of scope is not a weakness in the answer — it's evidence of judgment. "I'm going to assume this doesn't need offline support, since the prompt didn't mention it, and I'll flag if that assumption turns out wrong" is a stronger answer than silently trying to handle everything.
• Scale is a non-functional requirement worth asking about even in a frontend round, because it determines whether certain complexity (real-time sync, aggressive caching) is justified at all — the next lesson goes deep on estimating it.
• "What devices/platforms" is an easy question to skip and a costly one to skip — a mobile-web notification feed and a desktop-only one have different constraints (viewport, background execution, push APIs) that shape the whole design.
• Every clarifying question should be one you can imagine changing your design based on the answer. If a question wouldn't change anything, it's not actually scoping the problem — skip it.

Why this matters in interviews

Interviewers routinely leave requirements deliberately ambiguous specifically to see whether a candidate asks, and whether the resulting answers visibly reshape the design that follows — silence here is read as a candidate who designs on autopilot rather than in response to the actual problem.