Senior Android Developer Interview Questions and Answers

Mid-level screens check whether you can implement features. Senior screens check whether you can own them across teams and production edge cases.

Common senior-only rounds:

• System design — feed, chat, checkout, or sync architecture on a whiteboard
• Code review — spot leaks, wrong scope, or fragile state
• Behavioral — STAR stories with metrics (crash rate, retention, latency)

Loops vary by company size, but a common pattern looks like this:

Some companies merge platform and architecture into one pair programming session on a take-home or shared repo.

What to bring: Two shipped apps you can whiteboard—data flow, testing strategy, and one hard bug or incident you fixed.

A senior prep plan should produce spoken narratives and one reference architecture, not only flashcards.

Daily habit: Pick one scenario—"user submits form on airplane mode"—and explain UI, domain, data, and recovery in under three minutes.

Most greenfield Android teams expect Compose fluency or a credible migration plan. Legacy View/XML still exists in large apps, but interviewers use Compose questions to test modern state management.

You do not need to be a Compose library author—but you should explain recomposition, remember vs rememberSaveable, and where state lives.

Kotlin is the interview default for new code. Seniors still encounter Java in older modules, SDK samples, and stack traces.

Interview tip: When asked about threading, connect coroutines as compiler-transformed state machines to why they scale better than raw threads for I/O.

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.

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.

inline copies bytecode at the call site—removing lambda allocation overhead and enabling reified generics at runtime.

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 everything 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.

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.

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. Disk (Room, DataStore, SavedStateHandle) survives; plain Activity fields do not.

A strong answer is:

I focus on what survives rotation vs process death. ViewModel and persisted storage survive configuration changes; only persisted state survives process death.

ViewModel survives configuration changes and exposes UI state to the screen.

Belongs in ViewModel:

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

Does not belong:

• Context, View, or Activity references (leaks)
• Navigation side effects without a clear pattern (prefer one-off events channel)
• 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.

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: Enable "Don't keep activities" and "Background process limit" in developer options; walk through your critical flows.

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.

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.

Compose runs in three phases for each frame:

Performance angle: Skipping recomposition is cheaper than laying out or drawing again. Stability and smart state reads reduce composition work.

A strong answer is:

Composition decides what UI should exist; layout positions it; draw renders it. Senior performance work targets skipping unnecessary composition first.

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.

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.

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

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

A strong answer is:

remember is in-process only. rememberSaveable survives process death for small UI state; large data belongs in Room or DataStore.

Compose side-effect APIs tie work to the composition lifecycle:

LaunchedEffect(userId) {
    viewModel.loadUser(userId)
}

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

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.

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.

Structured concurrency means every coroutine has a parent scope—when the scope cancels, children cancel too. No 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.

A strong answer is:

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

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

Senior nuance: Suspend does not mean background—only withContext or dispatcher choice moves work off Main. Room and Retrofit provide main-safe suspend APIs when used correctly.

A strong answer is:

Main for UI, IO for blocking I/O, Default for CPU. I use withContext explicitly when library code might block.

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

Exception handling: async exceptions surface at await()—use supervisorScope when one failure should not cancel siblings.

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.

private val _events = Channel<UiEvent>(Channel.BUFFERED)
val events = _events.receiveAsFlow()

UI events pattern: Prefer Channel or SharedFlow with replay=0 for navigation/snackbar—avoid re-firing on rotation.

A strong answer is:

StateFlow for state; SharedFlow or Channel for events that should not replay. I never put short-lived toast events in StateFlow without consuming them.

Common operators seniors should explain, not only name:

searchQuery
    .debounce(300)
    .distinctUntilChanged()
    .flatMapLatest { q -> repo.search(q) }
    .catch { emit(emptyList()) }

A strong answer is:

debounce plus flatMapLatest for search, distinctUntilChanged for UI, catch for graceful degradation—I explain backpressure and cancellation, not just operator names.

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

Senior point: Inject dispatchers—do not hardcode Dispatchers.IO inside ViewModels if you want fast unit 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.

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.

Typical layers:

Dependency rule: Inner layers never depend on outer layers. Domain defines repository interfaces; data module implements them.

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.

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 { it ?: User.empty(id) }

    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.

Modularization improves build time, enforces boundaries, and enables feature teams.

Rules: Feature modules do not depend on each other directly—navigate via interfaces or deep links. Share only through core APIs.

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.

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.

Offline-first apps read from disk first and refresh in the background.

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.

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.

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.

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.

Common causes: Disk/network on Main, over-recomposition, bitmap work on UI thread, lock contention.

Fix pattern: Move work to Dispatchers.Default/IO, use Baseline Profiles for startup, lazy list keys, image loading library with sizing.

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.

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.

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

A strong answer is:

I encrypt sensitive local data, avoid hard-coded secrets, minimize exported surfaces, and treat R8 as obfuscation—not a vault.

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

CI: run unit tests on every PR; shard instrumentation tests nightly.

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.

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: semantic versionCode monotonic for Play Store.

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.

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.

Clarify: One-to-one vs group, delivery receipts, offline queue, end-to-end encryption scope.

Battery: Batch heartbeats; use WorkManager for non-urgent sync.

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.

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

A strong answer is:

FCM delivers; the app routes through a single handler to navigation and analytics. I design for permission denial and data-only messages in background.

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.

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.

Technical drills:

• Explain lifecycle vs process death with Room recovery
• Whiteboard MVVM data flow from Compose to network
• Compare StateFlow vs SharedFlow and launch vs async
• Walk through Compose side effects and state hoisting
• Sketch offline-first sync with outbox + WorkManager
• Name Paging 3 + RemoteMediator responsibilities
• One performance story (jank, ANR, startup)

Cross-skill refresh:

• Java / JVM fundamentals for OOP and threading depth
• Design patterns vocabulary
• Git for CI and review flow
• Full stack guide if the role includes backend APIs

Behavioral:

• Three STAR stories—incident, conflict, technical decision
• Portfolio or Play Store links with 2-minute walkthrough each

A strong answer is:

In the final week I rehearse offline-first design aloud, drill Compose and coroutines trade-offs, and polish three STAR stories tied to shipped apps—not slides of API trivia.