How to get hired as an Android developer in 2026-27

Which Android job you are actually applying to

Three distinct jobs are advertised under Android titles and they do not share an interview. The first and largest is Android application development: Kotlin, Jetpack Compose, a backend you consume over HTTP, and a release that goes through Google Play. The second is Android platform or AOSP engineering: C++ and Java in the framework and below, hardware abstraction layers, SELinux policy, kernel-adjacent debugging, custom system images and device bringup, hired by handset makers, silicon vendors, automotive suppliers building Android Automotive OS, and companies shipping kiosks, point-of-sale terminals and ruggedized handhelds. The third is SDK or library engineering: you ship an AAR that other developers compile into their apps, so binary compatibility, public API design, method count and size budget, and never owning an Activity of your own define the work. Applying to the second with a portfolio of Compose screens wastes everyone's time.

Inside application development, read the title carefully. 'Android Developer' and 'Android Engineer' are usually the same job on different ladders, and the ladder matters: at companies with a unified software engineering job family, mobile engineers are levelled and paid alongside backend engineers, while at companies with a separate 'mobile' family the bands are sometimes lower and almost impossible to change after you accept. 'Mobile Engineer' usually means you are expected to work on both platforms, or on a cross-platform stack, and you should ask in the first call which it is. 'Senior Android Engineer, Platform' inside a product company usually means the internal platform: build system, CI, release tooling, design system, modularization, the shared libraries other app teams depend on. That is a good job and a different interview, weighted toward Gradle, dependency graphs and developer experience rather than screens.

The cross-platform question is real and you should answer it honestly rather than defensively. Flutter and React Native hold a meaningful share of new consumer app work, particularly at startups and agencies where one team must serve both platforms on one budget. Kotlin Multiplatform has moved from curiosity to a defensible choice for sharing the data and domain layers while keeping native UI, and Compose Multiplatform extends that to shared UI for teams willing to take it. None of this removed native Android roles. The companies with the largest, oldest, most regulated or most performance-sensitive apps overwhelmingly stayed native, and they are the ones hiring Android specialists. What shrank is the generic 'build screens from a Figma file' job at small companies, which is now often done cross-platform or by one generalist.

The sector matters more than the title for what your week looks like. Banking and fintech means security review, certificate pinning, device integrity checks, long regression cycles, strict release trains and a lot of existing XML. Retail and commerce means deep links, payments, performance on low-end devices and seasonal code freezes. Delivery and logistics means location, foreground services, battery, and fighting aggressive OEM process killing on devices sold in markets you do not live in. Media and streaming means Media3 and ExoPlayer, DRM, casting, TV and Auto surfaces. Healthcare means privacy controls and audit requirements. Automotive means Android Automotive OS, a different UI situation driven by distraction guidelines, and a hardware release cycle measured in years.

Finally, note whether the posting treats Android as a product surface or as a cost centre. Postings that name Android Vitals, crash-free rate, startup time, experiment frameworks or release ownership come from teams where mobile engineering has authority. Postings that list only 'implement designs', 'fix bugs' and 'work with the team' and name no tooling at all are usually staff-augmentation roles, often through an agency, with a shorter interview and lower pay. Both are legitimate. Know which one you are in before you negotiate.

• Posting names Kotlin, Compose, coroutines, Hilt, Room: mainstream modern product app, standard preparation applies.
• Posting names Java, XML, Fragments, RxJava, Dagger 2, MVP: a long-lived codebase, usually enterprise or finance. Real jobs, far less competition, but say honestly whether you can work in it.
• Posting names AOSP, HAL, SEPolicy, device tree, board support package, Yocto: platform engineering, not app development. Different career.
• Posting names React Native, Flutter, or 'Mobile Engineer (iOS and Android)': cross-platform or dual-platform expectations. Ask in the screen how much native Android work actually remains.
• Posting names Gradle, CI, release automation, modularization, design system: mobile platform team. Interview weights build and tooling over UI.
• Posting names Media3 or ExoPlayer, CameraX, Bluetooth and BLE, NFC, or Health Connect: a hardware-adjacent specialism where domain depth beats generic Android breadth.

The 2026 stack: what is expected, and what is still Java and XML

Kotlin is the baseline, not a differentiator, and interviewers probe depth rather than syntax. The parts that come up repeatedly: coroutines and structured concurrency (scopes, cancellation, what happens to a child when a parent is cancelled, why launching in GlobalScope is a smell), Flow versus StateFlow versus SharedFlow and when each is right, cold versus hot streams, what buffer, conflate and collectLatest do to a slow collector, sealed interfaces and exhaustive when for modelling UI state, data classes and immutability, null handling at the boundary with Java and with JSON, and the inline and reified tricks libraries use. The K2 compiler is the normal front end now, so build speed and migration pain are reasonable things to have an opinion about.

