Android Developer interview prep

Short answer: A coroutine is a lightweight unit of concurrency on top of threads. Suspension parks the coroutine and frees the thread for other work; blocking keeps the thread busy. That is why thousands of coroutines can live on a single thread.

In depth:

// Blocking: the thread is busy and useless
fun blocking() {
    Thread.sleep(1000)   // the thread sleeps — unavailable to anyone
}

// Suspension: the coroutine parks, the thread stays free
suspend fun suspending() {
    delay(1000)          // meanwhile the thread runs other coroutines
}

fun main() = runBlocking {
    repeat(100_000) { launch { delay(1000) } }  // fine even on one thread
    // 100,000 threads with Thread.sleep(1000) — OutOfMemoryError
}

1. Suspension ≠ blocking — delay hands control back to the dispatcher; Thread.sleep holds the thread hostage.
2. Lightweight — a coroutine is a heap object (continuation + state), not a ~1 MB stack like a thread.
3. Cooperative — a coroutine yields its thread only at suspension points.

⚠️ Common mistake: saying a suspend function runs on a background thread. It does not: suspend by itself never switches threads — the dispatcher decides where the code runs.

Short answer: Three "up" callbacks — onCreate → onStart → onResume — bring the screen to the user; three "down" ones — onPause → onStop → onDestroy — take it away. onRestart fires when a stopped Activity comes back to the screen.

In depth:

     onCreate()    ← created: setContentView, init, read savedInstanceState
        │
     onStart()     ← became visible
        │
     onResume()    ← in the foreground, receiving input
        │
   [ RESUMED — running ]
        │
     onPause()     ← lost focus (partially covered)
        │
     onStop()      ← fully hidden  ──onRestart()→onStart() when it returns
        │
     onDestroy()   ← destroyed (finish or low memory)

1. onCreate — the only mandatory one; layout inflation, initialization, restoring from savedInstanceState.
2. onStart / onStop — the visibility boundary: register and unregister whatever only a visible screen needs.
3. onResume / onPause — the focus and input boundary; onPause must be short — the next screen won't appear until it returns.
4. onDestroy — the finale; may never arrive if the process is killed, so save critical things earlier.

⚠️ Common mistake: treating onDestroy as a guaranteed place to save. On process death it never runs — save in onSaveInstanceState / onStop.

Short answer: Recomposition is re-invoking @Composable functions when the state they read changes. It is triggered by a write to an observable State (mutableStateOf, a StateFlow via collectAsState, etc.) that was read inside the composable. Only the functions that read that particular value re-run.

In depth:

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }
    Text("Clicks: $count")           // reads count → re-invoked
    Button(onClick = { count++ }) {  // writes count → recomposition
        Text("Tap")                  // doesn't read count → skipped
    }
}

1. The trigger is not "any change" — it is a write to snapshot state that was read in a specific composable. Compose tracks reads and invalidates exactly the affected scopes.
2. Optimistic — if state changes again mid-recomposition, the current pass is discarded and restarted.
3. Unordered and possibly parallel — the execution order of sibling composables is not guaranteed; don't rely on side effects in the body.

⚠️ Common mistake: a plain var without mutableStateOf is not state; Compose can't see its change and won't recompose — the UI freezes.

Short answer: MVVM splits a screen into three roles: Model (data and logic), View (Activity/Fragment/Composable — it only renders and forwards actions), and ViewModel (holds state and survives View recreation). The ViewModel knows nothing about the concrete View — it just publishes state the View subscribes to.

In depth:

┌────────┐   subscribe to state  ┌───────────┐   request data  ┌───────┐
│  View  │ ◄─────────────────── │ ViewModel │ ──────────────► │ Model │
│ (dumb) │ ── actions (events) ─►│  (state)  │ ◄─── data ────── │(repo) │
└────────┘                       └───────────┘                 └───────┘

1. View is a dumb renderer — it takes ready-made state and draws it; no business logic, just "show what I was given".
2. ViewModel holds state — it survives rotation (the ViewModelStoreOwner keeps it, rather than recreating it with the Activity).
3. Model — repositories, DB, network; the ViewModel talks to these, not the View directly.

⚠️ Common mistake: storing a View, Activity, or Context in a ViewModel field. The ViewModel outlives the View — after a rotation the reference points at a destroyed Activity, which is a memory leak. Need a Context? Use AndroidViewModel.getApplication() or inject @ApplicationContext.

Short answer: Retrofit is the top, declarative layer: it turns an annotated Kotlin interface into HTTP requests and parses the response via a Converter. OkHttp beneath it is the actual HTTP client: sockets, connection pool, cache, interceptors, timeouts, retries. Retrofit does not work without OkHttp — it is its transport.

In depth:

┌─────────────────────────────────────────┐
│ ApiService (interface + @GET/@POST)      │  ← your code
├─────────────────────────────────────────┤
│ Retrofit: annotations → Request,         │
│           Converter (JSON ↔ data class)  │
├─────────────────────────────────────────┤
│ OkHttp: interceptors, connection pool,   │
│         cache, timeouts, TLS, retry      │
├─────────────────────────────────────────┤
│ Socket / network                         │
└─────────────────────────────────────────┘

1. Retrofit — understands suspend and returns a ready data class; it does not parse JSON itself.
2. Converter — kotlinx.serialization / Moshi / Gson; this is what maps JSON ↔ object.
3. OkHttp — all the networking machinery; one OkHttpClient per app so the pool and cache are reused.
4. CallAdapter — suspend-function support out of the box.

⚠️ Common mistake: creating a new OkHttpClient/Retrofit per request. That throws away the connection pool and cache; the client should be a single instance for the whole app.