Senior Android Developer Interview Questions and Answers

What interviewers are testing: Whether you design nullability at Java/API/storage boundaries rather than sprinkling !!.

Kotlin separates nullable and non-null types at compile time.

fun length(name: String?): Int =
    name?.length ?: 0

Senior follow-up: Prefer explicit null handling at boundaries (API, DB, intents). Avoid !! in production paths—use early return, requireNotNull, or checkNotNull with messages.

A strong answer is:

Kotlin encodes nullability in the type system. I use safe calls and Elvis at boundaries and treat !! as a code smell except in tests or proven invariants.

What interviewers are testing: Whether you distinguish value records from closed state/result hierarchies.

Both model structured data; the choice is about closed hierarchies vs flat records.

sealed class UiState {
    data object Loading : UiState()
    data class Success(val items: List<Item>) : UiState()
    data class Error(val message: String) : UiState()
}

Compose tie-in: Sealed hierarchies make when exhaustive—compiler forces you to handle every branch.

A strong answer is:

data class for product-shaped records; sealed class when the set of outcomes is fixed and I want exhaustive when without an else branch.

What interviewers are testing: Whether you understand what inlining changes and why erased generic type information can become available to reified parameters. inline asks the Kotlin compiler to inline the function body and eligible lambdas at call sites, which can reduce higher-order-function overhead and enables reified type parameters.

inline fun <reified T> Gson.fromJson(json: String): T =
    fromJson(json, T::class.java)

Interview use cases:

• Type-safe intent extras (inline fun <reified T> Bundle.getParcelable)
• DSL builders
• Performance-sensitive higher-order functions

Caution: Large inlined functions inflate bytecode—not every higher-order function should be inline.

A strong answer is:

inline plus reified lets me access T::class at runtime without passing Class objects—common for type-safe parsing and Android parcelable helpers.

What interviewers are testing: Whether you use extensions for cohesive receiver-specific behavior without pretending they add polymorphic members.

Extensions add behavior to existing types without inheritance—idiomatic Kotlin for Android APIs.

fun String.isValidEmail(): Boolean =
    Patterns.EMAIL_ADDRESS.matcher(this).matches()

Keep extensions discoverable—group in StringExt.kt, avoid dumping unrelated helpers on Context.

A strong answer is:

Extensions keep call sites readable for Android framework types. I avoid god-object extension files and prefer cohesive *Ext.kt modules.

What interviewers are testing: Whether you connect lifecycle callbacks to state survival and cleanup—not recite every callback. Interviewers care less about reciting every callback and more about state survival and resource cleanup.

Configuration change: Without ViewModel or rememberSaveable, rotation recreates the Activity—dropping in-memory state.

Process death: OS may kill your process under memory pressure. Persistent app data (Room, DataStore, files) survives; small restorable UI state uses SavedStateHandle or rememberSaveable; plain Activity fields do not.

A strong answer is:

I focus on what survives rotation vs process death. ViewModel survives configuration changes but not process death. After system-initiated process death, small restorable UI state can come from saved-state APIs, while durable application data comes from Room/DataStore/files.

What interviewers are testing: Whether you understand screen-level state ownership and lifetime, not treat ViewModel as a place for all logic. A ViewModel is retained while its ViewModelStoreOwner scope survives configuration changes. The enclosing owner—Activity, Fragment, navigation destination/graph, or other owner—determines lifetime.

Belongs in ViewModel:

• UI state (StateFlow, UiState)
• Calls to repositories / use cases
• Coroutine work in viewModelScope

Does not belong:

• Activity, Fragment, Context, or Resources references for convenience — Android architecture guidance discourages passing UI/context types into ViewModel and even discourages AndroidViewModel for new code
• Navigation side effects without a clear pattern (prefer representing outcomes in UI state)
• Android framework classes that tie to lifecycle shorter than the VM