Jetpack Compose is the default for new UI and the most common place candidates reveal shallow knowledge. Writing a composable is table stakes. What separates people: understanding that recomposition is driven by state reads rather than by function calls, state hoisting and where state should actually live, remember versus rememberSaveable and what survives process death, LaunchedEffect keys and what happens when one changes, DisposableEffect for cleanup, derivedStateOf for values that should not retrigger, snapshotFlow, Modifier order being significant, keys in LazyColumn, and measuring all of it with the Layout Inspector's recomposition counts and the Compose compiler's stability report rather than by guessing. One detail worth getting right because it dates candidates: strong skipping is on by default in current Compose compiler versions, so a composable with unstable parameters is still skippable using instance comparison, and lambdas are memoized automatically. The modern failure mode is not 'an unstable type broke skipping' but values recreated on every recomposition so instance comparison always fails. Material 3 and theming, adaptive layouts for tablets and foldables, and accessibility semantics belong in the same bucket.

Architecture questions assume Google's app architecture guidance as the shared vocabulary: a UI layer with unidirectional data flow, an optional domain layer, and a data layer with repositories as the single source of truth. ViewModel plus SavedStateHandle, UI state exposed as an immutable data class in a StateFlow, events flowing up, and the UI collecting with collectAsStateWithLifecycle or repeatOnLifecycle so collection stops when the screen is not visible. MVI shows up often enough that you should be able to say what you gain (one state object, replayable events, easier testing) and what it costs (ceremony, and a drift toward one giant state class). Dependency injection is usually Hilt, sometimes Koin at smaller companies, occasionally hand-rolled where a team decided build time matters more.

The data layer is where mobile system design conversations start. Retrofit with OkHttp remains the common HTTP stack, Ktor client in Multiplatform codebases, kotlinx.serialization having largely displaced Gson in new code. Room for local storage, DataStore in place of SharedPreferences, Paging 3 for lists backed by a network source, WorkManager for deferrable background work under Doze and app standby buckets. Know the constraints rather than the API surface: what you may and may not do from the background, which foreground service types must be declared and justified, why exact alarms are restricted, and why your sync works perfectly on a Pixel and dies silently on devices from manufacturers with aggressive battery management.

Build and release knowledge is undervalued by candidates and by nobody else. Gradle with the Kotlin DSL and version catalogs, KSP rather than kapt for annotation processing, build variants and flavours, R8 shrinking and the keep rules you inevitably need for reflection-based libraries, module boundaries and what they do to build times, and the Android Gradle Plugin upgrade treadmill. If you can describe a real build time reduction with a before and after number, that is a stronger senior signal than another screen in your portfolio.

Testing is the other undervalued area. Unit tests with JUnit, Turbine for asserting on Flows, MockK or fakes (and an opinion about preferring fakes), Robolectric where a JVM test needs an Android shim, Compose UI tests with semantics matchers, Espresso in older codebases, Maestro for end to end flows, screenshot testing with Paparazzi or Roborazzi to catch visual regressions, and a device matrix in Firebase Test Lab. Teams that care about quality ask what you test and what you deliberately do not, and the right answer involves a cost argument, not a coverage percentage.

The honest statement about legacy: most paid Android work touches code written before Compose existed. XML layouts, Fragments, RecyclerView with DiffUtil, LiveData, Dagger 2, RxJava, and Activities with a thousand lines in them are the daily reality in banking, insurance, retail, airlines and enterprise tooling. The valuable candidate can work in that and migrate it incrementally: ComposeView inside an existing Fragment, AndroidView inside Compose, strangling one module at a time with a measurable outcome. Candidates who present migration as a rewrite are rejected by every experienced hiring manager, because the rewrite is the thing their last team tried and abandoned.

• Junior: Kotlin fluency, Compose basics, one app shipped end to end, can follow an existing architecture, writes unit tests, understands the activity lifecycle and configuration changes.
• Mid: owns features end to end, handles process death and state restoration correctly, debugs with Layout Inspector, the Profiler and Crashlytics, writes tests that catch real regressions, reviews others' code, understands the data layer and caching.
• Senior: owns architecture decisions for an area, mobile system design, performance work with before and after measurements, release ownership including staged rollout and kill switches, mentoring, and the judgment to say what not to build.
• Staff and above: module and build architecture across teams, migration strategy that actually lands, cross-functional work with backend on API contracts designed for mobile, and setting the quality bar (vitals targets, release process, testing strategy).
• Cross-cutting at every level: the ability to explain a decision in terms of the constraint it respected, not the pattern it followed.

