Requirements Gathering in Mobile System Design Interviews

A few years ago, I watched a candidate get the prompt "Design a messaging app" in a mobile system design interview. Within 30 seconds, he was sketching boxes on the whiteboard. Networking layer here, database there, a nice arrow pointing to "Server." By minute 15, the interviewer asked: "Does this app support group chats?" The candidate froze. His entire architecture assumed one-to-one messaging. He spent the remaining 30 minutes ripping apart what he'd built and never recovered.

He wasn't a bad engineer. He just skipped the most important part of the interview.

The First 5-10 Minutes Decide Everything#

Requirements gathering isn't a warm-up. It's the phase where you define the problem you're going to solve, and getting it wrong means solving the wrong problem brilliantly — which still earns you a "no hire."

Here's why those first few minutes matter so much: every architectural decision you make downstream depends on what you establish upfront. Should you build an offline-first architecture? That depends on the use case. Do you need real-time updates via WebSockets, or is polling fine? Depends on the latency requirements. Should you store media locally? Depends on whether the app even supports media.

When I started interviewing candidates myself, I noticed a clear pattern. The strongest candidates spent 7-10 minutes on requirements. They asked sharp questions, confirmed their understanding, and walked into the design phase with a clear scope. The weaker candidates either asked zero questions or rattled off a laundry list of clarifications that ate up 15 minutes without focus.

The goal isn't to ask the most questions. It's to ask the right questions — the ones that eliminate ambiguity and narrow the problem to something you can actually design in 45 minutes.

Functional Requirements: What Are We Building?#

Functional requirements define what the app does. These are the user-facing features — the things someone can see and interact with. Your job during this phase is to figure out the core user flows and cut everything else.

Start with this question: "What are the 2-3 most important things a user should be able to do?"

This forces the interviewer to prioritize, and it gives you a ranked list of what to focus on. You're not trying to design every screen. You're trying to design the critical paths.

Example: "Design a Messaging App"#

Let's say you get this prompt. Here are the functional requirement questions I'd ask, roughly in this order:

1. User scope: Is this one-to-one messaging, group messaging, or both?
2. Message types: Text only, or do we support images, videos, and files?
3. Message features: Do we need read receipts? Typing indicators? Message reactions?
4. Search: Should users be able to search through their message history?
5. Delivery guarantees: Does the app need to guarantee message delivery when the user comes back online?
6. Notifications: Push notifications for new messages?

Notice what I'm not asking about: user profiles, settings screens, contact management, message forwarding, stories, status updates. Those are all real features in messaging apps, but they're not what the interviewer wants to evaluate. They want to see you design the messaging architecture.

After asking these questions, I'd confirm my understanding:

"So we're designing a messaging app that supports one-to-one and group chats with text and image messages. We need read receipts and push notifications. Users should be able to search messages. Offline message queuing is important — if a user sends a message without connectivity, it should be delivered when they reconnect. I'll skip typing indicators and video messages for now to stay focused. Does that sound right?"

That confirmation step matters. It's a contract between you and the interviewer. If you later skip something, it's because you both agreed it was out of scope.

Interview Tip: When the interviewer says "Design X," resist the urge to start with "I'll need a ViewModel and a Repository and a..." Instead, respond with "Before I start designing, I'd like to understand what we're building. Can I ask a few clarifying questions?" Every single time, the interviewer will say yes. And they'll be relieved you asked.

Non-Functional Requirements: How Should It Behave?#

Non-functional requirements are the constraints and quality attributes that shape how you build, not what you build. These are where mobile system design diverges hard from backend system design.

Scale#

Ask about the number of users. "Are we designing for thousands of users or hundreds of millions?" The answer completely changes your architecture.

For a few thousand users, a simple REST API with local SQLite storage is fine. For hundreds of millions, you're thinking about pagination strategies, aggressive caching, CDN integration for media, and connection pooling on the client side.

You don't need exact numbers. What you need is the order of magnitude. "Tens of millions" is enough.

Latency#

What are the latency expectations? A messaging app where messages arrive 5 seconds late feels broken. A news reader where articles load in 2 seconds feels fine.