class FeedViewModel(
    private val repo: FeedRepository
) : ViewModel() {

    private val _state = MutableStateFlow<UiState>(UiState.Loading)
    val state: StateFlow<UiState> = _state.asStateFlow()

    fun load() = viewModelScope.launch {
        _state.value = UiState.Success(repo.getFeed())
    }
}

A strong answer is:

ViewModel holds UI state and orchestrates use cases across rotation. I keep Android UI types out and survive process death with SavedStateHandle or Room—not memory-only fields.

What interviewers are testing: Whether you design for process death with SavedStateHandle and persistent storage—not in-memory-only state. Android may kill your entire process when memory is low. When the user returns, the app restarts—Activities and ViewModels are recreated.

Senior pattern: Single source of truth in Room; UI observes Flow from DB. Network refresh updates DB—not a fragile in-memory list.

Test: For recreation testing, use "Don't keep activities" or explicit Activity recreation. For real process-death restoration, use tooling/tests that kill the app process while preserving the task/saved state, then relaunch/return to the task. Do not treat Activity destruction alone as process death.

A strong answer is:

Process death wipes memory. I persist user-visible state in Room or DataStore and treat in-memory caches as optional performance layers only.

What interviewers are testing: Whether you can articulate Fragment/XML vs single-Activity Compose trade-offs and migration without duplicating business logic.

Modern apps often use single-Activity + Compose Navigation. Legacy apps use multi-Fragment navigation.

Interviewers want a migration story: new features in Compose, shared navigation graph, avoid duplicating business logic in both View and Compose layers.

A strong answer is:

I know Fragment back-stack rules for legacy code. For greenfield I prefer single-Activity Compose with Navigation-Compose and keep business logic in ViewModels and repositories either way.

What interviewers are testing: Whether you can connect composition, layout, and draw invalidation to performance diagnosis. Compose rendering is organized into three main phases: composition, layout, and draw. Depending on what state changes and where it is read, Compose may need to rerun only the affected phase(s).

Performance angle: State can invalidate composition, layout, or draw depending on where it is read. Reduce work in the phase that is actually hot; for rapidly changing visual values, deferring reads to layout/draw can sometimes avoid unnecessary recomposition.

A strong answer is:

Composition decides structure, layout measures/places it, and draw renders pixels. I profile which phase is doing excess work rather than assuming recomposition is always the bottleneck.

What interviewers are testing: Whether you understand state-read scopes and stability, not simply "avoid recomposition." Recomposition runs when state read during composition changes.

Reduction tactics:

val listState = rememberLazyListState()
val showFab by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 0 }
}

A strong answer is:

Recomposition follows state reads. I stabilize models, hoist state, use derivedStateOf for derived UI flags, and profile with Layout Inspector when lists jank.

What interviewers are testing: Whether you place state at the right owner while keeping reusable composables stateless where useful.

State hoisting moves state up to the lowest common owner so child composables stay stateless and reusable.

@Composable
fun SearchScreen(viewModel: SearchViewModel = hiltViewModel()) {
    val query by viewModel.query.collectAsStateWithLifecycle()
    SearchContent(
        query = query,
        onQueryChange = viewModel::onQueryChange
    )
}

@Composable
fun SearchContent(
    query: String,
    onQueryChange: (String) -> Unit
) {
    TextField(value = query, onValueChange = onQueryChange)
}

Rule: State flows down as parameters; events flow up as callbacks.

A strong answer is:

I keep leaf composables stateless—state lives in ViewModel or parent, children receive value plus event callbacks. That improves preview and testability.

What interviewers are testing: Whether you choose the right state survival API for composition, recreation, and process death.

Use rememberSaveable for small UI state—scroll position, expanded flags, draft text—not large lists (use Room).

Current Compose also provides rememberSerializable, which has similar saved-state lifetime semantics to rememberSaveable but uses Kotlinx Serialization for serializable custom types. Use it when that serialization model fits; keep saved state small either way.