Shipping proof: getting something real on Google Play

The field has no licence, so distribution does the work a credential does elsewhere. A live Play listing proves things a repository cannot: that you finished, that you handled signing and versioning, that you wrote a privacy policy and a data safety declaration, that you passed policy review, and that you have read your own crash reports. Hiring managers open the link. Several will install it on their own phone before the call.

The administrative path is short but has a trap. You create a Google Play developer account and pay a one-off registration fee, long set at 25 USD. Personal accounts opened in recent years must then run a closed test with a minimum number of testers for 14 continuous days before they can apply for production access, and the count has been revised at least once, so read the current number in Play Console. Plan for it, because it adds weeks between 'my app works' and 'my app is public'. Finding real testers is the part nobody warns you about: opt-in testers must accept the invitation on a Google account and keep the build installed, so recruit from friends and colleagues first, then from the organised tester-exchange threads on r/androiddev and the Android developer Discords, and over-recruit, because some invitations are never accepted. For apps distributed outside Play, Google has announced developer verification requirements for installs on certified Android devices with a staged rollout; treat the timing as something to check in Google's own documentation rather than something to quote.

The publishing requirements are a short list you should be able to recite, because they come up as interview questions. Google Play takes Android App Bundles rather than APKs for new apps, and Play App Signing holds the signing key. Play enforces a target API level policy that moves every year, and apps that fall behind become invisible to new users on newer devices, so 'targets a recent API level' is a maintenance obligation rather than a one-time task. You must complete the data safety form honestly and keep it in sync with what the app actually collects. Sensitive permissions require declared justification, and foreground services require a declared type. Apps targeting recent platform versions must handle edge-to-edge display and the predictive back gesture properly. If your app ships native code, 16 KB memory page size support has become a Play requirement for apps targeting recent platform versions; the effective date has moved, so check it before you assume your NDK dependencies are fine.

What you build matters more than how much. A to-do list app proves nothing because it avoids every hard thing. Build something that forces you through at least five of the following: real third party data over a network, authentication with token refresh, offline reading with a local cache as the source of truth, writes that queue while offline and reconcile on reconnect, at least one runtime permission with a graceful denial path, background work scheduled under WorkManager, push notifications, a list large enough to need paging, media or camera, and a settings surface with DataStore. Then ship it, watch the vitals, fix a real crash, and release again. The second release is where the learning is.

Make the app reviewable. A README that states the architecture in five lines, a module diagram, the test strategy and one honest 'what I would do differently' paragraph is read far more often than the code. Include screenshots from a small phone, a tablet and dark mode. If the code is on GitHub, make sure CI runs the tests on every push and the badge is green, because a red badge is worse than no badge. Keep the Play listing current: a link to an app last updated two years ago reads as abandonment and costs you more than having no link at all.

Three alternatives count if Play is genuinely not available to you. Merged contributions to a well-known open source Android library are strong evidence and sometimes stronger than an app, because a maintainer reviewed your work. Internal or enterprise apps distributed through managed Play or an MDM count fully; describe scale, constraints and outcomes without breaching confidentiality, and bring a redacted architecture sketch. A detailed, reproducible bug report filed against a public app or library, with a minimal reproduction project, demonstrates exactly the diagnostic skill the deep dive round tests.

• Register the Play developer account early. The closed-testing period runs in calendar time and you cannot compress it when a deadline arrives.
• Over-recruit testers. Invitations that are never accepted do not count toward the requirement, and the clock restarts if you drop below the minimum.
• Set up Crashlytics or an equivalent before your first release, not after your first crash.
• Test on a genuinely low-end device, not only an emulator and a flagship. A cheap three or four year old handset will teach you more than another tutorial.
• Run the hostile checklist before you call it shipped: rotation, dark mode, system font scaled to maximum, TalkBack on, an RTL locale, airplane mode mid-request, backgrounded for an hour then resumed, and the developer option that kills activities when backgrounded.
• Record one real number you improved: cold start at the 90th percentile measured with Macrobenchmark, download size after R8 and resource shrinking, crash-free sessions rate, ANR rate, or build time.
• Write the privacy policy and the data safety declaration yourself. Interviewers in regulated sectors ask about them and most candidates have never read one.
• Use a staged rollout on your own app so you can say, truthfully, that you have halted a release.

How Android hiring actually works, stage by stage

