Android Developer Interview Questions 2026

Last updated: August 9, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

The Android questions worth asking in 2026 cover Jetpack Compose state, coroutine cancellation, and a target-SDK migration the candidate actually shipped. Everything else on the standard list is vocabulary, and vocabulary is the part candidates study the night before. Ask about the migration first. It is the only question on this page that predicts the first ninety days.

A retail company in Plano ran five rounds on an Android req last winter and hired a candidate who was genuinely good at the interview. He named all four launch modes without pausing. Fast, too. He drew the Activity lifecycle on a whiteboard from memory, including the states nobody uses. Two people on the panel wrote “strongest technical we have seen” in the debrief.

Week nine, they bumped targetSdk to 36 in a release branch. Then it broke.

The bottom navigation bar rendered underneath the gesture pill on every device running the new build. Their checkout button, the one that produced revenue, sat about eleven pixels below the point where a thumb could reach it. QA caught it. Barely. The fix took a week and a half because nobody on that team had ever written a WindowInsets handler, and the person they had just hired for exactly this kind of work had spent his entire career in a codebase where someone else owned the shell.

Nobody had asked. Not once in five rounds.

Worth knowing where I sit before you weigh any of this. I helped start KORE1 in 2005, we run a mobile developer recruiting desk and a Kotlin developer staffing practice inside our broader IT staffing services group, and our revenue arrives when you hire somebody we sent. Two sections below tell you to promote an engineer you already have instead of opening a req. One tells you to delete a round. That is a strange thing for a staffing company to publish and I would rather say it than watch another client repeat the Plano loop. So it stays.

The Date Your Next Hire Inherits

Twenty-two days.

On August 31, 2026, Google Play stops accepting new apps and app updates that do not target Android 16, API level 36. Eligible teams can request an extension to November 1. Wear OS and Automotive OS get API 35, Android TV and Android XR get API 34, and everyone else gets the full jump. No partial credit. If your app is not there yet, the person you hire this month walks into that work on day one, which makes it a strange thing to leave out of the interview.

Targeting 36 is not a version-number edit. Apps targeting Android 16 can no longer opt out of edge-to-edge, because windowOptOutEdgeToEdgeEnforcement is deprecated and disabled. Predictive back turns on by default, so onBackPressed() stops getting called and KEYCODE_BACK stops being dispatched. On any display with a smallest width of 600dp or more, the platform ignores android:screenOrientation, resizeableActivity="false", and both aspect-ratio attributes, along with the runtime setRequestedOrientation() call, which means a tablet layout your team locked to portrait four years ago is now going to rotate whether or not anyone designed for it.

Portrait lock is done. There is a per-activity opt-out for the resizability piece. It expires at API 37.

So the honest framing for a hiring manager is this. You are not interviewing for Android knowledge in general. You are interviewing for the ability to carry a real app across a platform boundary that has a date attached, and that is a much narrower and much easier thing to test than most panels realize.

Four Things the Loop Has to Prove

Everything below is a way of asking one of these.

Four rounds. Under five hours of candidate time, total. Any loop longer than that is losing you people who have three other processes running, and in this market most of the engineers you want do.

Compose Questions That Actually Separate People

Compose is not the future. It is the floor. On July 28, 2026, the Android team published a five-year retrospective confirming that more than 68 percent of the top 1,000 Play Store apps run it in production, and stating that Google is Compose-first with the Views toolkit in maintenance mode. Material Design moved over entirely. New APIs land in one toolkit now.

Which means a Compose question is no longer a bonus round. It is the round.

Show me a composable that recomposes more than it should, and tell me how you found out.

The best version of this question uses your own code. Pull a screen from your app, hand it over, and let them talk.

Weak candidates talk about remember in the abstract. They know it exists. Vaguely. They will tell you it caches things. Strong candidates go somewhere specific almost immediately, usually to an unstable parameter type, a lambda being reallocated on every pass, or a list of data classes that Compose cannot infer stability for. Then they tell you how they measured it, and the answer is Layout Inspector’s recomposition counts or the Compose compiler metrics report, not intuition.

