Android Developer Interview Questions — Complete 2026 Guide

Hiring managers are not asking whether you know Android. They are asking whether you can ship Kotlin and Jetpack Compose code that survives a production incident at 2 a.m. The Android developer interview questions used in 2026 reflect that shift: less trivia about activity lifecycles, more pressure on coroutines, state management, and the migration decisions that define modern apps. This guide covers what actually gets asked, how answers get scored, and where candidates lose offers they should have won.

The Android Developer interview funnel

A typical Android developer interview loop in 2026 runs four to six stages over two to four weeks. The recruiter screen confirms compensation expectations, work authorization, and a rough sense of Kotlin and Compose depth. Roles at well-funded startups quote $120K to $155K base for mid-level engineers and $150K to $190K for seniors with real Compose architecture experience, so know your number before that call.

The technical screen is usually a 60-minute live session covering Kotlin fundamentals, one coroutine question, and a small coding task. Companies that hire from a global talent pool often run a take-home instead: build a small app that fetches paginated data, handles configuration changes, and ships tests. Take-homes that touch Paging 3, Hilt, and Compose now get auto-rejected if the candidate uses XML Views without justifying the choice.

Onsite or virtual onsite rounds split into three buckets. A coding round tests algorithms at medium difficulty, but the framing is usually Android adjacent: parse a deep link, deduplicate a list of contacts, or build a small in-memory cache with TTL. A deep-dive technical round drills into one project from the resume; expect to whiteboard the architecture, defend trade-offs, and explain what you would change. A system design round for senior candidates covers offline-first sync, push notification fan-out, or video upload with resumable transfer.

The final stage is the hiring manager round. This is where decisions actually get made. Strong technical answers do not save a loop where the manager doubts your judgment, ownership, or ability to disagree without burning the relationship.

Kotlin, Jetpack Compose, Android SDK questions

Kotlin coverage starts with the basics and accelerates fast. Interviewers ask the difference between val and var, then immediately follow up: does val guarantee immutability of the contained object? The right answer is no — a val reference to a MutableList still allows mutation, and true immutability requires listOf or persistent collections.

Coroutines questions dominate the middle of the screen. Structured concurrency, where a parent coroutine cannot complete until its children finish and cancellation propagates downward, is the framing interviewers want. Be specific about viewModelScope cancelling when the ViewModel clears, lifecycleScope tying to the host lifecycle, and SupervisorJob isolating failures so one failing child does not cancel siblings. Candidates who confuse launch and async or who never explain withContext switching dispatchers without creating a new coroutine routinely fail this section.

Jetpack Compose questions test recomposition mechanics more than syntax. Expect to explain why remember survives recomposition but not configuration change, when to reach for rememberSaveable, and how derivedStateOf prevents recomposition when an upstream state changes but the derived value does not. The StateFlow versus LiveData comparison comes up in almost every Compose-heavy interview: StateFlow is the Kotlin-native reactive stream usually exposed from the ViewModel, while Compose’s State<T> triggers recomposition directly. The bridge is collectAsStateWithLifecycle, which respects lifecycle and avoids the bug where collectAsState keeps collecting in the background.

Android SDK questions narrow to lifecycle and process death. ViewModel survives configuration changes but not process death without SavedStateHandle. WorkManager handles deferred and guaranteed background work; foreground services handle ongoing user-visible tasks. Knowing which API to pick for a given constraint matters more than reciting documentation.

Architecture and patterns questions

MVVM is the floor. Every Android developer should explain unidirectional data flow, why ViewModels expose state and accept events, and how the view layer stays dumb. Beyond that, hiring managers want to hear a real opinion on MVI, Clean Architecture, and modularization.

MVI pairs cleanly with Compose because both treat UI as a function of state. Be ready to describe an MVI implementation: a single UiState data class, intents or actions flowing in, a reducer producing the next state, and one-shot effects routed through a Channel or SharedFlow. Interviewers test whether you understand why one-shot events (navigation, snackbars) cannot live in the main state without causing replay bugs.

Clean Architecture appears in senior rounds. The expectation is layered separation: a domain layer with pure Kotlin use cases and entities, a data layer with repositories and data sources, and a presentation layer with ViewModels and Composables. The follow-up question is always the same: when is this layering overkill? A good answer acknowledges that two-screen apps rarely need use cases and that ceremony without payoff is a code smell.

Dependency injection questions center on Hilt. Know @Inject, @Singleton, @HiltViewModel, the difference between @Binds and @Provides, and how to scope a dependency to a specific Compose navigation graph. Dagger fundamentals still matter because Hilt is built on Dagger, and at least one interviewer per loop will ask what Hilt generates under the hood.

Modularization questions probe trade-offs. A :feature:onboarding module that depends on :core:designsystem and :data:user is the typical pattern. Be ready to explain why feature modules speed up builds, where Gradle convention plugins reduce boilerplate, and when a dynamic feature module is worth the complexity over a regular module.

Performance and memory questions

Performance rounds start with ANR debugging. The bar is concrete: name the threshold (5 seconds for input, 10 for foreground services), describe how to reproduce one, and walk through the StrictMode, Android Profiler, and Perfetto workflow for finding the blocking call. Mention how Dispatchers.IO keeps disk and network off the main thread and how Dispatchers.Default handles CPU-bound work.