Who screens you depends on employer size. At a company with a few dozen engineers, the Android lead reads your application directly and your Play link is the screen. At a mid-size product company, a recruiter filters on keywords first, which is why 'Kotlin', 'Jetpack Compose', 'coroutines' and 'Google Play' must appear as plain text on the resume rather than only inside a logo or a skills graphic. At large standardised employers, you are entering a general software engineering pipeline, and Android depth may be one round of five, with data structures and algorithms carrying most of the weight. At staffing agencies serving banks, automotive and retail, a non-technical recruiter screens on years, frameworks and rate, then a client-side technical call decides.

The modal process at a product company is five steps. Application, then a 20 to 30 minute recruiter call about scope, location, visa and compensation range, then a 45 to 60 minute technical screen, then a loop of three to five rounds, then an offer conversation. The technical screen is the fork in the road: some companies run a shared-editor coding problem, others run an Android fundamentals conversation, a few run a short pair programming exercise in a sample app. Ask which, in writing, in your reply to the scheduling email. A one-line question costs nothing and changes what you do for a week.

Take-homes are more common for Android than for backend, because a small app is a natural brief. The honest version is 4 to 8 hours: consume a public API, show a list, show a detail screen, cache for offline, handle errors and empty states, and write tests. The scoring is rarely about features. It is about whether the architecture is coherent, whether state survives rotation and process death, whether errors are modelled rather than swallowed, whether tests assert behaviour rather than implementation, and whether the README explains your trade-offs. Over-engineering a four screen app with six modules and a custom navigation framework is a failure mode interviewers see constantly. If the brief is open-ended, state your time budget in the README and what you consciously left out; that paragraph often scores higher than the code.

Some companies run a code review round, which is the most informative and the least prepared for. You are given a pull request or an existing file and asked to review it out loud. They are watching for whether you spot the leak (a listener registered without being unregistered, an Activity Context held in a ViewModel, a coroutine launched in the wrong scope), whether you distinguish a correctness bug from a style preference, and whether you can say that something is fine. Candidates who flag everything at equal severity score poorly, because that is what a bad reviewer does to a real team.

Timelines: 3 to 6 weeks end to end at product companies, 1 to 2 weeks for contract roles through agencies, and 6 to 10 weeks at large employers with hiring committees and team matching. Contract to hire is a genuine entry route in enterprise Android and worth taking seriously if you are switching into the field, because the interview tends to weight shipped experience over algorithms. Rates and conditions differ sharply from permanent employment, so price the lack of benefits and notice protection into the number.

One stage-specific warning. If a recruiter cannot tell you the level, the band, the loop format or who you would report to, slow down rather than speeding up. Android teams are small, often a handful of engineers, and the single biggest determinant of whether the job is good is whether mobile has release authority or has to beg for it. Ask directly: who decides when a release ships, and when was the last time a rollout was halted?

• Application: keyword screen at larger companies, direct read by the Android lead at smaller ones. Plain-text Kotlin, Compose and a Play link matter here.
• Recruiter screen (20 to 30 min): scope, location, visa, range, notice period. Ask the format of every subsequent round and get it in writing.
• Technical screen (45 to 60 min): either data structures in Kotlin or an Android fundamentals conversation. These need different preparation.
• Take-home (4 to 8 hours, common at mid-size companies): a small app against a public API, judged on architecture, state restoration, error modelling, tests and the README.
• Take-home review call: you defend decisions and extend the app live. Prepare to add a feature to your own code under observation.
• Coding round in the loop: at large employers, standard algorithms. At product companies, often an Android-flavoured problem such as implementing a cache or a debounce.
• Android deep dive: lifecycle, process death, Compose state and recomposition, coroutine scoping, memory leaks, the build. The round that most often decides the level.
• Mobile system design: design an offline-capable feed, a sync engine, an upload queue or a chat client. Marked on data flow, caching, failure handling and release safety.
• Code review round: you review a pull request aloud. Severity judgment is what is being graded.
• Behavioural and hiring manager: shipping stories, conflict with design or backend, a production incident you handled, and what you would do differently.
• Offer: level first, then cash. Level is nearly impossible to change later; cash sometimes is.

What Android interviews actually test, and how to answer

The deep dive round sets your level, and it concentrates on a short list of topics because those topics predict whether you will cause production incidents. Process death is the most common knockout. An interviewer asks what happens when the system reclaims your app's process while it is in the background and the user returns to it, and a surprising share of candidates with years of experience describe a configuration change instead. The right answer separates three things: configuration change (the Activity is recreated, the ViewModel survives), process death (the whole process is gone, the ViewModel does not survive, the system restores the back stack and whatever you saved), and a normal cold start. Then name the mechanisms: SavedStateHandle in the ViewModel, rememberSaveable in Compose, onSaveInstanceState underneath, and the developer option 'do not keep activities' to reproduce it on demand. If you can say you have actually tested with that toggle on, you have answered better than most senior candidates.

