🎯 Android Interview Preparation and Career

Android System Design Interview Questions

Mobile system design interviews ask you to design an app, such as a chat app, a news feed or a photo gallery, end to end from the client's perspective. The skill being tested is structured thinking about constraints, data flow and trade-offs, not drawing boxes quickly.

✍️ Yunok Tech 📅 Updated ⏱ 3 min read 🎯 Advanced
On this page
  1. A framework for the interview
  2. Step 1: Clarify
  3. Step 2: API and data models
  4. Step 3: Client architecture
  5. Step 4: Common deep dives
  6. Worked example prompts
  7. Step 5: Trade-offs to volunteer
  8. Frequently asked questions
  9. Conclusion

"Design Instagram's feed" isn't a request to rebuild Instagram in 45 minutes. It's an invitation to show how you clarify requirements, choose a client architecture, handle network and storage constraints, and reason about trade-offs, while communicating clearly.

A framework for the interview

Mobile system design interview framework Five steps with approximate time: clarify requirements and constraints, define API and data models, design client architecture and data flow, deep-dive into critical parts such as offline, pagination or real-time, then discuss trade-offs, scaling and quality concerns. Clarify~5 min API + models~5 min Architecture~10 min Deep dives~15 min Trade-offs~5–10 min Talk through decisions out loud. The interviewer grades reasoning, not completeness.
Spend most time on deep dives the interviewer cares about. Ask which parts they'd like to explore.

Step 1: Clarify

  • Functional: core features for this interview (for example: view feed, like, comment, post photo).
  • Non-functional: offline support? Real-time? Scale (users, items per screen)? Low-end devices? Battery and data constraints?
  • Out of scope: confirm what you'll skip (for example the ranking algorithm and server internals).

Step 2: API and data models

Example: feed API sketchText
GET  /feed?cursor={cursor}&limit=20      → { items: [Post], nextCursor }
POST /posts/{id}/like                    → { liked: true, likeCount }   (idempotent)
POST /posts  (multipart: image + caption) → Post
Post { id, author{id,name,avatarUrl}, imageUrl, caption, likeCount, likedByMe, createdAt }

Mention cursor-based pagination (stable under inserts), idempotency for actions, and image URLs with size variants.

Step 3: Client architecture

Client architecture for a feed app Compose UI observes a ViewModel with paged UI state. The repository uses a Paging RemoteMediator to load pages from the API into Room, the source of truth. Likes are written locally first and synced by WorkManager. An image loader with memory and disk cache fetches thumbnails. Push notifications trigger refreshes. Compose UILazyColumn + images ViewModelPagingData + actions FeedRepositoryRemoteMediator Room (truth) API WorkManager sync Image loader cache FCM push
A defensible baseline: offline-capable, paged, with optimistic actions and background sync.

Step 4: Common deep dives

TopicKey points to discuss
PaginationCursor vs offset, Paging 3 + RemoteMediator, prefetch distance, invalidation on refresh
Offline and syncLocal source of truth, pending-change outbox, WorkManager constraints, conflict policy
Optimistic updatesWrite locally, show immediately, roll back on failure, idempotent APIs
Real-timeWebSocket while visible, FCM when backgrounded, catch-up via REST after reconnect
ImagesSize variants, memory and disk cache, downsampling, placeholders, prefetching visible items
UploadsCompress, resumable or chunked, WorkManager with progress notification, retries
SecurityToken storage, TLS, server-side authorisation, Play Integrity for abuse-prone actions
PerformanceStartup, list jank, memory on low-end devices, Baseline Profiles

Worked example prompts

Design a chat app

Local message store, send queue with states (sending, sent, failed), WebSocket while open, FCM otherwise, ordering with server IDs, attachments uploaded in the background.

Design an offline notes app with sync

Room, client UUIDs, change log, periodic and on-change sync, last-write-wins or field merge, end-to-end encryption options.

Design an image gallery

MediaStore or Photo Picker, paging thumbnails, memory budgets, decoding off the main thread, and large-screen layouts.

Step 5: Trade-offs to volunteer

  • Consistency vs responsiveness (optimistic UI).
  • Real-time freshness vs battery and data.
  • Offline capability vs complexity and storage.
  • Modularization vs speed for a small team.

Frequently asked questions

How much backend detail is expected?

Mostly API contracts and client implications. Mention server concerns briefly (rate limits, idempotency), and stay focused on the client.

Should I write code?

Usually only small snippets or interfaces. Diagrams and clear explanations matter more.

Conclusion

Ace mobile system design by clarifying constraints, defining APIs and models, presenting a clear client architecture, going deep on offline, pagination, real-time and media, and volunteering trade-offs, all while thinking out loud.

Next step: prepare the whole senior loop with How to Prepare for a Senior Android Developer Interview.

Official references

📱 Apps built by Yunok Tech

Real Android apps on Google Play, free to download.

See all our apps →

Ready to build real Android applications?

Interviews reward developers who can explain why, not just how. Build the Kotlin, Compose and architecture depth that lets you discuss real trade-offs with confidence.

Move beyond theory and strengthen your Android development skills with Yunoktech's Android course. Learn core concepts, practical implementation, modern Android development techniques, and the reasoning behind building maintainable applications.

Explore the Android course and take your next step as an Android developer.

Explore Android Course →Browse all Android topics
Share: LinkedIn X / Twitter WhatsApp