Memory leak questions assume you know LeakCanary by name. The classic leak is a static reference to an Activity or a long-lived listener holding a Context. A weaker answer recites this without describing how to fix it. A stronger answer mentions weak references, the lifecycle-aware LifecycleEventObserver pattern, and the rule that you never store a Context in a singleton.

Baseline Profiles and startup time get heavy coverage at senior level. A Baseline Profile is a generated list of classes and methods pre-compiled by ART at install time, cutting cold start by 20% to 40% in measured apps. Bringing a specific number from your own work — “we reduced p95 cold start from 1.8s to 1.1s after adding Baseline Profiles and pre-warming the Room database” — is the answer hiring managers remember.

R8 minification questions test whether you have actually shipped a release build. Know that R8 combines shrinking, optimization, and obfuscation; that ProGuard rules go in proguard-rules.pro; and that Compose runtime requires specific keep rules that the AndroidX team publishes. The follow-up is usually about reflection: serialization libraries like Moshi and kotlinx.serialization need rules to survive minification, and forgetting them causes crashes only in release.

Macrobenchmark and jank measurement round out the performance section. Be able to describe a CI pipeline that runs Macrobenchmark on a physical or emulated device, captures FrameTimingMetric, and fails the build if p99 frame time regresses.

What hiring managers look for

Strong technical answers are necessary but not sufficient. The candidates who get offers in 2026 demonstrate three traits beyond knowing Kotlin.

The first is judgment about migrations. Compose migration is the loudest hiring pattern right now because teams need engineers who have done one before. If your last project converted 30 XML screens to Compose, lead with that: which screens went first, how you handled interop with AndroidView and ComposeView, what testing strategy survived the transition, and how you measured that performance did not regress. Specifics beat generalities every time.

The second is incident ownership. Every senior Android engineer should have a story about a production issue they led: an ANR spike after a release, a memory leak that crashed low-end devices, a crash loop that bypassed staged rollout. The framing matters — describe how you triaged with Crashlytics or Sentry, narrowed the root cause, shipped the fix, and prevented recurrence. Candidates who blame other teams or describe being told what to fix sound junior regardless of years on the resume.

The third is product literacy. Hiring managers want engineers who ask “should we build this?” before “how should we build this?” If you pushed back on a feature because the metrics did not justify the engineering cost, or proposed a simpler alternative that shipped twice as fast, say so. The engineer who reduces scope is more valuable than the one who silently absorbs it.

Communication closes the loop. Explaining a technical decision to a non-technical product manager, writing a clean ADR, or running a calm incident review carries as much weight as your coroutine knowledge.

Questions to ask them

Smart questions reveal seniority. Avoid generic prompts about culture. Ask about the codebase and the team’s actual constraints.

Start with the Compose migration. What percentage of screens are on Compose today? What is blocking the rest? Which Compose stability problems have they not solved yet? The answer tells you whether you will spend your first six months on greenfield work or rescuing legacy XML.

Ask how the team handles modularization. Is the project monolithic or modularized? Are convention plugins used? How long does a clean build take, and how long does an incremental Compose change take to hot reload? Long incremental builds are a daily tax that recruiters never mention.

Probe quality infrastructure. Do they run Macrobenchmark in CI? What is the current crash-free rate and ANR rate? Who owns release management — a release engineer, a rotating duty, or the feature team that broke last? These questions surface dysfunction faster than any company review site.

Ask about ownership boundaries. Does the Android team own backend contracts, or does a separate API team define them? Who decides when to deprecate an endpoint? How are A/B tests rolled out, and who reads the results?

Close with a question for the hiring manager personally. What does success look like in the first 90 days? What was the last hard decision they made about the Android stack? Their answer reveals whether they actually have authority or are forwarding decisions upward.

Common mistakes

The most common mistake is over-rehearsing definitions. Reciting “coroutines are lightweight threads” without explaining structured concurrency or cancellation reads as memorized rather than understood. Interviewers prefer a slightly hesitant candidate working through a real example over one who delivers a polished but shallow definition.

The second mistake is ignoring trade-offs. Every Android architecture choice has costs. Saying “we used Clean Architecture because it is best practice” without acknowledging the boilerplate is a red flag. A senior answer names the trade-off explicitly: more files and indirection, slower onboarding for new engineers, in exchange for testability and a domain layer that survives UI rewrites.

The third mistake is underestimating debugging questions. Candidates spend hours on algorithm prep and skip ANR triage. When the interviewer asks how you would investigate a 30% crash spike in the latest release, vague answers about “checking Crashlytics” lose points. A strong answer names the tools (Crashlytics, Sentry, Logcat, Perfetto, Android Profiler), describes how you would correlate the spike with the release cohort, and explains how you would roll back if needed.

The fourth mistake is dismissing testing. Saying “we did not have time for tests” in a senior interview is disqualifying. Even if the previous team neglected tests, a strong candidate describes how they introduced tests incrementally: snapshot tests for Compose, runTest for ViewModels, Robolectric or Espresso for integration coverage.

The last mistake is treating the offer as binary. Every Android developer interview is a two-way evaluation. Pushing back on a question, asking for clarification, or proposing a different approach demonstrates seniority. Candidates who agree with every hint and follow every breadcrumb signal that they will not raise concerns once hired.