Parcelable / list savers exist for custom types—mind Bundle size limits.

A strong answer is:

remember survives recomposition only while that composition remains alive. rememberSaveable and SavedStateHandle handle small UI state across recreation/process death; large data belongs in Room or DataStore.

What interviewers are testing: Whether you select an Effect API based on lifecycle and cleanup semantics. Compose side-effect APIs tie work to the composition lifecycle:

LaunchedEffect(snackbarMessage) {
    snackbarHostState.showSnackbar(snackbarMessage)
}

DisposableEffect(lifecycleOwner) {
    val observer = LifecycleEventObserver { _, event -> /* ... */ }
    lifecycleOwner.lifecycle.addObserver(observer)
    onDispose { lifecycleOwner.lifecycle.removeObserver(observer) }
}

Do not use LaunchedEffect merely to move ordinary screen initialization into composition when the ViewModel/data layer can own it directly.

A strong answer is:

LaunchedEffect for coroutine work keyed to composition; DisposableEffect when I must unregister on dispose; rememberUpdatedState to avoid stale lambdas in effects.

What interviewers are testing: Whether you migrate Views to Compose incrementally with shared data layers—not a big-bang rewrite.

Incremental migration beats big-bang rewrite.

Senior point: Measure crash and ANR rates per release; feature-flag Compose screens; keep navigation consistent.

A strong answer is:

I migrate screen by screen with shared ViewModels and data layers. Interop bridges let legacy and Compose coexist until the back stack is ready to simplify.

What interviewers are testing: Whether child work has bounded lifetime, cancellation propagation, and predictable failure behavior. Structured concurrency keeps related child coroutines inside an explicit scope so their lifetime, cancellation, and failure are tied to that scope—not orphaned work after the user leaves the screen.

viewModelScope.launch {
    val user = async { repo.loadUser() }
    val feed = async { repo.loadFeed() }
    _state.value = UiState.Ready(user.await(), feed.await())
} // cancelled automatically when ViewModel clears

Anti-pattern: GlobalScope.launch for UI work—survives the screen, leaks, hard to test. Contrast with detached/unstructured work that outlives its owner.

A strong answer is:

Structured concurrency ties async work to a lifecycle scope. I use viewModelScope or lifecycleScope—not GlobalScope—for UI-driven coroutines.

What interviewers are testing: Whether you distinguish blocking I/O, CPU work, and main-safe suspend APIs.

Dispatchers.IO is for blocking I/O APIs. Many modern Android clients already expose main-safe suspend functions — for example Retrofit suspend calls and Room suspend APIs — so callers should not blindly wrap every network/database call in withContext(IO) when the API is already main-safe.

suspend fun loadFeed(): List<Post> = withContext(Dispatchers.IO) {
    blockingFileApi.readPosts()
}

Senior nuance: Suspend does not automatically mean background — only dispatcher choice or a main-safe library implementation moves work off Main.

A strong answer is:

Main for UI, IO for known blocking I/O, Default for CPU work. I don't wrap every suspend API in IO—the data-layer API should be main-safe, and I move only genuinely blocking work.

What interviewers are testing: Whether you understand parallel results, failure propagation, and supervisorScope trade-offs.

coroutineScope {
    val profile = async { repo.profile() }
    val settings = async { repo.settings() }
    ProfileScreen(profile.await(), settings.await())
}

Exception handling: async stores a result in Deferred, and await() returns it or rethrows its failure. In a normal coroutineScope, failure of a child also cancels the scope and siblings; use supervisorScope when sibling failures should be isolated.

A strong answer is:

launch for side effects; async when I need parallel results and will await Deferred. I handle failures at await and consider supervisorScope for partial success.

What interviewers are testing: Whether you model durable UI state vs transient events with appropriate delivery semantics.

Current Android architecture guidance: StateFlow is the default for ViewModel UI state. For durable outcomes that must not be lost when the UI is absent, model them as state. For genuinely transient UI events, SharedFlow/Channel or Navigation-specific event mechanisms may still be appropriate if their delivery semantics match the requirement.

