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. Middle: deeper understanding, optimization, and real-world situations.
A coroutine is a suspendable computation scheduled by the Kotlin runtime; a thread is scheduled by the OS. Suspension releases the thread instead of blocking it, so thousands of coroutines share a small pool. This is why a blocking call inside a coroutine defeats the purpose entirely — it holds the thread it was meant to free.
That every coroutine started in a scope is a child of it, so cancelling the scope cancels them all and the scope does not finish until they do. In practice this is viewModelScope — work stops when the ViewModel is cleared. Launching in GlobalScope opts out and is how work outlives the screen that started it.
A Flow is cold — it produces values when collected, once per collector. StateFlow is hot, always holds a current value, and emits it to every new collector, which is what UI state wants. SharedFlow is hot without a current value and suits events that should not replay — a navigation command or a snackbar.
Compose re-runs composables whose inputs changed. It happens too often when a lambda or an unstable type is recreated on every parent render, or when a whole screen reads one frequently changing value. The fixes are remember, hoisting state so only the part that needs it reads it, and stable types — and the recomposition counts in Layout Inspector tell you where.
Because an Activity context is tied to a screen, and anything long-lived holding it keeps that whole screen in memory. The usual cases are a singleton initialised with an Activity, a static reference, or a listener never unregistered. Application context is right for anything outliving a screen — but it cannot inflate themed views, which is why the mistake gets made.
Measure first: adb shell am start -W gives cold, warm and hot start times, and the system trace shows what runs before the first frame. The usual causes are work in Application.onCreate — SDK initialisation especially — synchronous disk or network reads, and doing on the main thread what could be deferred until after the first frame.
launch starts work and returns a Job with no result; async returns a Deferred you await. Use async only when you need the value, and start both before awaiting either if you want them concurrent. An async whose result is never awaited swallows its exception, which is a quiet way to lose a crash.
Parcelable is the Android one: you describe how the object is written and read, so there is no reflection and it is measurably faster for passing data between components. Serializable is the Java marker interface — almost free to write, slow at runtime, and it allocates heavily. In Kotlin the argument mostly disappears because @Parcelize generates the boilerplate, which removes the only real reason people chose Serializable.
Doze and App Standby are the system deferring your background work when the device is idle or your app is unused, which is why an alarm or a network call simply does not happen when you expected. WorkManager is for deferrable work that must eventually happen and survive process death and reboot — sync, upload, cleanup. A foreground service is for work the user is aware of right now, like playback or navigation, and it must show a notification. Reaching for a plain background service instead is how work silently stops running on modern Android.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Android (Kotlin) interview →