Cracking the Mobile System Design Interview (with 7 Practice Prompts)
1. The Reframe: Process Over Architecture
When you're handed a prompt like "Design the client architecture for a photo-sharing feed," you will feel an overwhelming urge to jump straight to the architecture. You'll want to grab a marker and immediately draw your presentation layer, domain layer, and local database.
Resist that urge.
The interviewer is NOT testing whether you know how to "build Instagram." They know you can build an app. They are testing something far rarer: whether you can take a fuzzy, underspecified business requirement and turn it into a concrete, risk-managed technical plan, out loud, under time pressure, while explaining your reasoning to a peer.
Two candidates can propose the exact same architecture. One will be down-leveled to mid-level; the other will receive a strong senior offer. The difference is the path they took to get to that architecture.
2. The 5-Step Framework
To keep yourself from jumping straight to the solution, you need a mental framework. Think of this as the agenda you explicitly set at the start of the interview. Walk the interviewer through these five steps sequentially.
Why it matters: Interviewers specifically penalize assumption-making. They deliberately leave prompts underspecified to see if you notice.
Action: Ask questions out loud before drawing a single box. "Do we need offline support for this? What's the expected scale — thousands or millions of users? Is this a greenfield app or integrating into an existing codebase?" Candidates who skip this often solve the wrong problem entirely.
Why it matters: A technical choice without a stated trade-off sounds junior, no matter how correct the choice is.
Action: Draw your boxes, but attach reasoning to every choice. Don't just say "I'll use SQLite." Say, "I'm choosing SQLite over a NoSQL solution here because our clarified requirements indicate we need complex relational querying for the offline product catalog, even though it adds migration overhead."
Why it matters: It proves you think about production reality, not just the "happy path" a tutorial covers.
Action: Proactively identify mobile-specific issues before the interviewer prompts you. Talk about users with limited data plans, battery drain from polling, memory pressure from large images, and what happens when the OS kills the app in the background mid-upload.
Why it matters: It shows the difference between an engineer who thinks about code and one who thinks about how code is built by a team of people over time.
Action: Mention modularization. "If we isolate this chat feature as its own package, a separate squad can own it, test it, and update it without stepping on the toes of the core navigation team."
Why it matters: Business requirements change. Your v1 design shouldn't require a total rewrite to support v2.
Action: Flag what a hypothetical v2 will need. "We are only supporting credit cards now, but I'm designing the payment interface so adding Apple Pay in v2 won't require touching the core checkout logic."
It is completely fine—and often stronger—to say: "I haven't built offline conflict resolution from scratch before. I would start with a 'last-write-wins' strategy based on timestamps, and ask product if that's sufficient for v1." Honesty beats bluffing every time. An interviewer trusts a candidate more after one honest "I don't know, but here is my approach" than after a confident-sounding answer that falls apart under a single follow-up question.
3. 7 Realistic Practice Prompts
Do not read these prompts and simply look at the answers. The goal is to train your process. Expand a card to see the clarifying questions and non-obvious constraints a strong senior candidate would immediately surface.
Prompt: Design a client architecture that must handle large files, retries, background upload, progress indication, and failure recovery.
Clarifying Questions:- What is the maximum file size? (Dictates if chunking is required).
- Does the backend support resumable uploads via byte-range headers?
- How critical is immediate upload versus waiting for Wi-Fi?
- OS Lifecycle: The app being backgrounded or killed by the OS mid-upload.
- Memory: Out-of-memory (OOM) crashes if reading the entire file into RAM instead of streaming chunks.
- Network Transition: Handling the transition from Wi-Fi to cellular data mid-stream.
Prompt: Design a payment flow that must work correctly even with offline queuing and unreliable retries.
Clarifying Questions:- Are we selling digital goods (instant unlock) or physical goods (shipped later)?
- Is it acceptable to optimistically show success in the UI while queuing the request?
- What is the expiration policy if the device stays offline for 48 hours?
- Idempotency: Generating a unique UUID on the client per transaction so the server doesn't double-charge on a blind retry.
- State Sync: If the user clears app data while a payment is queued, is that transaction lost forever?
Prompt: Design a multi-level caching layer for a screen showing frequently-updating data (e.g., live prices or live scores).
Clarifying Questions:- Are we using a Push model (WebSockets/SSE) or a Pull model (polling)?
- What is the business tolerance for stale data upon app foregrounding?
- Connection Storms: When the app is foregrounded, it must smoothly re-establish connections without overwhelming the backend.
- Battery Drain: Keeping a persistent connection alive or polling frequently drains battery; we need back-off strategies when the app goes background.
- Memory Pressure: High-frequency updates causing excessive widget rebuilds or RAM bloat if the history isn't truncated.
Prompt: Design a scalable local notification and deep-link system for time-sensitive alerts.
Clarifying Questions:- Are there multiple notification types requiring different navigation stacks?
- Should tapping a notification clear the current stack or push on top of it?
- Cold vs. Warm Starts: Routing logic differs vastly if the app is already in memory versus launching from a terminated state.
- Token Expiration: Handling push token rotation gracefully.
- Parameter Failures: Fallback routing if the deep-link payload is missing IDs or malformed.
Prompt: Design the plugin boundary for adding a new option to an existing multi-option feature (e.g., a new delivery option) without touching existing code.
Clarifying Questions:- Will distinct teams own these different options independently?
- Are we in a monorepo or using multi-repo distributed packages?
- Dependency Hell: Conflicting versions of shared libraries across modules.
- Navigation Coupling: How the core app knows to route to a new module's screen without importing it directly (e.g., using a registry or DI container).
- App Size Bloat: Shared assets duplicated across modules if not managed carefully.
Prompt: Design the client side of a percentage-rolled-out new version of a core flow, including how you'd kill it quickly if it broke.
Clarifying Questions:- Can the flag change mid-session, or should it only evaluate on app launch to prevent UI jumping?
- What is the default fallback state if the config fetch fails?
- Offline Caching: Ensuring the user doesn't flip back to the legacy flow just because they entered a subway tunnel.
- Analytics Attribution: Ensuring the flag's resolved state is tagged onto all subsequent analytics events so the A/B test data is actually usable.
Prompt: Design a screen driven partly by server-defined content that must render safely on an app version several releases behind the backend schema.
Clarifying Questions:- How strict is the schema validation on the client side?
- If an unknown component type is received, do we drop the whole screen, or just that specific block?
- Backward Compatibility: A v1 app receiving a v3 JSON payload with unknown action types.
- Accessibility overrides: Ensuring backend-driven colors/fonts don't override the OS-level accessibility and text-scaling settings.
4. ⚠️ Common Failure Patterns
Even with excellent architectural knowledge, candidates routinely fail this round by falling into these behavioral traps:
Jumping straight to naming state management tools and database libraries before understanding the business scale, offline requirements, or user constraints.
Treating the interview as a speech rather than a collaborative whiteboard session with a colleague. You should be pausing frequently to ask, "Does this approach align with your expectations?"
Proposing an architecture with zero acknowledgment of its weaknesses. Every architecture has a bottleneck. If you don't point yours out, the interviewer will assume you can't see it.
Freezing or making up confident-sounding nonsense when pushed on an unfamiliar sub-topic (e.g., cryptographic key storage), instead of honestly reasoning through it out loud.
5. How to Actually Practice
Reading these prompts silently in your head will give you a false sense of security. The skill being tested is verbal, structured, real-time reasoning.
To practice effectively:
- Pick one of the 7 prompts above.
- Set a timer for 35 minutes.
- Speak your answer out loud to an empty room, drawing on a physical piece of paper or a digital whiteboard.
- Record yourself on your phone.
When you play it back, listen to your first three minutes. Did you ask questions, or did you dive straight into naming packages? Did you sound like a colleague collaborating on a problem, or a student reciting a textbook?
Q: What would you do differently if this feature needed to support 10x the current scale or traffic?
A: Shift focus from client-side processing to server-side pagination, evaluate caching aggressiveness, and ensure our analytics pipelines batch events instead of sending them individually to save battery and network overhead.
6. Senior-Level Sample Answer (The Opening)
The highest-leverage moment of this interview is the first 45 seconds. Here is how a senior candidate opens a prompt about a new photo upload feature:
Before closing out this architecture module, answer this unscripted: If an interviewer asks you to build a feature you've literally never built before, what are the first three words out of your mouth?
Comments
Post a Comment