Android interviews focus on Kotlin idioms, coroutines, and the platform lifecycle — most senior questions are really asking whether you understand that your process can be killed at any moment. Below are the questions asked most often, each with a model answer. Senior: architecture, trade-offs, mentoring, and decision-making.
Dispatchers.Main runs on the UI thread and is where you touch views. Dispatchers.IO is a large elastic pool for blocking work — disk, network, database — because those threads spend their time waiting. Dispatchers.Default is sized to the CPU count and is for actual computation like parsing or sorting. Putting a blocking call on Default starves the pool, which is the most common dispatcher mistake.
Flow is a cold asynchronous stream: it starts producing when collected, and each collector gets its own execution. StateFlow is hot and always holds exactly one current value, which makes it the natural fit for UI state — new collectors immediately get the latest state. LiveData is the older lifecycle-aware holder; StateFlow plus repeatOnLifecycle covers the same need with the rest of the coroutines toolkit, so new code generally prefers it.
Rotation, dark mode, language and window size changes destroy and recreate the Activity so it can load resources for the new configuration. State that must survive belongs in a ViewModel, which outlives the recreation. State that must also survive process death goes into SavedStateHandle, because the system can kill your process in the background and restore the task later — testing that path with "Don't keep activities" is what separates a robust app from one that loses the user's input.
Compose re-runs a composable when a State it reads changes, and it skips composables whose parameters are equal and stable. Slowness comes from unstable parameters — a plain List or a lambda capturing a changing value — which defeat skipping and re-run large subtrees. The fixes are hoisting state to the lowest common owner, using immutable collections or @Immutable annotations, and deferring reads with lambdas so only the layout or draw phase re-runs.
DI removes the need for a class to know how to build its dependencies, which makes it testable and keeps wiring in one place instead of scattered singletons. Hilt generates the Dagger graph and ties component lifetimes to Android ones — a @Singleton lives with the application, a @ViewModelScoped binding with the ViewModel. The practical payoff is swapping a real repository for a fake in tests without touching production code.
The UI layer holds Compose or Views plus a ViewModel that exposes immutable state and receives events. The domain layer holds use cases and pure business rules with no Android imports, which is what makes it testable with plain JUnit. The data layer holds repositories that decide between Room and Retrofit and map DTOs to domain models. The rule that matters is dependency direction: domain knows nothing about data or UI.
An ANR fires when the main thread is blocked for roughly five seconds on input, or shorter limits for broadcasts and services. Typical causes are database or network calls on the main thread, a huge synchronous JSON parse, or lock contention with a background thread. After release, Play Console's ANR reports plus the captured main-thread stack point at the blocking frame; adding StrictMode in debug builds catches most of these long before they ship.
The recurring cause is something long-lived holding an Activity or View — a static reference, a listener you never unregistered, an inner class holding an implicit outer reference, or a coroutine on GlobalScope. The defences are scoping work to a lifecycle-aware scope, clearing binding references in onDestroyView for fragments, and using the application Context where an Activity Context is not required. LeakCanary in debug builds catches the rest by reporting the retaining path.
let takes the receiver as an argument and returns the lambda result, so it fits null-checking and transformation. run does the same but with this, useful for a block of calls returning a value. apply returns the receiver and is for configuring an object. also returns the receiver too but takes it as it, so it suits side effects like logging. with is not an extension and just groups calls on an object. Choosing by return value and receiver form is what keeps them readable rather than clever.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Android (Kotlin) interview →