What Is the Android System Design Interview Like?

An Android design round asks you to design one feature of one app, on one device. There are no load balancers and no sharding. The subjects are the network, the local database, memory, background work, and offline behavior.

The scope is one of three. Client only, client plus the API, or the full stack. Ask which one applies before you draw anything.

Quick Overview

The Machine Coding Round Often Comes First

At several companies the design round is not the first technical round. Candidate reports and Indian hiring guides describe a machine coding round first. You build a small working module in about two hours.

Those reports name Flipkart, Swiggy, Uber and similar companies. The graders look for clean class boundaries and separation of concerns. Feature count matters less than structure.

A client design round often follows. In those reports the backend is described as already built. So the question is about the app, not about servers.

Background Work Is the Hardest Part on Android

Android stops your app to save battery, and your design must expect that. This is the part that separates a strong Android answer from a generic one. Name each rule, then name your response to it.

• Doze. When the device is idle and still, the system defers background work. Jobs and alarms wait for a maintenance window.
• App Standby buckets. The system sorts apps by how often the person opens them. A rarely opened app receives fewer jobs and fewer alarms.
• Background start limits. Recent Android versions block an app from starting a foreground service while it sits in the background, apart from a few allowed cases.
• Foreground service types. A foreground service shows a notification and keeps running. Recent versions make you declare a type for it, and each type has its own rules.
• WorkManager. The API for deferred work that must survive a restart. You attach constraints such as network connected, or battery not low.
• Manufacturer limits. Community trackers such as dontkillmyapp.com document extra restrictions added by Xiaomi, Oppo, Vivo, OnePlus and others.

The manufacturer point matters for phones sold in India and other large markets. Autostart can be off by default. Background work can simply never run, and the app is not told.

So the design answer has the same shape every time. Never depend on background work for correctness. Sync when the app opens, keep a queue of pending writes, and treat background runs as a bonus.

Say how you would know. Record whether the scheduled work ran, and report that number. Then say what the app does for a user whose work never ran.

The Android Parts You Are Expected to Name

The Five Step Method

• Requirements. Ask what the feature does and what must work with no network. Write the list down and agree it.
• API and data model. Use cursor pagination, where the server returns a marker for the next page. Also name the Room tables.
• Client architecture. Four layers: UI, presentation, domain, data. Room is the source of truth and the network is a sync source.
• The hardest part. On Android this is usually background sync. Spend the time there.
• Failure, offline and shipping. Queue writes with IDs the client creates, so an action made offline is not lost and not applied twice.

The Details That Decide the Grade

• Process death. The system can kill your process and restore the screen later. Restore state from saved state or from Room, never from memory.
• Image memory. Decode a photo to the size of the view. A full size decode can use tens of megabytes.
• Cancellation. Cancel an image request when its row scrolls away.
• Offline reads. The screen renders from Room first. The network updates it afterwards.
• Shipping. A release cannot be rolled back like a server deploy. Use feature flags and staged rollout.

What Each Level Must Add

Mid level produces a design that works. Senior adds what breaks, what the user sees when it breaks, and what each choice costs. Senior also names a rejected alternative.

Staff adds whether the feature should exist. Staff draws module and team boundaries. Staff also covers rollout and the cost of owning the code.

The Questions Asked Most Often

App features come up first. News feed, chat, stories, photo upload, ride hailing, food delivery with live order tracking, booking and checkout, and a video player.

Library questions come up just as often. An image loading library, a file downloader and uploader, a networking layer, a pagination library, an analytics SDK, or a feature flag SDK.

How to Prepare

• Prepare the round directly. Grokking Modern Mobile System Design Interview covers the Android side of every question here, including background execution and app size.
• Practice one offline write feature. An order placed with no network is a good subject. Cover the queue, the client IDs, the retries, and what the user sees.
• Rehearse the background story out loud. Doze, buckets, WorkManager constraints, and manufacturer limits, in that order.
• Read the iOS version for contrast. What the iOS system design interview is like shows which parts are platform specific, and Apple iOS expectations shows a company version.
• Know what does not apply from server rounds. Mobile vs backend system design lists the differences.
• Build a question bank and a plan. Use the questions asked in mobile design rounds, this mobile system design question list, and how to prepare.
• Prepare the coding round separately. Grokking the Coding Interview covers the patterns, and Grokking System Design Fundamentals covers the server ideas you will reference.