weeebox/mobile-system-design

This repository is a guide for people preparing for mobile system design interviews at tech companies, covering both iOS and Android roles. A system design interview typically asks you to design a feature or application from scratch, like a social media feed or a file-sharing tool, within 45 to 60 minutes. The guide explains how to approach that process in a structured way. The core framework starts with defining what the task actually is. The interviewer might ask you to design just the mobile app, or both the app and the server API, or the full stack including backend infrastructure. The guide walks through how to clarify the scope early, then how to gather requirements by separating what the feature must do (functional requirements), what qualities it needs to have (non-functional requirements like offline support or battery efficiency), and what to leave out. A significant portion of the guide covers the kinds of clarifying questions worth asking: whether the app needs to support older devices or slower networks, how many users are expected, what the team size looks like, and what performance targets matter. Each question is explained with the reasoning behind it, so you understand why it signals good thinking to an interviewer rather than just memorizing a list. The guide also walks through creating a high-level architecture diagram, showing how components like an API service, a local data store, a repository layer, image loading, navigation coordination, and dependency injection all fit together in a typical mobile app. It explains the role of each piece in plain terms. Beyond the main framework, the repository includes deeper dives into specific topics such as image loading strategies, mobile navigation patterns, and other technical areas that commonly come up in interviews. The guide explicitly notes it is not affiliated with any specific company and does not guarantee interview success, but it provides a repeatable structure for thinking through mobile design problems clearly. The full README is longer than what was shown.