Android Interview Questions — Part 4: Real Questions, Clear Answers

Not a Medium member? Read this story for free here — valid for 30 days.

Android interviews have changed a lot in recent years.
Many companies now include take-home tests or timed online quizzes during the hiring process.

These tests often ask multiple-choice questions with four options — only one of them correct. Some answers may look similar or even feel right. But the goal is to find the best one — and to understand why the others are wrong.

You probably won’t get these exact questions in your next interview.
But reviewing real examples like these can help you spot common patterns, avoid tricky mistakes, and feel more confident under pressure.

This article is Part 4 in a growing series.
Each part includes four questions I’ve collected from real interviews and technical assessments — with clear explanations of what’s correct, and why.

Android Interview Questions Series

• Android Interview Questions — Part 1
• Android Interview Questions — Part 2
• Android Interview Questions — Part 3
• Android Interview Questions — Part 4 ← you’re here

Question 1: remember vs rememberSaveable in Jetpack Compose

Real Interview Question:
What is the difference between remember and rememberSaveable in Jetpack Compose?

Options:

• remember automatically restores data across process death
• rememberSaveable persists data across configuration changes and process death
• both behave the same, only names differ
• rememberSaveable requires a database for persistence

Correct Answer:
rememberSaveable persists data across configuration changes and process death

Explanation:

remember stores state only during recomposition but loses it after configuration changes (like screen rotation) or process death.
rememberSaveable uses SavedInstanceState under the hood, keeping values across configuration changes and even process recreation.

Example:

var count by remember { mutableStateOf(0) }
var savedCount by rememberSaveable { mutableStateOf(0) }

Why the Other Options Are Incorrect:

• remember automatically restores data — false; it is not saved after configuration change.
• both behave the same — false; persistence behavior is different.
• rememberSaveable requires a database — false; it uses SavedInstanceState.

Conclusion:

Use remember for ephemeral state, and rememberSaveable for UI state that should survive configuration changes.

Question 2: suspend vs blocking function in Kotlin

Real Interview Question:
What is the main difference between a suspend function and a blocking function in Kotlin?

Options:

• suspend functions always create a new thread
• suspend functions can be paused without blocking a thread
• blocking functions run faster than suspend functions
• suspend functions must return Deferred

Correct Answer:
suspend functions can be paused without blocking a thread

Explanation:

A suspend function allows a coroutine to suspend execution without blocking the underlying thread. This makes them efficient for tasks like network calls or database queries. By contrast, blocking functions (like Thread.sleep) block the thread, preventing other coroutines from running.

Example:

suspend fun fetchData(): String {
 delay(1000) // suspends without blocking
 return "Data"
}

fun blockingWork() {
 Thread.sleep(1000) // blocks the thread
}

Why the Other Options Are Incorrect:

• suspend functions always create a new thread — false, they do not create threads; they reuse coroutine dispatchers.
• blocking functions run faster than suspend functions — misleading; performance depends on the operation, not the keyword.
• suspend functions must return Deferred — false; they can return any type.

Conclusion:

Use suspend for non-blocking concurrency. Use blocking only in dedicated worker threads where thread suspension is acceptable.

Question 3: DiffUtil in RecyclerView

Real Interview Question:
Why is DiffUtil preferred over calling notifyDataSetChanged() in RecyclerView?

Options:

• DiffUtil always runs on the main thread for better UI performance
• DiffUtil calculates the minimal set of updates efficiently
• notifyDataSetChanged is deprecated
• DiffUtil automatically updates database values

Correct Answer:
DiffUtil calculates the minimal set of updates efficiently

Explanation:

DiffUtil compares old and new lists in the background and calculates minimal changes (insertions, removals, updates). This avoids redrawing the entire list and improves performance.

Why the Other Options Are Incorrect:

• runs on main thread — false; it should be used off the main thread.
• notifyDataSetChanged is deprecated — false; it is not deprecated, just less efficient.
• automatically updates database — false; it only updates UI, not data sources.

Conclusion:

Use DiffUtil for efficient RecyclerView updates instead of invalidating the entire list.

Question 4: Difference between launch and async

Real Interview Question:
What is the main difference between launch and async in Kotlin coroutines?

Options:

• launch returns a Job, async returns Deferred
• launch blocks the thread, async does not
• async always runs in parallel, launch does not
• both are identical, only syntax differs

Correct Answer:
launch returns a Job, async returns Deferred

Explanation:

launch is used to start a coroutine that does not return a result. It returns a Job.
async is used when you need a result from the coroutine. It returns a Deferred<T>, which can be awaited.

Example:

val job = scope.launch {
 println("Job started")
}

val deferred = scope.async {
 return@async 42
}
println(deferred.await()) // 42

Why the Other Options Are Incorrect:

• launch blocks the thread — false; neither blocks the thread.
• async always runs in parallel — false; depends on dispatcher.
• both are identical — false; they differ in return type and usage.

Conclusion:

Use launch for fire-and-forget tasks, and async for concurrent tasks that return results.

Summary & What’s Next

The questions in this article are based on real screening formats used in Android hiring processes — practical, time-limited, and often deceptively simple.

The goal isn’t just to find the right answer, but to understand why it’s correct — and why the others are not. That’s what builds clarity and confidence, especially under pressure.

This is Part 4 of an ongoing series.
Each part includes four questions and explanations, covering key areas of Android development — from UI state and Compose behavior to architectural decisions and Kotlin modeling.

If you found this helpful, follow along for upcoming parts.
You’ll be better prepared not just for interviews but for writing better, safer Android code every day.

You might also like:

Tricky Android Interview Questions: Context & Activity Edition

When Kotlin object Stops Being a Singleton

Tricky Android Interview Questions: Kotlin Coroutines Edition

Anatolii Frolov
Senior Android Developer
Writing honest, real-world Kotlin & Jetpack Compose insights.
📬 Follow me on Medium