Ask: "How real-time does this need to feel?" The answer tells you whether you need WebSockets, server-sent events, or simple polling.

Offline Support#

This is the big one for mobile. Ask: "How should the app behave when there's no internet connection?"

The answers range widely:

• No offline support needed — the app is useless without connectivity (e.g., a live streaming app)
• Read-only offline — users can view cached content but can't create new data (e.g., a news app)
• Full offline support — users can read and write, and changes sync when connectivity returns (e.g., a notes app or messaging app)

Each answer leads to a fundamentally different data layer. Full offline support means you need a local database, a sync engine, and conflict resolution. Read-only offline means you need a cache. No offline support means you can keep things simple.

Platform Targets#

"Are we building for iOS, Android, or both?"

If it's both platforms, you might want to discuss shared data models, a common networking layer (using KMM or a shared C++ library), or at least consistent API contracts. If it's a single platform, you can go deeper into platform-specific APIs.

Accessibility#

This one catches candidates off guard, but it's worth asking: "Are there specific accessibility requirements?" At companies like Google and Apple, accessibility isn't optional. Mentioning it shows maturity.

Data Sensitivity#

For apps handling health data, financial transactions, or messages, ask about security requirements. "Is end-to-end encryption expected?" or "Are there compliance requirements like HIPAA?" This changes your storage strategy (encrypted databases), networking approach (certificate pinning), and data retention policies.

How Each Answer Changes the Design#

Here's a quick example. Let's say the interviewer tells you: "This messaging app should work for 50 million users, messages should arrive within 1 second, and it needs full offline support on both iOS and Android."

That single sentence tells you:

• 50 million users → You need efficient pagination, connection management, and probably a message delivery protocol more sophisticated than plain REST
• 1-second delivery → WebSocket connections when the app is foregrounded, push notifications when backgrounded
• Full offline support → Local database (Room on Android, Core Data or GRDB on iOS), outbox pattern for pending messages, sync engine with conflict resolution
• Both platforms → You'll want to discuss a shared data model and consistent sync logic

See how those four constraints just outlined 60% of your architecture? That's the power of good requirements gathering.

The Art of Scoping#

"Design WhatsApp" is not a 45-minute problem. WhatsApp has messaging, voice calls, video calls, status updates, payments, communities, channels, and end-to-end encryption for all of it. If you try to design all of that, you'll design none of it well.

Scoping is about deliberately choosing what to include and what to leave out — and being transparent about those choices.

How to Scope Effectively#

After gathering your functional and non-functional requirements, split everything into two buckets:

Must-have (MVP): The features without which the app doesn't make sense. For a messaging app, that's sending and receiving messages, and a conversation list.

Nice-to-have (if time permits): Features that are real but not essential to demonstrate your design skills. For a messaging app, that's typing indicators, message reactions, or disappearing messages.

Tell the interviewer your plan: "I'll focus on the core messaging flow — sending and receiving text and image messages in one-to-one and group chats, with offline queuing and push notifications. If we have time, I'd love to discuss how we'd add read receipts and message search. Does that work?"

This does two things. First, it shows you can prioritize — a skill that matters on the job, not just in interviews. Second, it protects you from going down rabbit holes. If the interviewer wants you to go deeper into search, they'll say so. If they don't, you just saved yourself 10 minutes.

How Much Is Enough?#

A good scope for a 45-minute mobile system design interview typically covers:

• 2-3 core user flows
• The data model supporting those flows
• The networking approach (REST, GraphQL, WebSocket)
• The local storage strategy
• One or two non-functional deep dives (offline sync, performance optimization, etc.)

If you're trying to cover more than that, you're probably not going deep enough on any of it.

Common Mistakes During Requirements Gathering#

I've seen these patterns across hundreds of interviews — both as a candidate and as an interviewer. Here are the ones that hurt the most.

Mistake 1: Skipping Requirements Entirely#

This is the most damaging. The candidate hears "Design Instagram" and immediately starts talking about MVVM and repository patterns. Ten minutes in, the interviewer asks "How are you handling Stories?" and the candidate realizes they designed only for the feed.

