A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Android's defining problem is that "Android" is not one platform. It is a specification that several hundred manufacturers implement with their own opinions layered on top.
The differences that hurt are not screen sizes. They are behavioural. Manufacturer battery management on a number of popular handsets will kill background work that the platform documentation says should survive. A scheduled sync that runs reliably on a Pixel silently stops on a device where the OEM has decided your app is not worth waking. Nothing crashes. The user simply reports that notifications arrive late, or not at all, and your logs show nothing because the process was never running.
A developer who has only tested on a Pixel and an emulator has not met this class of bug. It does not appear in the documentation, it cannot be reproduced without the hardware, and the fix is usually a design change rather than a code change.
On top of that sits the Java-to-Kotlin divide, which cuts through the candidate pool the same way version splits do elsewhere.
Android screening is about the gap between the emulator and the field.
Which they have shipped, and whether they can work across the interop boundary in a mixed codebase. Not one skill, and we do not treat it as one.
Coroutines, Flow, structured concurrency and nullability used deliberately rather than Java habits written in Kotlin syntax.
Whether they have debugged an OEM-specific failure. The answer separates people who have shipped widely from people who have shipped to a Pixel.
WorkManager, foreground service types, and designing for the case where the system never wakes you when you expected.
Target API compliance, staged rollout, and reading Vitals to find what is failing rather than waiting for reviews to say so.
A live conversation in English, every time. Device-specific problems are hard to reproduce, so precise description saves days.
The Android failure that costs most is a shipped app that stops working because a policy changed, not because the code broke.
Google Play enforces a minimum target API level, raised annually. Miss it and your app stops being updatable and eventually stops being discoverable to new users. The work to comply is rarely trivial, because each API level bump brings behavioural restrictions with it. Background execution limits, scoped storage, runtime notification permission, and typed foreground services have each broken working apps that did nothing wrong except stay still.
These land on a deadline you do not set. A team without an Android owner discovers the requirement weeks before the cutoff, and now the storage rewrite that should have been planned across a quarter is an emergency.
Fragmentation costs compound quietly alongside that. An app tested only on flagship hardware will feel fine in the office and janky on the mid-range devices most users have. ANRs cluster on slower storage and less memory. R8 in a release build strips or renames what it believes is unused, and a reflection-based serialiser that worked all through development throws on the first production install — a failure that appears exclusively in release builds, which is why it reaches users.
Mid-level (3–5 years). Builds screens and features against an existing architecture. Comfortable with Kotlin, coroutines, and either Compose or the View system. Uses Jetpack libraries as configured rather than choosing them.
Senior (5–8 years). Owns architecture and the Compose adoption path. Handles Play Console, staged rollout and target API compliance. Knows where OEM behaviour diverges and designs around it rather than being surprised by it.
Lead (8+ years). Owns the Android platform, plans the annual policy cycle deliberately, sets the device matrix that counts as acceptance, and makes modularisation and build-time decisions for a growing team.
Feature work on an existing app. The largest category. State whether it is Compose, XML views, or both.
Jetpack Compose migration. Screen-by-screen replacement of the View system. Needs someone fluent in both, since the interop layer is where the work actually is.
Java to Kotlin. Usually incremental and usually bundled with other work. Straightforward per file, and a good opportunity to fix nullability properly rather than mechanically.
Target API compliance. Driven by a Play deadline. Bounded work, and best started before it is urgent.
Android alongside iOS or cross-platform. See iOS, Flutter and React Native developers.
Week one. They ask what your device matrix is, and if the answer is "a Pixel and the emulator" they tell you that is a problem. Expect questions about the current target API level, what the Play Console is reporting for ANRs and crashes by device, and whether background work is scheduled through WorkManager or something more optimistic.
Weeks two to four. A shipped feature, tested on a real mid-range device, plus one thing they have fixed that was only visible off the happy path — an ANR clustered on a particular manufacturer, a background job that never fires on a specific OEM, a release-build failure that debug builds never showed.
The warning sign is a developer who dismisses the Play Console. Vitals data tells you which devices are failing and how often, and it is the only view you have of the hardware you cannot buy. Somebody who has not opened it by week two is working from assumptions.
Testing only on flagship hardware. The single most common mistake, and the cheapest to fix. Buy two mid-range handsets from the manufacturers your analytics actually show, and make one of them the device a feature has to work on before it ships.
Trusting the documentation on background work. The platform documents what should happen. Several popular manufacturers implement something more aggressive, and your scheduled work does not run. Design so that late execution degrades gracefully rather than assuming it will happen on time, and test it on the hardware rather than in the emulator.
Treating target API bumps as a formality. They arrive annually with behavioural changes attached, and they are non-negotiable if you want to keep shipping updates. Put the deadline in the roadmap the moment it is announced, because the storage and permission changes in particular are not a one-sprint job.
Assuming Kotlin experience means Compose experience. Compose is a declarative model with its own rules about state, recomposition and side effects. A strong Kotlin developer from the View system writes Compose that recomposes far more than it should and cannot say why. Screen for it separately, exactly as you would for SwiftUI on the other platform.
Rates depend on seniority, platform depth, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.