Hire Android and Kotlin developers

Android development is Kotlin across an enormous range of devices, and hiring for it means finding someone who designs for fragmentation rather than for their own handset.

What Android and Kotlin actually is

Android development means building applications for Google's mobile platform, now overwhelmingly in Kotlin rather than Java. Kotlin is a modern typed language with null safety in the type system, full interoperability with Java, and first-class support from Google as the preferred language for the platform.

The defining characteristic of Android is variety. Applications run on an enormous range of devices with different screen sizes, processors, memory, manufacturer modifications and operating system versions, many of them years old. An application that performs well on a current flagship can be unusable on the hardware a large part of the actual user base owns, and that gap is invisible to a developer testing only on their own phone.

As with iOS, the platform is midway through an interface transition. The older approach declares layouts in XML and manipulates them imperatively; the newer one is a declarative toolkit written in Kotlin. New work generally starts in the declarative toolkit, a great deal of existing code is in the older style, and most substantial applications contain both.

The part that separates seniors from mid-levels

Lifecycle is the concept that defines Android development. The system can destroy and recreate parts of your application at any time, for reasons including rotation, memory pressure, configuration changes and the user switching away. State that is not deliberately saved is gone. A very large share of Android bugs are lifecycle bugs: work that continues after its screen is destroyed, state lost on rotation, or callbacks firing into objects that no longer exist. Developers who understand the architecture components and where state should live write substantially more robust applications.

Coroutines are the second area, and they are how asynchronous work is done on modern Android. What matters is scope: work launched in the right scope is cancelled automatically when its screen goes away, and work launched carelessly outlives it and leaks or crashes. Candidates who talk about structured concurrency and lifecycle-aware scopes are describing the correct model. Those who launch coroutines globally are describing a class of production bug.

The third is the declarative toolkit's recomposition model. Composable functions re-run when the state they read changes, and the framework decides how much to re-run. Understanding state hoisting, stability and what causes unnecessary recomposition is the practical performance skill, and it is where interface jank originates on exactly the low-end devices that are hardest to test on.

Where Android and Kotlin is used

The label “Android and Kotlin developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Consumer applications

Products where Android reach matters, which in most of the world means the majority of the addressable market.

Emerging market products

Applications where low-end devices, limited storage and expensive data are design constraints rather than edge cases.

Field and logistics applications

Workforce tools on rugged or managed devices, often with offline operation as a core requirement.

Retail and point of sale

Applications on dedicated hardware, including payment terminals and kiosks.

Media and communications

Streaming, messaging and social applications where background behaviour and notifications are central.

Automotive and wearables

Adjacent Android surfaces with their own constraints and their own smaller talent pools.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Android and Kotlin versions are still supported

Google requires applications to target a recent platform version to remain updatable on the Play Store, so the target version is a compliance deadline rather than a preference.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 4 are still maintained and 4 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Android and Kotlin alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Kotlin

The language. Java knowledge remains useful for older codebases and is no longer the default.

Jetpack Compose

The declarative interface toolkit, where new Android interface work is written.

Coroutines and Flow

Asynchronous work and reactive streams, tied to lifecycle scopes.

Hilt

Dependency injection, the standard approach on modern Android.

Room

Local persistence over SQLite, which matters because offline capability is often required.

Retrofit with OkHttp

Network access, with interceptors for authentication and retry.

WorkManager

Deferred and guaranteed background work under the platform's increasingly strict execution limits.

Android Studio profilers

Memory, CPU and recomposition profiling, ideally on real low-end hardware.

Related skills that frequently appear on the same specification: Java, React Native, Flutter, iOS and Swift, AWS.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Lifecycle and state preservation

The foundation of Android, and the source of most defects.

• Strong answer: Explains what survives rotation and process death, uses the right state holder, and has debugged a state-loss bug.
• Warning sign: Has disabled rotation to avoid the problem, or does not distinguish configuration change from process death.

Coroutine scope

Determines whether background work is cancelled correctly or leaks.

• Strong answer: Uses lifecycle-aware scopes, understands structured concurrency, and avoids launching globally.
• Warning sign: Launches work in a global scope as a default.