Fix: Always spend 5-7 minutes on requirements. Even if you think the problem is obvious, confirm it.

Mistake 2: Asking Too Many Questions#

The opposite extreme. Some candidates spend 15 minutes asking about every edge case: "What about landscape mode? What about tablets? What about accessibility for screen readers? What happens if the user has low storage? What if the API returns a 429?"

These are all valid concerns, but raising them all during requirements gathering makes you look like you can't prioritize. Save the edge cases for when you're designing the relevant component.

Fix: Limit yourself to 6-8 targeted questions. Cover the functional scope, scale, offline needs, and platform targets. Move on.

Mistake 3: Not Confirming Assumptions#

You ask great questions, get great answers, and then never summarize what you heard. Fifteen minutes later, you're designing something slightly different from what the interviewer intended, and neither of you realizes it until it's too late.

Fix: After your questions, spend 30 seconds summarizing the scope back to the interviewer. Get explicit confirmation.

Mistake 4: Treating It as a Checklist#

Requirements gathering should be a conversation, not an interrogation. The best candidates adapt their questions based on the answers. If the interviewer says "We need real-time updates," a good follow-up is "How real-time? Sub-second, or is a few seconds acceptable?" A bad follow-up is ignoring that answer and moving to the next question on your mental list.

Fix: Listen to the answers. Let them guide your next question.

Mistake 5: Ignoring Mobile-Specific Concerns#

In a mobile system design interview, if you don't ask about offline behavior, battery impact, or platform differences, you're leaving points on the table. These are the concerns that distinguish a mobile design interview from a generic system design one.

Fix: Always ask about offline support and platform targets. These two questions alone will differentiate your approach from web-focused thinking.

A Practical Framework: The UFSCV Method#

Here's a repeatable framework I've used and refined over the years. It's not magic — it's just a structure to make sure you don't forget anything.

U — Users: Who is using this app? What are the primary user personas? How many users are we designing for?

F — Flows: What are the core user flows? What are the 2-3 most important actions a user takes?

S — Scale & Speed: How many users? What are the latency expectations? How much data are we dealing with?

C — Constraints: Offline support? Platform targets? Security requirements? Accessibility needs? Battery sensitivity?

V — Verify: Summarize your understanding. Confirm scope. State what you'll focus on and what you're intentionally leaving out.

The whole thing should take 5-8 minutes. Let's see it in action.

Walkthrough 1: "Design Instagram's Feed"#

Here's how I'd handle requirements gathering for this prompt.

Users#

"Who are the primary users? I'm assuming this is for regular end users browsing and posting content — not for business accounts or advertisers. Is that right?"

Interviewer: "Yes, focus on regular users."

Flows#

"What are the core flows we should focus on? I'm thinking: (1) viewing the home feed with infinite scroll, (2) posting a photo with a caption, and (3) liking and commenting on posts. Should I include Stories, Reels, or DMs?"

Interviewer: "Skip Stories, Reels, and DMs. Focus on the feed, posting, and engagement."

Scale & Speed#

"How many daily active users are we designing for? And what's the expected feed refresh latency — should new posts appear in real-time, or is pull-to-refresh acceptable?"

Interviewer: "Design for 100 million DAUs. Pull-to-refresh is fine; no need for real-time feed updates."

Constraints#

"A few more questions. Should the app support offline viewing of previously loaded feed content? Are we targeting iOS, Android, or both? And is media stored on a CDN, or do we need to design media storage ourselves?"

Interviewer: "Offline viewing of cached feed items would be great. Target both platforms. Assume media is served from a CDN — don't worry about the upload pipeline."

Verify#

"Let me summarize. We're designing an Instagram-like app for 100 million DAUs, focused on three flows: browsing a paginated feed, posting photos with captions, and engaging via likes and comments. The feed updates via pull-to-refresh — no real-time push. We need offline viewing of cached content on both iOS and Android. Media comes from a CDN, so I won't design the media upload pipeline. I'll focus my architecture on the feed loading and caching strategy, the data model, and the posting flow. Does that sound right?"