Compose questions follow the same pattern: they want the model, not the API. Why did this screen recompose when only one field changed? Usually because state is read too high in the tree, or because a value passed down is recreated on every pass so instance comparison fails. What survives process death, remember or rememberSaveable? What happens to the coroutine LaunchedEffect started when its key changes? Why is derivedStateOf the right tool for a boolean derived from scroll position? Why does Modifier order change the result? Why do keys matter in a LazyColumn? Name your measurement tools, because 'I would check recomposition counts in Layout Inspector and read the compiler's stability report' is the answer that reads as someone who has done it.

Mobile system design is the round that distinguishes Android engineers from people who write Android code, and it has a predictable marking scheme. Given a prompt such as 'design the feed for a social app' or 'design an offline-first notes app with sync', the interviewer wants: the data flow and where the single source of truth sits (almost always the local database, with the network as a writer into it), the caching and invalidation policy, pagination with a cursor rather than an offset, conflict resolution for offline writes, retry and backoff that does not hammer a struggling backend, image loading and memory pressure, what the user sees on a cold start with no network, how the feature is instrumented, and the release mechanics. That last one is where candidates lose the round. On mobile you cannot hot-fix a binary, so the answer must include a feature flag or remote config kill switch, a staged rollout, how you would detect a regression (crash rate, ANR rate, a business metric), and a forced-upgrade or minimum-version path for the case where the shipped client is genuinely broken.

Behavioural rounds for Android have their own recurring question, because the job has a recurring conflict: you depend on a backend you do not control and a design you did not draw. Expect 'tell me about a time the API did not fit the mobile use case', and have a real answer that shows you negotiated a contract change (chatty endpoints, missing pagination cursors, a payload that cannot be cached, a field nullable in practice but not in the schema) rather than one that shows you worked around it silently for a year. Expect 'tell me about a production incident' and answer with the timeline: how you learned about it, how you scoped it, what you shipped, and what changed in the process afterwards.

• Kotlin and concurrency: structured concurrency and cancellation; viewModelScope and what cancels it; why GlobalScope is a smell; dispatchers, withContext, and whose job main-safety is; suspend function design; cold Flow versus StateFlow versus SharedFlow; stateIn with a sharing strategy and why the five second stop timeout exists; buffer, conflate and collectLatest; flatMapLatest for search; Turbine for testing a Flow; why a try/catch around launch does not catch what people expect.
• Lifecycle and process: Activity and Fragment lifecycle in practice, not as a diagram; configuration change versus process death versus cold start; SavedStateHandle; rememberSaveable; why you must not hold an Activity Context in a ViewModel; lifecycle-aware collection with repeatOnLifecycle or collectAsStateWithLifecycle; task and back stack behaviour with launch modes and deep links.
• Compose: what triggers recomposition and what lets the compiler skip; strong skipping and lambda memoization in current compiler versions; state hoisting; remember versus rememberSaveable; LaunchedEffect, DisposableEffect, SideEffect and rememberCoroutineScope; derivedStateOf; snapshotFlow; Modifier ordering; LazyColumn keys and item reuse; interop with existing Views in both directions; accessibility semantics and the 48dp minimum touch target; adaptive layouts for tablets and foldables.
• Architecture: unidirectional data flow; modelling UI state as one immutable object versus several fields; one-off events versus state; repository as single source of truth; when a domain layer earns its keep; MVVM versus MVI trade-offs; Hilt scoping and the cost of a god module; modularization boundaries and what they buy.
• Data and offline: Room with Flow-returning queries; a read-through cache with the database as the source of truth; pagination with Paging 3 and a RemoteMediator; conflict resolution on offline writes; token refresh without a thundering herd; certificate pinning and when it hurts; serialization and schema evolution; DataStore migration from SharedPreferences.
• Background work: WorkManager constraints, chaining and uniqueness; Doze and app standby buckets; foreground services and declared types; why exact alarms are restricted; OEM battery management killing your process; push as a trigger rather than a payload.
• Performance: cold, warm and hot start; Baseline Profiles and what they actually improve; Macrobenchmark as the measurement tool; jank and frame timing; overdraw; memory leaks and LeakCanary; bitmap and image memory; R8 and resource shrinking; app size and the size cost of a dependency; ANR causes and how to find them in a trace.
• Build and release: Gradle Kotlin DSL and version catalogs; KSP; build variants; keep rules for reflection-based libraries; module graph effects on build time; App Bundle and dynamic delivery; Play App Signing; staged rollout and halting a release; remote config and kill switches; minimum supported version policy and what it costs.
• Testing: fakes versus mocks and why fakes usually win; what belongs in a JVM test versus an instrumented test; Robolectric's role; Compose UI testing with semantics; screenshot testing to catch visual regressions; Maestro or Espresso for critical flows; a device matrix and why the cheapest device matters most.
• System design prompts worth rehearsing out loud: an offline-first notes or messaging app with sync; an infinite feed with images and pagination; a background upload queue with retry and progress; a location-tracking feature that must survive the app being backgrounded; a payments flow with idempotency; migrating a large XML codebase to Compose without stopping feature work.
• Behavioural: a production incident you owned; an API contract you negotiated with backend; a disagreement with design about a platform convention; a migration you did incrementally; something you shipped that you later removed; how you decided not to build something.

