Mobile System Design Interview: The 20 Most Asked Questions

Twenty questions cover almost every mobile system design round. Ten are app features. Ten are libraries or SDKs, where an SDK is a package that other apps install and call.

The list is short because the round is narrow. You design one feature of one app, running as one process on one device. There is a weak network, a small battery, and an operating system that can stop the app at any time.

This article lists all twenty questions and the hard part of each one. It then gives the five step method with a minute budget. It also lists the requirements a mobile design must answer, and what moves an answer up a level.

A one page summary sheet is available to subscribers of my newsletter. It holds the five steps, the requirements list, and all twenty questions. You can subscribe at arslanahmad.substack.com.

The 10 app feature questions

These are ordered by how often candidates report them.

1. Design a news feed. Paging while new items arrive, and keeping the scroll position after a refresh.
2. Design a chat screen. Message order, retrying a failed send, and showing each message exactly once.
3. Design photo sync and upload. Large files, resumed uploads, and work that must survive the app closing.
4. Design the rider side of a ride hailing app. A live map, frequent location updates, and the battery cost of both.
5. Design a food delivery order screen. Order state changes from three parties, on a connection that drops.
6. Design booking and checkout. One payment must happen once, even when the user taps the button twice.
7. Design an email client. A large local mailbox, search with no network, and syncing read state back.
8. Design stories. Prefetching the next item so playback starts at once, without wasting the user's data.
9. Design a video player screen. Buffering, quality switching, and releasing the decoder when the user leaves.
10. Design notifications. Push is not reliable delivery, so the app must also fetch when it opens.

The 10 library and SDK questions

11. Design an image loading library. A memory cache and a disk cache, cancelling requests when a row scrolls away, and decoding each image to the size of the view.
12. Design a file downloader and uploader. Resume after a break, progress reporting, and the limits on background time.
13. Design the networking layer. Retries, timeouts, refreshing the login token, and one place every call passes through.
14. Design a pagination library. Cursor paging, repeated items, and a list that changes while it is being read.
15. Design an analytics SDK. Batching events, storing them on disk, and never losing or double counting one.
16. Design a feature flag SDK. Fetching values, a default when the fetch fails, and no flicker after the screen is drawn.
17. Design a push notification client. Token refresh, permission changes, and what to show when the app is already open.
18. Design a caching library. Eviction, size limits, expiry, and what to return when the stored copy is stale.
19. Design an event bus. Delivery order, which thread the listener runs on, and removing listeners so closed screens are freed.
20. Design a crash reporting and logging SDK. Writing a report while the app is dying, then sending it on the next start.

Question twenty is my own addition to the reported list. It is worth practising because it forces you to think about work that happens when the app is not healthy.

The half most candidates never prepare

Most preparation covers app features only. That leaves ten of the twenty questions untouched. Candidates report that Meta, Uber and Flipkart ask library questions as often as app questions.

A library question is harder to answer from memory. There is no product to describe, so the whole answer is architecture. The interviewer can ask about the public interface, threads, memory use, and failure.

The useful part is that one body of study answers both families. A news feed needs pagination, image loading, and caching. Preparing those three libraries also prepares most of the app questions.

The five step method, with a minute budget

The budget above suits a 45 minute round. Before minute one, ask which scope you are in. The three choices are client only, client plus the API, or full stack.

Step three has one answer that works almost every time. Four layers: UI, presentation, domain, and data. The UI never talks to the network.

Make the local database the source of truth and the network a sync source. Offline behaviour then becomes part of the design instead of an extra section. That single choice earns credit in step five as well.

Sixteen of these twenty are worked as full case studies in Grokking Modern Mobile System Design Interview, which teaches the client side of this round. The server side is still worth knowing, and Grokking the System Design Interview teaches the backend version of feeds, chat, and uploads.

The mobile non functional requirements

Backend rounds ask about scale. Mobile rounds ask about the device. Name these out loud in step one, then return to them in step five.

• Offline behaviour. What the screen shows with no network, and what happens to a tap made offline.
• Network cost. Payload size, the number of calls, and what the screen does on a slow connection.
• Battery. Location updates, background work, and how often the app wakes the device.
• Memory. Image decoding size and list recycling. A large photo decoded at full size can use tens of megabytes.
• Storage. Cache size limits, what is deleted first, and which data must be encrypted.
• Startup and render time. Time to the first real content, and whether the screen can draw from cache.
• Background limits. iOS gives short windows and background URLSession for transfers. Android uses WorkManager and is limited by Doze, a mode that pauses work while the device is idle.
• Security. Keychain on iOS and Keystore on Android for secrets, plus how permissions are requested.
• Accessibility and translation. Larger text sizes, screen readers, and strings that grow when translated.
• Release safety. A release cannot be rolled back like a server deploy. Feature flags, staged rollout, and a way to switch the feature off belong in the design.

Two more mobile specifics decide grades often. Use cursor pagination rather than page numbers, because items arrive while the user scrolls. Keep a queue of pending writes with client generated IDs, so an offline tap is neither lost nor applied twice.

What separates a senior answer from a mid one

A mid answer builds a design that works. It names the right components, the right endpoints, and the right layers. Nothing in it is wrong.

A senior answer adds four things. What breaks, what the user sees when it breaks, what each choice costs, and the option that was rejected.

A staff answer adds a wider set. Whether to build the feature at all, the module and team boundaries, how it ships, and what it costs to own.

The most common senior rejection is a correct design given at the level below. Correct components, correct API, no failure modes, no offline behaviour, no rollout, and no way to switch the feature off.

So say the cost out loud. A local database makes the screen work with no network. It also adds migration work and the risk of showing stale data.

Naming that cost is most of the distance between the two levels. It takes one sentence per decision.

How to practise this list

Pick one question each week. Write the five steps on one page before you speak. Then answer out loud with a timer running.

Cover the library family as well as the app family. Two of the twenty every month should be a library or an SDK.

Grokking Modern Mobile System Design Interview works these questions at each level, with the platform tables for iOS and Android. For the server vocabulary underneath them, Grokking System Design Fundamentals covers caching, pagination, and consistency.

The one page summary sheet holds the five steps, the requirements list, and all twenty questions. It goes to subscribers of my newsletter at arslanahmad.substack.com.

Frequently asked questions

How long is a mobile system design round?

About 45 minutes at most companies, and sometimes 60. Candidates report that one area takes the largest share of the time. Plan for the interviewer to examine a single part in detail.

Do I need to know the backend?

Yes, but less than a backend candidate does. You design the API you call, not the service behind it. Knowing how a feed is stored and ranked helps you ask for the right endpoint shape.

Does the question change between iOS and Android?

The question rarely changes. The names do. Core Data or SwiftData and Room, UserDefaults and DataStore, Keychain and Keystore, BGTaskScheduler and WorkManager, APNs and FCM, URLSession and OkHttp, SwiftUI and Compose.

Which question should I practise first?

A news feed. It contains pagination, image loading, caching, and offline reads. Those four parts appear again in most of the other nineteen questions.

Are the library questions really asked?

Yes. Candidates report them at Meta, Uber, and Flipkart as often as app questions. They are common at senior and staff level, because the answer shows how you design an interface.

What if I do not know the platform API names?

Describe the behaviour instead. Say "a scheduled background job that the system may delay" rather than guessing a class name. Interviewers grade the design, not the vocabulary.

Related reading

• What Questions Are Asked in a Mobile System Design Interview?
• How Do You Prepare for a Mobile System Design Interview?
• Mobile vs Backend System Design Interview: What Changes?
• What Is a Product Architecture Interview at Meta (Facebook)?
• What Is the Android System Design Interview Like?