A strong answer is:

StateFlow for UI state. I model durable outcomes as state; for transient events I use SharedFlow or navigation event APIs when delivery semantics match the requirement—not a default Channel bus from every ViewModel.

What interviewers are testing: Whether you understand cancellation/switching semantics, especially for search and rapidly changing input. Common operators seniors should explain, not only name:

searchQuery
    .debounce(300)
    .distinctUntilChanged()
    .flatMapLatest { query ->
        repo.search(query)
    }

Handle errors without converting a failed request into a valid empty result—for example expose a typed success/error state from the repository or ViewModel.

A strong answer is:

debounce plus flatMapLatest for search, distinctUntilChanged for UI—I explain backpressure and cancellation, and handle errors in the repository or ViewModel without masking failures as empty results.

What interviewers are testing: Whether you can make async code deterministic through injected dispatchers and virtual time.

@Test
fun loadSuccess() = runTest {
    val vm = FeedViewModel(FakeRepo())
    vm.load()
    assertEquals(UiState.Success, vm.state.value)
}

Senior point: Prefer keeping blocking-dispatcher decisions in the data layer rather than making ViewModels switch to IO. Inject dispatchers where code actually owns blocking/CPU work and needs deterministic tests.

A strong answer is:

I use runTest with injected dispatchers and fakes for repositories. For Flow I assert emissions with turbine or collect in a controlled scope.

What interviewers are testing: Whether you choose MVVM or MVI based on screen complexity and team conventions—not pattern dogma.

MVVM (common Jetpack shape):

// ViewModel exposes StateFlow<UiState>
// View calls fun onIntent(action: UserAction)

MVI: UserIntent → reducer → UiState → UI (loop is explicit).

A strong answer is:

I default to MVVM with a single UiState data class for clarity. I choose MVI when the screen is a state machine with many transitions and I want intents logged for debugging.

What interviewers are testing: Whether architecture boundaries reduce coupling without adding ceremony for its own sake. Typical layers:

Dependency rule: In a strict Clean Architecture variant, domain-facing abstractions may be defined inward and implemented by data. In pragmatic Android architectures, repository interfaces can live at the boundary that best preserves module ownership and testability.

Pragmatic senior take: Not every app needs a UseCase class per action—avoid ceremony until the team benefits from test seams.

See design patterns for shared pattern vocabulary (repository, factory, observer).

A strong answer is:

UI observes ViewModels; ViewModels call use cases or repositories; data layer implements repos against Room and network. I keep domain Android-free and avoid use-case explosion on small teams.

What interviewers are testing: Whether the repository owns data-source coordination and consistency, not merely wraps Retrofit. Repository is the single API for data—UI does not care if data came from cache or network.

Responsibilities:

• Merge remote + local (Room as source of truth)
• Expose Flow for reactive UI
• Handle retry, error mapping, offline

class UserRepository @Inject constructor(
    private val api: UserApi,
    private val dao: UserDao
) {
    fun observeUser(id: String): Flow<User?> =
        dao.observeUser(id).map { entity -> entity?.toDomain() }

    suspend fun refresh(id: String) {
        val remote = api.getUser(id)
        dao.upsert(remote.toEntity())
    }
}

A strong answer is:

Repository hides data sources and exposes one observable API. UI collects Flow; refresh writes through to Room so offline still works—the ViewModel decides not-found vs empty UI.

What interviewers are testing: Whether module boundaries improve ownership/build isolation/API boundaries without producing dependency spaghetti. Modularization improves build time, enforces boundaries, and enables feature teams.

Rules: Prefer clear, acyclic feature dependencies. Where features need to collaborate, depend on narrow contracts/navigation APIs rather than reaching into another feature's internals.

A strong answer is:

I split by feature and core layers, keep dependencies pointing inward, and avoid feature-to-feature imports. Navigation contracts decouple teams.