The resume and the portfolio: what gets read, what gets ignored

Put the Play Store links in the top third, above the work history, each with one line of context: what the app is, roughly how large its user base is if you are allowed to say, what you specifically owned, and one outcome with a number you can defend. A bullet shaped like 'rebuilt the checkout flow in Compose, cut cold start at the 90th percentile by nearly half as measured with Macrobenchmark, and raised crash-free sessions' is read and remembered. 'Worked on various features using modern Android technologies' is skipped. If you cannot share your employer's numbers, say what you measured and what moved in relative terms, which is both truthful and sufficient.

Write the stack in plain text once, grouped, and then never again: Kotlin, Jetpack Compose, coroutines and Flow, Hilt, Room, Retrofit and OkHttp, WorkManager, Paging, Gradle, JUnit, Turbine, Espresso or Maestro, Firebase Crashlytics, Google Play Console. Recruiter and ATS keyword matching is real, and the cost of listing these honestly is one line. The failure mode is the opposite: a wall of thirty library names including every Jetpack component ever shipped, which signals nothing because it cannot distinguish you from anyone who read the documentation index.

Each bullet in your work history should answer three questions: what did you own, what constraint made it hard, and what changed because you did it. Android gives you unusually concrete constraints to name, so use them: a device floor, a size budget, a battery or thermal problem, a flaky network in a specific market, an API that could not be changed, a release train with a two week cadence, a regulated review gate. Hiring managers for mobile read for this, because the thing they cannot teach quickly is judgment about constraints.

What gets ignored, consistently: tutorial clones (another weather app, another to-do app, another movie list built against the same public API everyone uses), 'passionate about mobile technology', certificate badges from online course platforms, 'Android Studio' or 'Git' listed as skills, a GitHub profile full of forty abandoned repositories, and a skills section with proficiency bars. What actively hurts: a Play link to an app whose last update was years ago, a portfolio app that crashes on first launch on the reviewer's phone, an unexplained claim like 'improved performance by 40 percent' that falls apart when asked how it was measured, and claiming sole credit for a team app whose other contributors are visible on the listing.

One page under about ten years of experience, two at most beyond that. Single column, no text inside images or headers, standard section names, plain bullets. Many ATS parsers still mangle multi-column layouts, and the resume that cannot be parsed is not rejected, it is simply never read. Name the file with your name and the role.

Your Play listing is part of the portfolio and is judged as a product. Screenshots that show the app on a real screen rather than a marketing mock, a description written in sentences, a current last-updated date, a privacy policy link that resolves, and replies to a few user reviews all say that you understand shipping as a practice and not just as an action. If you have written publicly about a hard Android problem you actually solved, link that too: a specific post-mortem about a memory leak, an ANR hunt or a migration is worth more than a general tutorial, because it demonstrates the diagnostic process interviewers are trying to detect.

• Top third: name, title, location and work authorisation, one line of positioning, then Play links with one outcome each.
• Use numbers you can defend under questioning: startup time at a named percentile, crash-free sessions rate, ANR rate, download size in MB, build time, release cadence, test runtime.
• Say what you owned and what you did not. 'Owned the sync layer; the UI was built by two colleagues' reads as credible, not as weakness.
• Name the device floor and the markets you supported. Supporting a four year old mid-range device on a congested network is a harder engineering problem than supporting the latest flagship, and it is a differentiator.
• Mention migration work explicitly if you have it: Views to Compose, Java to Kotlin, RxJava to coroutines, Dagger to Hilt, single module to modular. Many employers are hiring for exactly this.
• Cut anything that does not survive the question 'how did you measure that'.
• Keep a one page addendum for the deep dive: a diagram of the architecture of the app you will be asked about, so you can share your screen and talk from it.