Interviewer: "Perfect. Let's go."

That took about 6 minutes. Now I know exactly what to design, and the interviewer knows I understand the problem. I won't waste time on Stories or real-time feed updates. I can go deep on feed pagination, image caching, and offline storage — which is exactly what the interviewer wants to evaluate.

Walkthrough 2: "Design Uber's Rider App"#

Different prompt, same framework. Watch how the questions change based on the domain.

Users#

"I'll focus on the rider's perspective — the person requesting a ride, not the driver. Is that correct?"

Interviewer: "Yes, rider only."

Flows#

"The core flows I see are: (1) requesting a ride — entering pickup and destination, seeing price estimates, and confirming; (2) tracking the driver in real-time after the ride is confirmed; and (3) completing the ride with payment and rating. Are there other flows you'd like me to include, like ride scheduling or ride sharing?"

Interviewer: "Those three flows are perfect. Skip scheduling and sharing."

Scale & Speed#

"For the real-time tracking, what update frequency do we need for the driver's location? Every second? Every 5 seconds? And how many concurrent ride requests should the system handle in a single city?"

Interviewer: "Location updates every 2-3 seconds during an active ride. Assume tens of thousands of concurrent rides per city."

Constraints#

"Uber is heavily location-dependent, so a few specific questions. Should the app work in areas with poor connectivity — say, spotty 3G? Do we need to cache map tiles for offline use? And on the battery front, continuous GPS tracking drains battery fast — is that an acceptable tradeoff during an active ride?"

Interviewer: "The app needs to handle poor connectivity gracefully — queue requests and retry. No need for full offline maps; assume the user has some connectivity. Battery drain during an active ride is acceptable, but minimize GPS usage when the app is idle."

"One more: are we targeting both platforms?"

Interviewer: "Yes, iOS and Android."

Verify#

"Here's what I'll design: a rider app for iOS and Android with three core flows — ride requesting, real-time driver tracking, and ride completion with payment and rating. Location updates come every 2-3 seconds during active rides. The app handles poor connectivity by queuing requests. I'll minimize GPS usage when there's no active ride to preserve battery. I'll focus my architecture on the real-time location tracking system, the ride state machine, and the networking layer with retry logic. I won't cover map tile caching, ride scheduling, or the driver-side app."

Interviewer: "Sounds good."

Notice how different these questions were from the Instagram walkthrough. Instagram was about content loading, caching, and pagination. Uber is about real-time location, state management, and network resilience. The framework is the same, but the questions adapt to the domain.

Putting Requirements Into Your Architecture#

Good requirements gathering doesn't just help you scope the problem — it gives you architectural anchors. Each confirmed requirement maps to a design decision.

Here's how requirements from the Instagram example translate directly into architecture:

And for Uber:

When you make these connections explicit during your interview, the interviewer sees that your design isn't arbitrary — it's driven by requirements. That's what separates a senior-level answer from a junior one.

What to Do Right After Requirements#

Once you've confirmed scope, don't jump straight to drawing boxes. Take 30 seconds to outline your approach on the whiteboard or shared doc:

1. List the confirmed requirements (abbreviated)
2. Sketch the high-level components you'll cover
3. State the order you'll tackle them

Something like:

"I'll start with the data model, then the networking and caching layer, then the UI architecture. I'll circle back to offline sync at the end."

This gives the interviewer a roadmap. If they want you to spend more time on a specific area, they can redirect you early — before you've spent 20 minutes on something they don't care about.

The Bottom Line#

Requirements gathering is a skill, and like any skill, it gets better with practice. Run through it before every mock interview. Use the UFSCV framework until it becomes second nature: Users, Flows, Scale, Constraints, Verify.

The candidates who do this well don't just pass interviews — they make the interviewer's job easier. And interviewers who enjoy the conversation tend to evaluate you more favorably. That's not gaming the system. That's being a good communicator, which is exactly what the interview is testing.

Get the requirements right, and the rest of the interview flows. Skip them, and you're building on sand.