What interviewers are testing: Whether you understand lifetime and dependency ownership, not annotation memorization. Dependency injection supplies dependencies from the outside—testable, swappable, lifecycle-aware.

@HiltViewModel
class FeedViewModel @Inject constructor(
    private val repo: FeedRepository
) : ViewModel()

Interview follow-up: Manual DI works for small apps; Hilt/Koin scale when graphs grow. Prefer constructor injection over field injection.

A strong answer is:

DI makes dependencies explicit and testable. I use Hilt for ViewModel and singleton bindings—fake repos in unit tests without Robolectric.

What interviewers are testing: Whether UI reads from a durable authoritative model while refresh/sync updates it. Many offline-first designs make a durable local data source such as Room the canonical read source, while network/sync updates it.

Benefits: Survives process death, rotation, and airplane mode without custom cache glue.

A strong answer is:

Room gives durable observable state. Network is an update mechanism, not the primary read path—users still see data when offline.

What interviewers are testing: Whether you design durable pending writes, idempotency, retries, and conflict semantics. Senior system-design favorite. Outline:

1. Local write — optimistic UI, queue mutation in outbox table
2. Background sync — WorkManager worker drains outbox when online
3. Conflict policy — last-write-wins, server version, or merge per field
4. Idempotency — client-generated IDs or request keys

Clarify with interviewer: Chat vs catalog vs financial data need different conflict rules.

A strong answer is:

I persist locally first, sync with WorkManager, and define conflict rules per entity type. I mention idempotency and what the user sees when sync fails mid-flight.

What interviewers are testing: Whether errors are translated into domain/UI decisions without leaking transport implementation details.

Map layers cleanly—do not leak HTTP codes into Compose.

sealed class NetworkResult<out T> {
    data class Success<T>(val data: T) : NetworkResult<T>()
    data class HttpError(val code: Int, val body: String?) : NetworkResult<Nothing>()
    data object Offline : NetworkResult<Nothing>()
}

A strong answer is:

I map transport errors to domain results in the repository and expose sealed UI state. Users get actionable messages and retry—not raw 502 text.

What interviewers are testing: Whether you understand paging keys, invalidation, refresh/append failure, and local/remote coordination.

Compose: PagingData + LazyColumn + collectAsLazyPagingItems().

Senior points: Duplicate keys break diffing; handle refresh vs append; empty and error states in LoadState.

A strong answer is:

I use Paging 3 with keyset APIs when possible. I explain placeholder behavior, retry, and how refresh invalidates the cache without duplicating items.

What interviewers are testing: Whether you distinguish ANR, jank, and startup bottlenecks before applying fixes.

ANR causes: Blocked main thread, locks, binder/I/O, long callbacks.

Jank causes: Expensive render/layout/draw, bitmap work, large lists.

Startup: Baseline Profiles, startup tracing.

A strong answer is:

I profile before guessing—Main thread stacks for ANR, recomposition counts for Compose jank. Fixes are moving blocking work off Main and stabilizing list state.

What interviewers are testing: Whether you can spot long-lived references retaining short-lived UI objects.

Tool: LeakCanary in debug builds; heap dumps for stubborn cases.

A strong answer is:

Leaks are usually long-lived references to short-lived UI. I match scope to lifecycle, remove listeners, and use LeakCanary in debug.

What interviewers are testing: Whether you can identify mobile-specific trust boundaries and storage/network/component risks.

Encryption-at-rest design depends on the threat model; do not assume a deprecated convenience wrapper makes secrets safe. EncryptedSharedPreferences and EncryptedFile from androidx.security:security-crypto are deprecated.

Proguard/R8: Obfuscation is not encryption—assume reverse engineering.

A strong answer is:

I minimize sensitive client storage, use Keystore where needed, avoid hard-coded secrets, minimize exported surfaces, and treat R8 as obfuscation—not a vault.