Where the Android jobs are, and how to reach a human

Demand sits in large, long-lived consumer and enterprise apps rather than in new app builds: banking and payments, retail and grocery, delivery and logistics, airlines and travel, telecom, media and streaming, healthcare and insurance, automotive (both in-car Android Automotive OS and companion apps), and the quiet, substantial world of apps for devices rather than phones (point of sale, warehouse scanners, medical devices, kiosks, in-flight entertainment). Agencies and consultancies also hire steadily for client Android work, with less interesting codebases and faster hiring.

Remote Android roles exist and are genuinely remote more often than in many fields, because mobile teams are small and often distributed. The cost is that remote postings attract global competition and their bands are increasingly location-adjusted. Hybrid and onsite roles in your own metro are a less crowded market, particularly in the regulated sectors above, which also tend to be the employers least represented on the job boards engineers actually read.

Reaching a human beats applying. The Android community is small, public and reachable in ways most fields are not. Kotlin's community Slack has active channels for Compose, coroutines and Android where library maintainers answer questions. droidcon events run in many cities and most publish their talks; attending one and following up with two specific questions to a speaker is a better use of an evening than fifty applications. Android Weekly, the Now in Android updates and the issue trackers for widely used libraries are where you see who is working on what. Local Google Developer Group chapters run meetups that hiring managers attend specifically because recruiting Android engineers is hard.

Three outreach approaches work better than a cover letter. First, use the product and write a short, precise message to the mobile lead about something concrete: a reproducible bug with the device, OS version and steps, or an observation about a slow screen with a trace attached. That is literally the job, performed unasked. Second, contribute to an open source library the company depends on and mention it. Third, give a short talk or write up a specific technical problem you solved, then send it to someone whose work it touches. Each of these converts better than volume applying, and each is also preparation.

Referrals carry more weight than any other channel at companies large enough to have a referral system, and the Android world is small enough that two or three conference and Slack relationships put you one hop from many teams. Ask for a referral only once you have something specific to refer: a Play link, a merged pull request, a write-up.

If you are switching into Android from another field, the realistic entry routes are, in rough order of likelihood: an internal move inside your current employer to a mobile team (by far the easiest, because they already trust you), a contract or contract to hire role through an agency serving enterprise clients, an agency or consultancy job, a smaller product company where your Play link is read by the person who would manage you, and last, a graduate or junior programme at a large employer, which is the most competitive of the five.

• Sectors hiring steadily: banking and payments, retail and grocery, delivery and logistics, travel, telecom, media and streaming, healthcare, insurance, automotive, and device-embedded Android (point of sale, scanners, kiosks, medical).
• Communities worth being present in: the Kotlin community Slack (Android and Compose channels), droidcon and local Google Developer Groups, r/androiddev, Android Weekly, and the issue trackers of libraries you actually use.
• Cold outreach that works: a reproducible bug report with a minimal project, a performance trace, or a merged pull request on a library the company depends on.
• Watch for 'Mobile Engineer', 'Kotlin Engineer', 'Software Engineer (Mobile)' and 'Client Engineer' as well as 'Android Developer'. Title-only searches miss a large share of the market.
• Contract and contract to hire through staffing agencies is a legitimate entry path into enterprise Android, with a shorter interview that weights shipped work over algorithms.
• If you are a strong backend or web engineer, an internal transfer to the mobile team at your current employer is the single highest-probability route into the field.

Pay, levelling, and what to actually say

Do not trust a salary band quoted in an article, this one included. Use three sources instead. US Bureau of Labor Statistics Occupational Employment and Wage Statistics series 15-1252, Software Developers, is the authoritative national and metropolitan reference; BLS does not break out Android separately, so read it for the shape of the occupation and the regional differences rather than as a mobile-specific number. For named employers and ladder levels, levels.fyi has the best public data on large technology companies. For live, employer-stated numbers, read current postings in pay-transparency jurisdictions: Colorado, California, Washington, New York, Illinois, Minnesota, Hawaii, Maryland, Vermont, New Jersey and Massachusetts among others, and the list has kept growing, so check whether your own state now requires it. Searching the same company's postings in a transparency state gives you their real band for your level, which is more useful than any aggregate.

Levelling matters more than negotiation. At companies with a unified software engineering ladder, Android engineers are paid at the same level as backend engineers doing comparable scope, and the lever is which level you are slotted into, not how hard you push on the number afterwards. At companies with a separate mobile job family, ask explicitly whether the mobile ladder tops out lower and where it maps against the software ladder. This is a fair question and the answer tells you a great deal about how the company regards mobile work.