The follow-up matters more than the answer. Ask what they did after they found it. Then wait. Anybody can identify an unstable parameter. Far fewer people have argued with a teammate about whether wrapping something in @Immutable is a lie about the data.

Where does this state belong, and who owns it?

Give them a screen with a search field, a filtered list, and a bottom sheet. Ask where each piece of state lives. Then be quiet.

You are listening for a candidate who distinguishes between UI state that can die with the composable and business state that has to survive process death. rememberSaveable versus SavedStateHandle in a ViewModel is the surface answer. The real signal is whether they ask you a question back, something like whether the search term needs to survive the user getting a phone call during a low-memory event on a three-year-old Pixel.

Candidates who have shipped ask that. Candidates who have only built demos do not, because in a demo the process never dies.

Talk me through a Compose interop boundary you had to maintain.

This is the question that finds migration experience without asking about migration directly.

An engineer who has run ComposeView inside a Fragment, or an AndroidView wrapping something Compose has no equivalent for, will have opinions. Strong ones, usually delivered with a small sigh. They will mention theme bridging, or the way lifecycle ownership gets confusing at the seam, or a scrolling conflict inside a nested RecyclerView. Greenfield-only candidates have nothing here. That is not disqualifying. It is information, and if your codebase is 200,000 lines of XML with Compose bolted on at the edges, it is the most important information the loop will produce.

Coroutines, and the Bug Nobody Can Reproduce

Every Android team I talk to has one. It shows up in Crashlytics twice a week, always on a different device, and nobody can trigger it locally. Nobody ever can.

Usually it is scope.

A network call keeps completing after the user has already left the screen. Walk me through it.

Let them ask clarifying questions. The good ones will.

What you want to hear is a candidate reaching for structured concurrency without being prompted, asking which scope launched the call, and getting to viewModelScope versus a scope tied to the composition versus something somebody started in GlobalScope in 2022 and never revisited. Bonus points if they bring up NonCancellable and immediately explain why almost nobody should use it.

Weak answers add a null check on the view and call it fixed. It is not fixed. That candidate has treated a lifecycle bug as a rendering bug, which is the exact failure that produced the Crashlytics entry in the first place.

When would you use a hot flow instead of a cold one, in an app, not in a definition?

The phrasing is deliberate. Almost every candidate can recite the difference between Flow and StateFlow. Very few can tell you about a time it mattered.

Listen for a real example. Location updates shared across three screens. A WebSocket feed that should not open four connections because four collectors subscribed. An engineer who has been burned by SharedFlow replay semantics will say so, and they will usually be able to tell you the exact replay value they settled on and the argument they had about it.

Something is dropping frames on a mid-range device but not on your Pixel. First three moves.

I like this one because there is no clean answer and the reasoning is the whole point.

Reasonable first moves include Macrobenchmark with a Baseline Profile check, a systrace or the Android Studio profiler on the actual device, and looking at whether work is happening on the main thread inside a composable’s body. Unreasonable first moves include buying a better test device and adding launch(Dispatchers.IO) around something at random until it stops. I have heard the second one more than once. Twice this year.

The Migration Round Almost Nobody Runs

This is the section I would keep if you deleted the rest.

Nearly every Android loop we audit for a client has zero questions about shipping through a platform change. Zero. Meanwhile the single largest chunk of work waiting for the person you hire this quarter is a target-SDK bump with a hard date on it, plus whatever fell over the last time somebody tried.

Tell me about a targetSdk bump you owned. What broke that you did not expect?

Open with this. Not round three. The screen.

Real answers have texture. Someone will tell you about scoped storage eating a file picker flow, or the Android 13 notification permission quietly dropping their delivery rate, or Android 14 foreground service types rejecting a build at review with a message that explained nothing. Someone else will describe two weeks of insets work and a designer who did not believe the status bar could overlap anything. It can.

Candidates who have not done one give you the changelog. Word for word. They will describe what Android 15 changed in general terms, accurately, in a way that sounds informed and tells you nothing about their app. That gap is easy to hear once you know to listen for it. The tell is the absence of a specific annoyance.

