Mobile System Design Interview Questions
ADVANCED › System Design
For a feature like a photo gallery with thousands of images, walk me through the trade-offs between loading everything into memory, paginating from a local database, and paginating straight from the network. When would you pick each?
What a strong answer covers: A strong answer rules out loading everything into memory past a few hundred items due to OOM and jank risk, and distinguishes database-backed paging, right when users scroll back and revisit content and you want instant offline re-render, from pure network pagination, which avoids storage and dedup cost for huge catalogs users rarely revisit. It should tie the choice to concrete signals like revisit frequency and offline requirements rather than defaulting to one pattern out of habit.
Mid-interview, the interviewer pushes back on your design and asks 'what if this needs to scale to ten times the traffic' or 'what if the network is really flaky.' Walk me through how you'd adapt your design live.
What a strong answer covers: A strong answer names specific pressure points the new constraint stresses, such as moving from offset to true cursor pagination, adding retry with backoff and idempotency keys to writes, or introducing a caching layer, and explicitly frames it as revising one component rather than starting over. The trap a weaker candidate falls into is redesigning from scratch, which signals they didn't understand why the original design held up in the first place.
Two engineers disagree about whether a feature needs a Domain layer of use cases, or whether the Repository should talk directly to the ViewModel. How do you actually decide, and what's the cost of getting it wrong either way?
What a strong answer covers: A strong answer ties the decision to whether business logic is reused across multiple ViewModels or is complex enough to warrant testing independently of Android framework classes; a single screen with simple pass-through logic often doesn't need the extra layer. It should name the cost of skipping it when needed, duplicated logic and hard-to-test ViewModels, against the cost of adding it when unneeded, extra indirection and boilerplate per screen, rather than asserting a blanket rule.