Compose recomposition

Where declarative interface performance problems live.

• Strong answer: Hoists state correctly, understands stability, and has used the profiler to find excess recomposition.
• Warning sign: Has used Compose without considering what triggers recomposition.

Device fragmentation

The characteristic Android challenge and the most commonly neglected one.

• Strong answer: Tests on low-end hardware and older OS versions, and can describe a bug specific to a manufacturer or version.
• Warning sign: Tests on a current flagship and an emulator only.

Background execution limits

The platform has tightened these repeatedly and applications break when it does.

• Strong answer: Uses WorkManager appropriately, understands doze and battery restrictions, and knows manufacturer behaviour varies.
• Warning sign: Assumes background services run whenever scheduled.

Permissions and privacy

Requirements have tightened substantially and are enforced at the store.

• Strong answer: Requests at point of use, handles denial gracefully, and knows the current storage and location rules.
• Warning sign: Requests everything at launch, which is both a user problem and a store problem.

Play Store release management

Staged rollouts and pre-launch reports are real advantages if used.

• Strong answer: Uses staged rollout, watches crash rates, and has halted a rollout.
• Warning sign: Has never managed a release, or ships to all users at once.

Warning signs in a Android and Kotlin codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Work launched outside a lifecycle scope

• What you see: Coroutines started in a global scope from a screen.
• What it costs: Work continues after the screen is gone, leaking memory and crashing when it tries to update a destroyed view.
• The fix: Use lifecycle-aware scopes so cancellation is automatic and structural rather than remembered.

State held in the wrong place

• What you see: Screen state stored in an activity or fragment rather than a state holder that survives configuration change.
• What it costs: Users lose their work on rotation or when the process is reclaimed in the background.
• The fix: Use the architecture components designed for this, and test by rotating and by forcing process death.

Testing only on flagship hardware

• What you see: Development and validation on a current high-end device.
• What it costs: The application is slow or unusable on the hardware a large share of real users have.
• The fix: Keep low-end physical devices in the loop and treat their performance as the target rather than the exception.

Requesting all permissions at launch

• What you see: A wall of permission dialogs on first open.
• What it costs: Users deny them, the application breaks, and store review may reject the justification.
• The fix: Request at the point of use with context, and handle denial as a normal path rather than an error.

Blocking the main thread

• What you see: Database or network access performed on the main thread.
• What it costs: Frozen interface and the system's not-responding dialog, which users treat as a crash.
• The fix: Move work to an appropriate dispatcher. Enable strict mode in development so violations are loud.

Ignoring target version requirements

• What you see: An application on an old target version because raising it required work.
• What it costs: The Play Store eventually refuses updates, and raising it later means addressing several years of behaviour changes at once.
• The fix: Raise the target version each cycle and deal with the behaviour changes as they arrive.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Android developer.

Junior

Builds screens in an existing application. Needs review on lifecycle, coroutine scope and state preservation.

Mid-level

Owns a feature including persistence, background work and tests. Can profile and fix jank.

Senior

Owns application architecture, the state and concurrency model, the offline strategy, and the release process including staged rollout.

Staff

Owns the platform upgrade path, the device support matrix, the modularisation strategy, and the response to each year's behaviour changes.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New Android application

• Usual team: One to two developers plus a designer.
• What governs it: Device testing, permissions and background behaviour take longer than the feature work suggests.

Views to Compose migration

• Usual team: One senior developer.
• What governs it: Interoperable, so screen by screen. Navigation and shared components are the awkward boundary.

Target version uplift

• Usual team: One developer.
• What governs it: Recurring and not optional. Scoped by how many years of behaviour changes must be absorbed at once.

Performance remediation for low-end devices

• Usual team: One senior developer with real hardware.
• What governs it: Must be measured on the devices in question. Emulator results are close to meaningless here.

Offline capability

• Usual team: One to two developers.
• What governs it: Synchronisation and conflict resolution are the project. The local database is the easy part.

Migration work you may actually be hiring for

A large share of Android and Kotlin work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

Java to Kotlin