Your app locks tablets to portrait. It targets 36 next sprint. What now?

A scenario question with a correct-ish answer, which makes it useful for calibrating the whole panel.

You are looking for them to know the orientation lock stops working above 600dp, to reach for the temporary per-activity property rather than pretending the problem is not real, and to say out loud that the opt-out dies at API 37 so this is a deferral rather than a fix. Then the good ones start asking about your layouts. How many screens, how much of it is Compose already, whether anybody has ever run the app on a foldable in the unfolded state.

That last question is the one I want candidates to ask. Almost nobody does.

How do you ship a risky platform change without a bad week?

Staged rollout percentages. Play Console’s pre-launch report across the device matrix. A crash-rate gate defined before the release, not negotiated after it. Feature flags around the parts most likely to regress, and a rollback plan somebody has actually rehearsed.

If the answer is “we test it thoroughly,” ask what percentage they roll out to on day one. Then count. The silence after that question is diagnostic.

Kotlin Multiplatform, and When Not to Ask About It

KMP usage among developers surveyed by JetBrains went from 7 percent in 2024 to 18 percent in 2025. Forbes, Philips, Cash App, and Quizlet run it in production. It is real, it is growing, and Google has backed it since I/O 2024.

It is also the single most common way I see clients accidentally shrink their own candidate pool.

If you have no KMP in your codebase and no committed plan to add it, do not put it in the req and do not ask about it in the loop. You will filter out excellent Android engineers in favor of people who list a technology you are not going to use, and you will pay a premium for the privilege. We have watched a client in Denver run eleven weeks on a req like that. They removed one bullet from the job description and filled it in nineteen days. One bullet.

If you do have shared business logic, then ask properly. What did they put in commonMain and what stayed platform-specific, and why. How they handled the iOS side of a coroutine boundary. Whether the shared module made the build slower and what they did about it. Those questions find people who have lived with the tradeoff rather than people who watched a conference talk about it.

Six Questions to Retire

These are still in most Android loops. They were reasonable in 2016.

Asking a candidate to list the Activity lifecycle callbacks tests memorization of something Android Studio autocompletes and Compose largely abstracted. Launch modes have the same problem, and worse, the correct answer for most modern apps is a single-Activity architecture where the question barely applies. “What is the difference between Serializable and Parcelable” has been a trivia question since kotlin-parcelize made it a one-line annotation. Asking which is faster, RecyclerView or ListView, in 2026 is a question about a toolkit in maintenance mode. Whiteboard sorting algorithms tell you about interview preparation and nothing about whether someone can find a frame drop. And “what is your favorite Android library” gets you a name, then an awkward pause, then a story about a job you are not hiring them for.

Replace all six with one request. Just one. Show me an app you shipped, open the code, and tell me what you would fix if you had a free sprint.

That single question does more work than the six it replaces. It is also harder to prepare for, which is the point.

How to Score It Without Arguing for an Hour

Three axes. Four points each, no half points, and a written justification required for anything above a three.

1. Platform judgment. Do they know what the OS will do to their app without asking permission, and do they plan around it?
2. Debugging under uncertainty. Given a crash they did not cause, do they narrow methodically or guess confidently?
3. Migration tolerance. Have they carried a real app through a version boundary and can they describe the ugly parts without flinching?

The written justification does more for the debrief than the score does. Every time. Two interviewers who disagree about a candidate usually turn out to be scoring different things, and the sentence each of them wrote makes that visible in about ninety seconds.

Match the Loop to the Band You Can Actually Pay

A five-round senior loop attached to a mid-level budget is the most common reason a search stalls. By a distance. Not the market. The mismatch.

Those bands come from our own placement data and the aggregator spread we track, broken out by city and years of experience in the Android developer salary guide. If you want to sanity-check a number against your own market before you post the req, the salary benchmark assistant takes about two minutes.

