Android interview preparation
Senior Android interview preparation
A senior Android preparation map built around lifecycle, state, concurrency and production decisions.
The Senior Signal (book, from $59)
Android interview preparation: what matters most
Senior Android interview preparation should connect Kotlin, coroutines and Flow, Jetpack Compose, lifecycle, persistence, testing and mobile system design. Interviewers want to see how you handle cancellation, process death, configuration change, stale data, offline writes, UI state and backwards compatibility. Prepare each topic as a decision with alternatives and constraints, not a definition. Build production stories around an incident, migration, performance problem, architecture change and disagreement.
For coding rounds, communicate invariants and tests before optimising. For system design, begin with the user journey and device constraints, define the source of truth, then cover sync, failure, observability and rollout.
The Android depth map
A credible plan covers the language, runtime and platform together.
- Kotlin semantics and collections
- Structured concurrency, Flow and cancellation
- Compose state and recomposition
- Lifecycle, process death and saved state
- Room, networking and offline synchronization
- Testing, performance and release safety
Test yourself on one feature
Take a search screen with a filter and saved results, and answer six questions about your own implementation.
Every answer you cannot give is the next thing to study. Keep your first attempt so you can compare it with the later one.
- The device rotates: what survives and what is rebuilt?
- The process dies while the app is in the background: what is restored and what is reloaded?
- A second search finishes before the first: what stops the old response from becoming current?
- The screen stops collecting: does the upstream keep running, and who decided that?
- The user switches accounts: what happens to cached state and pending work?
- A release changes the local data shape: what does the migration do when it fails?
Prepare lifecycle-aware answers
Android work is shaped by ownership over time. Explain what survives navigation, configuration change and process death. Name which state can be reconstructed and which must be persisted.
Do not use ViewModel as the answer to every lifetime question. Explain the responsibility and the boundary.
A common slip is saying the ViewModel keeps an unsent form after the process is killed. It survives rotation. It does not survive process death, so anything the user would be upset to lose needs saved state or storage, depending on what the product promises.
Practise with production constraints
Design feeds, messaging, checkout and upload flows under poor connectivity. Trace pending mutations and background work. Then explain how metrics distinguish device, network and backend failures.
That practice makes platform knowledge useful during both architecture and behavioural rounds.
