androidinterview.com

Android System Design Interview Questions

34 questions

A strong Android system design answer explains how the app works on the phone, including rotation, poor internet and process death. I'd start with what the user needs, draw the main components, then walk through one read and one write. That makes it clear where the data lives, who makes the request and how the screen updates.

How to structure the interview

I'd spend the first few minutes agreeing on scope and drawing the design. Most of the discussion should explain how data moves through the app. I'd leave time for failures and tradeoffs, and follow the interviewer's questions. Targets for speed, freshness, storage and battery use depend on the product, so I'd state my assumptions before choosing numbers.

ExplainQuestions your design should answer
Requirements and use casesWho uses it, what works offline and what this design leaves for later
ComponentsWhat Compose, the ViewModel, repository, DAO, API and worker each do
Reads and writesWho makes the request, who saves the result and how the UI receives updates
DataHow IDs, pages, versions, repeated requests and separate accounts are handled
UI behaviourWhat the user sees while loading, offline, waiting for sync or facing an error
Lifecycle and dependency injectionWhat survives rotation or process death, and who creates each object
Performance and testingHow memory stays limited, lists stay smooth and failures are tested

Design a Google Notes app shows the full path from Room entities and DAOs to the repository, worker, ViewModel and Compose screen. It also shows manual dependency injection and Hilt. The other answers explain what changes for each problem. A chat message, a payment and a location update have different rules for what must be saved and what can be retried.

The Kotlin snippets show how the Android pieces connect. They omit imports, routine setup and some supporting types where explained. The code browsers show the underlying algorithms separately in Java and Kotlin. These are interview examples, not complete Android projects.

For an app feature, MVVM is a useful starting point. State goes down to the UI and actions go back up, which is unidirectional data flow. Android recommends UI and data layers, with an optional domain layer for shared business rules. For a library, I'd focus on its API, storage, cancellation and what happens when several callers use it at once. Then I'd show how an app creates and calls it. See the official architecture recommendations.

Library Design

  • Design an image loading library.

    Hard

    Design a library that takes an image source and displays the right image in an Android view. While loading it can show a placeholder, and if loading fails it can show an error image. Repeated

  • Design an LRU cache.

    Hard

    A cache keeps values so callers can reuse them without fetching or calculating them again. An LRU cache has limited capacity and removes the least recently used entry when it needs room. Reading or

  • Design a caching library.

    Hard

    Design a reusable library that stores values under keys so different app features can reuse them. A cache avoids repeated work, but its copies may become old and its storage cannot grow forever.

  • Design a file downloader library.

    Hard

    Design a library that downloads a file from a URL to local storage. A caller should be able to start a download, see progress, pause or cancel it, and obtain a complete file when it succeeds.

  • Design a logging library.

    Hard

    Design a logging library that lets application code record diagnostic messages. Developers use those messages to understand what the app was doing before a failure, both during development and after

  • Design a networking library.

    Hard

    Design a reusable networking layer that lets app features send HTTP requests and receive results without each feature rebuilding connection handling, response parsing and cancellation.

  • Design an analytics library.

    Hard

    Design a library that records meaningful actions inside an app and sends them to an analytics service. Product teams use these events to understand behaviour, such as how many people open checkout

App & Feature Design

Caching & Offline

Offline and caching is where a mobile design round almost always ends up, because it is the part that separates mobile design from backend design.

Data & Security

Less common, worth knowing

These come up less often. Skim them once you are comfortable with everything above.

Library Design

  • Design an image downloading library.

    Hard

    Design a shared image download library that fetches image files for app features. Callers give it a URL and receive a local file or a failure. This layer handles the bytes. Turning those bytes into a

App & Feature Design

Data & Security

  • What is the SMS Retriever API in Android?

    Easy

    The SMS Retriever API lets your app automatically read a one time verification code from an incoming SMS, without asking the user for the READSMS or RECEIVESMS permission.

  • How do you get accurate time in Android?

    Medium

    Design time handling for an Android feature that cannot blindly trust the date and time shown on the phone. First distinguish measuring how long something lasts from knowing the current time agreed