What interviewers are testing: Whether you place tests where they provide fast confidence with minimal implementation coupling.

Senior bar: Tests prove behavior, not implementation details—avoid asserting private methods.

CI: run fast unit/static checks on every PR; select critical instrumentation tests per PR and parallelize/shard broader device suites according to CI cost and risk.

A strong answer is:

Heavy unit coverage on ViewModels and repositories; fewer UI tests on money paths. I inject fakes and use runTest for coroutines.

What interviewers are testing: Whether the pipeline manages quality, signing, artifact promotion, and staged release risk. Typical pipeline:

1. Lint (Android Lint, detekt, ktlint)
2. Unit tests
3. Assemble debug/release
4. Instrumentation (optional per PR)
5. Sign & distribute (Firebase App Distribution, Play Internal)

Versioning: keep versionCode monotonically increasing for Play distribution; versionName can follow semantic/product versioning if the team chooses.

See Git interview questions for branch and review practices that pair with mobile CI.

A strong answer is:

Every PR runs lint and unit tests; release builds bump versionCode and go through staged rollout. I tie Git flow to what CI actually gates.

What interviewers are testing: Whether you design offline-first feeds with durable reads, sync ordering, retry, and battery-aware refresh. Structure your answer in layers:

Requirements to clarify: Read offline? Personalization? Media attachments? Stale tolerance?

Edge cases: Airplane mode mid-pagination, process death mid-scroll, duplicate pages on retry.

A strong answer is:

Room plus Paging with RemoteMediator, network as refresh path, WorkManager for background sync, and explicit stale-while-revalidate UX.

What interviewers are testing: Whether you balance real-time delivery, offline queues, ordering, and battery limits on Android. Clarify: One-to-one vs group, delivery receipts, offline queue, end-to-end encryption scope.

Battery: Batch heartbeats; use WorkManager for non-urgent sync. Do not rely on a continuously connected socket for background delivery—Android background limits and battery constraints make push + durable resync the safer model.

A strong answer is:

Optimistic UI with outbox, WebSocket when foreground, FCM plus sync on resume, Room as source of truth for history and pending sends.

What interviewers are testing: Whether you treat push as a wake signal and sync authoritative data—not as the source of truth.

Senior points: Notification channels, permission on Android 13+, dedupe, respect user opt-out, do not put secrets in payload.

A strong answer is:

FCM is a signal, not my source of truth. I handle notification permission and deep links, keep payloads non-sensitive, dedupe messages, and sync authoritative data when the app runs rather than assuming every background message gives me unrestricted execution.

What interviewers are testing: Whether you narrate a production incident with measurable impact and systemic follow-up.

Use STAR with mobile-specific detail:

• Situation — spike in ANRs or crashes after release
• Task — restore stability without rolling back entire feature
• Action — Play Console stack traces, reproduce on low-RAM device, hotfix, staged rollout
• Result — crash-free rate recovered, postmortem, added test or monitor

Mention Firebase Crashlytics, Play vitals, or internal dashboards if you have them.

A strong answer is:

I describe a measurable incident—ANR or crash rate—with how I triaged stacks, shipped a fix, and added guardrails so the class of bug cannot silently return.

What interviewers are testing: Whether you prioritize debt by user and team velocity risk—not architectural purity. Seniors are judged on trade-offs, not purity.

A strong answer is:

I prioritize debt that affects users or velocity—crashes, build times, flaky tests—and negotiate visible platform wins alongside features.

What interviewers are testing: Whether you integrate system Back, predictive gestures, and navigation state restoration consistently. Predictive back lets users preview where the system Back gesture will take them before completing the gesture.

Android's current guidance points new Compose apps toward modern single-Activity navigation with correct back-stack behavior rather than ad hoc per-screen back handling.

A strong answer is:

I design navigation so system Back, predictive back gestures, and restored navigation state all behave consistently—especially in single-Activity Compose apps.