Interview Framework: Req → Design → Deep Dive → Trade-offs

Android system design interviews follow a predictable pattern. Knowing the framework lets you structure your answer confidently, hit the right depth at each phase, and avoid the most common failure modes.

The 45-Minute Framework

Copy code 0–5 min:   Clarify requirements
 5–15 min:  High-level design
15–30 min:  Deep dive (2–3 components)
30–40 min:  Trade-offs and alternatives
40–45 min:  Questions for the interviewer

Phase 1: Clarify Requirements (5 min)

Don't assume — ask. Interviewers often give vague prompts on purpose.

Functional Requirements

• "What platforms do we target? Android only or also iOS?"
• "What user actions must work offline?"
• "What's the expected scale? 1M users or 100M?"
• "Do we need real-time updates, or is eventual consistency OK?"
• "What existing infrastructure can I assume? Firebase? Custom backend?"

Non-Functional Requirements

• Network: "Should this work on 2G/3G?"
• Battery: "Any constraints on background activity?"
• Latency: "What's the acceptable P95 for screen load time?"
• Storage: "Maximum offline cache size?"

Scope Constraints

• "For this interview, I'll focus on the Android client architecture. I'll treat the server as a given."
• "Should I design the entire app or just the feed feature?"

Phase 2: High-Level Design (10 min)

Draw the architecture before writing any code. Components:

Copy code┌─────────────────────────────────────────────────────┐
│                    UI Layer                         │
│  Compose Screens → ViewModels → StateFlow/UiState   │
├─────────────────────────────────────────────────────┤
│                  Domain Layer                       │
│  Use Cases → Repository Interfaces → Domain Models  │
├─────────────────────────────────────────────────────┤
│                   Data Layer                        │
│  ┌──────────────┐    ┌─────────────────────────┐   │
│  │ Remote (API) │    │ Local (Room / DataStore) │   │
│  └──────────────┘    └─────────────────────────┘   │
├─────────────────────────────────────────────────────┤
│               Infrastructure                        │
│  Hilt DI │ WorkManager │ FCM │ Coil │ ExoPlayer     │
└─────────────────────────────────────────────────────┘

State what you'll deep dive: "I'll go deep on the feed pagination with caching and the optimistic like system. I'll treat search and notifications at a higher level."

Phase 3: Deep Dive (15 min)

Pick 2–3 components and go deep. Show you understand the full stack:

Good deep dive topics:

• Offline-first data flow: Room → UI, WorkManager sync, conflict resolution
• Pagination: PagingSource + RemoteMediator, cursor vs page-based
• Optimistic UI: like/unlike with rollback, idempotency keys
• Performance: image preloading strategy, ExoPlayer pooling
• Security: token storage (EncryptedSharedPreferences), PKCE flow
• Real-time: WebSocket connection management, reconnection backoff

What interviewers look for:

• Concrete API choices (not "some caching library")
• Awareness of failure modes and how to handle them
• Why this choice vs the alternative

Phase 4: Trade-offs (10 min)

For each major choice, state the trade-off explicitly:

Common Interview Anti-Patterns

Vocabulary That Signals Seniority

• "eventual consistency" — when acknowledging offline-first trade-offs
• "idempotency key" — when handling retries and duplicates
• "at-least-once delivery" — when discussing FCM reliability
• "optimistic update with rollback" — for immediate UI responsiveness
• "strong skipping / stable types" — for Compose performance
• "cursor-based pagination" — vs offset for live data
• "write amplification" — when discussing fanout models

Key Takeaways