Three structural facts about Android pay. Senior Android engineers at companies with large apps are not cheap, because the supply of people who can own a long-lived mobile codebase, its build and its release is genuinely small. Junior Android roles are scarcer and more competitive than junior backend or web roles, because small teams cannot absorb a trainee easily. Contract rates in enterprise Android often look attractive on the headline number and look very different once benefits, bench time and notice protection are priced in, so compare total compensation rather than day rate against salary.

What to say when asked for your expectations: ask for their band and the level first. 'What is the range for this level, and which level is this requisition?' is a normal question, and in many US jurisdictions the employer must give you the range in the posting or on request. If pressed for a number before you have theirs, give a range anchored on the research above, name your source, then move the conversation back to level and scope. When an offer arrives, negotiate on level if the scope they described exceeds the level they offered, because a level change is worth more over two years than any signing bonus.

Two questions worth asking that are about the job rather than the money, and which experienced interviewers respect. Who decides when a release ships, and when was the last rollout halted? And: what is your current crash-free rate and ANR rate, and what device floor do you support? The answers tell you whether you are joining a team with authority over its own quality or one that will be blamed for a binary it does not control.

• Authoritative pay reference: BLS OES 15-1252, Software Developers. Covers Android developers inside a broader occupation; use it for regional shape, not for a mobile-specific band.
• Employer and level data: levels.fyi for large technology companies.
• Live employer-stated numbers: postings from the same company in pay-transparency jurisdictions, matched to your level.
• Ask for the band and the level before giving a number. In many US jurisdictions the employer must provide the range in the posting or on request.
• Negotiate level before cash when the described scope exceeds the offered level. Level compounds; a signing bonus does not.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Android Developer
• Android Engineer
• Senior Android Engineer
• Mobile Engineer
• Mobile Developer
• Kotlin
• Kotlin Coroutines
• Kotlin Flow
• StateFlow
• SharedFlow
• Structured concurrency
• Java
• Jetpack Compose
• Compose Multiplatform
• Material 3
• XML layouts
• Android Views
• Fragments
• RecyclerView
• DiffUtil
• ViewBinding
• Android Jetpack
• ViewModel
• SavedStateHandle
• LiveData
• Lifecycle-aware components
• Navigation Component
• Navigation Compose
• Room
• DataStore
• SharedPreferences migration
• WorkManager
• Paging 3
• CameraX
• Media3
• ExoPlayer
• Health Connect
• Hilt
• Dagger 2
• Koin
• Dependency injection
• Retrofit
• OkHttp
• Ktor client
• kotlinx.serialization
• Moshi
• Gson
• REST API integration
• GraphQL
• Offline-first architecture
• Caching strategy
• Single source of truth
• MVVM
• MVI
• Clean Architecture
• Unidirectional data flow
• Repository pattern
• Modularization
• Multi-module Gradle
• Gradle Kotlin DSL
• Version catalogs
• KSP
• Android Gradle Plugin
• K2 compiler
• R8
• ProGuard
• Android App Bundle
• Play App Signing
• Google Play Console
• Target API level
• Staged rollout
• Remote config
• Feature flags
• Firebase
• Firebase Crashlytics
• Firebase Remote Config
• Firebase Cloud Messaging
• Firebase AI Logic
• Android Vitals
• ANR
• Crash-free sessions
• Baseline Profiles
• Macrobenchmark
• Android Profiler
• Layout Inspector
• App Quality Insights
• LeakCanary
• App startup optimization
• App size reduction
• JUnit
• MockK
• Turbine
• Robolectric
• Espresso
• Compose UI testing
• Maestro
• Paparazzi
• Roborazzi
• Firebase Test Lab
• Unit testing
• Instrumentation testing
• Screenshot testing
• CI/CD
• GitHub Actions
• Bitrise
• Fastlane
• Accessibility
• TalkBack
• WCAG
• RTL support
• Foldables
• Large screen support
• Wear OS
• Android TV
• Android Auto
• Android Automotive OS
• AOSP
• NDK
• Kotlin Multiplatform
• KMP
• ML Kit
• Gemini Nano
• AICore
• LiteRT
• MediaPipe
• On-device ML
• Gemini in Android Studio
• Play data safety
• Runtime permissions
• Scoped storage
• Doze mode
• Foreground services
• Push notifications
• Deep links
• Certificate pinning
• Play Integrity API
• Code review
• Agile
• Scrum

Mistakes that cost people this job

Questions people ask