• Why teams do it: Null safety, coroutines, and alignment with where Google's documentation and libraries are aimed.
• What to watch: Full interoperability means this is incremental by nature. Convert files as you touch them; there is rarely a case for converting working Java that nobody is changing.

XML views to Jetpack Compose

• Why teams do it: Less code per screen, a faster development loop, and the direction of the platform.
• What to watch: They interoperate, so migrate screen by screen. Navigation and any shared custom components are the boundary that needs designing rather than improvising.

An old target SDK version to a current one

• Why teams do it: Play Store requirements, and avoiding a larger jump later.
• What to watch: Each version brings behaviour changes to permissions, storage and background execution. Raise one version at a time and test on real devices, because manufacturer variation shows up here more than anywhere else.

RxJava to Coroutines and Flow

• Why teams do it: First-class language support, lifecycle-aware cancellation, and a simpler model for most cases.
• What to watch: Both can coexist through interoperability adapters. Migrate feature by feature rather than attempting a single conversion across the codebase.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Android developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Whether the application uses XML views, Compose, or both, and roughly in what proportion.
• What the minimum supported Android version and device profile are, since this shapes everything.
• Whether background work or offline operation is required, because both are genuinely hard on Android.
• Whether the codebase is Kotlin, Java, or mixed.
• Who controls the Play Console and signing keys.
• Which physical test devices exist, particularly at the low end, since this is routinely unaddressed.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Android and Kotlin work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Android developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Android developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Flagship-only testing. Ask which low-end device they test on. This single question predicts a great deal about the application they will produce.

Java-era Android habits. Ask about coroutine scopes and Compose. The platform has moved considerably in a few years.

No release management experience. Staged rollouts and crash monitoring are genuine advantages on Android and are frequently unused.

Underestimating background restrictions. Ask what happens to their scheduled work when the device is idle, and whether manufacturer behaviour differs.

Hiring Android and Kotlin developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Android developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Should we build native Android or use a cross-platform framework?

Native when Android is your main market, when the application depends on background work, hardware or deep platform integration, or when performance on low-end devices is commercially important. Cross-platform when you need both platforms from a small team and the interface is largely standard. In much of the world Android is the majority of the addressable market, which often settles it.

Kotlin or Java for Android?

Kotlin. It is Google's preferred language, where the documentation and libraries are aimed, and where the ecosystem is going. Java remains in large existing codebases and interoperates fully, so a mixed codebase is common and fine. New Android work in Java is now the unusual case and narrows your hiring pool rather than widening it.

Views or Jetpack Compose?

New work generally starts in Compose, and most substantial applications contain both because they interoperate and nobody rewrites working screens for their own sake. A candidate with only view-based experience will need ramp time on Compose, and one with only Compose experience will struggle in the older parts of most real codebases.

Why is our application slow for some users but not for us?

Almost certainly device fragmentation. A large part of the Android user base runs hardware several generations behind a developer's phone, with less memory and slower storage. Performance problems that are imperceptible on a flagship are severe there. The fix is to keep low-end physical devices in the development loop rather than checking on them before release.

Why does our background work stop running?

The platform has tightened background execution repeatedly to protect battery, and several manufacturers apply additional restrictions beyond the standard ones. Work scheduled the old way simply does not run on some devices. WorkManager is the supported mechanism, and even then guaranteed timing is not something Android offers.

How often do we need to update for the platform?

At least annually. Google requires applications to target a recent platform version to remain updatable on the Play Store, and each version brings behaviour changes around permissions, storage and background execution. Deferring means absorbing several years of changes at once under deadline pressure.

What does an Android developer need from us on day one?

Access to the Play Console or a clear path to it, signing keys, and at least one low-end physical test device. The last one is routinely forgotten and is the difference between an application that works for your users and one that works for your developers.

Can one developer maintain both Android and iOS natively?

For a small application, sometimes, and it is usually a false economy. Both platforms release annually, both have their own store requirements, and the context switching is real. If budget forces one person across both, a cross-platform framework is usually the more honest answer than expecting native depth in two ecosystems.