For context on the wider pool these hires come from, the Bureau of Labor Statistics put the median software developer wage at $132,684 in its May 2025 data, with 15 percent growth projected through 2034. Android specialists sit above that median at the senior end and below it at the junior end, which is roughly what you would expect from a specialization with a narrow talent pool and a wide experience range.

What Comes Up After the First Slate

How many rounds should an Android loop actually run?

Four, for a senior hire. A screen with the migration question in it, a Compose and state conversation, a debugging session on real code, and a cross-functional round with product and QA. Anything past four and you start losing candidates to faster processes. Our average time-to-hire across IT searches is 17 days, and the loops that break that number are almost always the six-round ones where two of the rounds duplicate each other.

Our codebase is still mostly XML. Should we screen out Compose-only candidates?

Wrong direction, slightly. Screen out nobody on that basis, but weight interop experience heavily, because an engineer who has only built greenfield Compose has never had to make two toolkits share a theme and a lifecycle. The engineer you probably want is the one who did the migration at their last company and complains about it. That complaint is the credential.

Is a take-home fair for senior Android candidates?

Usually not, at least not the kind that asks them to build something. Senior Android engineers have families and other offers, and a six-hour build is a filter for availability rather than skill. Send them a real screen from your codebase with a known bug in it and ask for a written diagnosis instead. Thirty minutes of their time, more signal than the build, and the ones who diagnose it correctly will also tell you two other things they noticed. Those two other things are usually the reason to hire them.

Should candidates be allowed to use AI assistants in the technical round?

Allow it, then watch how they use it. JetBrains found 85 percent of developers already using AI tools in its 2025 State of Developer Ecosystem report, so banning it during the interview tests a workflow nobody uses at work. The interesting part is whether they verify what comes back. A candidate who accepts a generated WindowInsets handler without checking it against the actual API told you something. So did the one who read it, caught a deprecated call, and said so.

Android engineer or Kotlin Multiplatform engineer. Which title do we post?

Post Android unless shared code already exists in your repo. The KMP title narrows your applicant flow to a fraction of the market and raises your band without giving you anything if the shared module never gets built. Companies with real KMP investment should absolutely say so, since it is a genuine draw for a certain kind of engineer. Aspirational KMP in a job description just costs you six weeks.

What band gets a senior Android engineer to take the call?

$150,000 and up in most U.S. metros, higher in the Bay Area and Seattle. Below $140,000 for a senior title, our recruiters are mostly reaching people who are between roles rather than people who are currently employed and happy, and that changes the shape of your slate more than any sourcing tactic will. If the band cannot move, move the title and the scope instead. A well-scoped mid-level req at $135,000 fills. A senior req at $135,000 does not.

Contract-to-hire, or direct?

Contract-to-hire works better here than for most engineering roles, because the output is visible fast. Thirty days in, either the target-SDK branch is moving or it is not. The catch is that strong Android candidates in this market usually have direct offers, so your conversion pool skews toward people between roles or people who want to see your codebase before committing. Our contract staffing desk runs these as 90-day evaluations with the conversion trigger written down in advance, and the hires who convert land inside the 92 percent twelve-month retention rate we track.

Where I Would Start on Monday

Move the migration question into the phone screen.

Most panels save it for the technical round, which is round three, which is after somebody on the team has already decided they like the candidate. By then a thin answer becomes a thing to explain away rather than a filter. Put it twenty minutes into the first call instead and it will change who reaches your onsite. Costs nothing to try.

The rest of the loop can stay exactly as it is. Honestly, that one move plus deleting the launch-modes question would fix most of the Android interviews I have seen this year, and I say that as someone whose company benefits when your search takes longer.

If the slate keeps showing up full of people who can recite the lifecycle and cannot describe a migration, talk to our recruiting team. We have run mobile searches across 30-plus U.S. metros since 2005 and we will tell you honestly whether the problem is your req, your band, or the market.

Still scoping the role? Our 2026 guide to hiring an Android developer covers the sourcing pipeline that feeds this loop, and the mobile developer job description template gives you a req that produces the right applicants before any of this starts. If you are staffing both platforms, hiring an iOS developer runs on a different calendar and a different set of platform deadlines.