An Android developer job description should specify the UI toolkit in use (Jetpack Compose, the legacy XML View system, or a mix of both), the minimum and target SDK versions your app supports, and whether the role owns Play Console submissions and release management. It should also name the architecture pattern, dependency injection framework, and local persistence layer, since “Kotlin developer” alone tells you almost nothing about whether a candidate can work inside your existing codebase. The strongest JDs describe the app’s module structure and release cadence honestly, so candidates can judge fit before the first screen.
Why “Kotlin Developer Wanted” Postings Underperform
A job description that lists “Kotlin, Android Studio, Android SDK, Play Store, Java a plus” pulls in a flood of applicants and almost none of them fit. Kotlin is a language, not a skill set, and the gap between an engineer who has patched a single-activity app once a quarter and one who owns a weekly release train across a dozen Gradle modules is enormous. Neither is wrong for every role, but a JD that does not say which one you need wastes both sides’ time.
This template fixes that by forcing three decisions before you write a single requirement:
- Whether your app is built primarily in Jetpack Compose, the XML View system, or a hybrid of both
- What the developer will own end to end versus hand off to a lead or a release manager
- How your app handles state, persistence, and networking today, not how it will look after a rewrite
Use the full template as-is, or adapt each section to match your codebase. If you are starting from scratch, our guide on how to hire nearshore Android developers covers the full process, from sourcing through onboarding.
What Android Developers Actually Own
Before drafting requirements, decide what your Android developer will actually be responsible for. On a two-person mobile team, that scope is nearly everything from the first commit to the Play Console listing screenshots. On a larger team with a dedicated release manager and a QA function, it narrows considerably, and the JD should reflect that difference honestly.
Depending on team size and maturity, an Android developer commonly owns some combination of the following:
- Building and maintaining screens in Jetpack Compose, XML layouts, or both
- Integrating REST or GraphQL APIs with Retrofit or Ktor and handling offline state
- Managing local persistence with Room, DataStore, or occasionally Realm
- Writing unit and instrumentation tests with JUnit and Espresso and maintaining CI pipelines
- Preparing builds and metadata for Play Console submission and staged rollouts
- Triaging crash reports from Firebase Crashlytics or Play Vitals and shipping fixes
Some teams also expect the Android developer to own push notification setup via Firebase Cloud Messaging, deep linking, background work with WorkManager, and Play Console configuration, including app signing keys.
At companies with a platform or release engineering function, the Android developer’s scope narrows to feature work, and a separate team owns CI/CD, code signing, and store submissions. At smaller companies, one developer frequently owns the entire pipeline, from a Compose screen to the version bump in Play Console. State which model applies, because a candidate who has only ever built features inside someone else’s release process will evaluate your JD very differently than one who has run a submission end to end.
Core Technical Requirements
Requirements should describe what a developer needs to be productive by day 60 in your actual codebase, not a wish list stitched together from three competitor postings. Keep hard requirements to six or eight items, separate them clearly from preferences, and describe the depth you need instead of just naming a toolkit.
UI Toolkit and Minimum SDK Support
Name the toolkit your codebase actually uses and how much of it is legacy. “3+ years building production Jetpack Compose apps, including custom layouts and state hoisting” describes a real requirement. “Experience with Android development” describes nothing. If your app is an XML-based View system migrating incrementally to Compose, say so, and state roughly what percentage of screens are on each toolkit. State your minimum and target SDK versions too, since a developer used to targeting only the latest API level will need to unlearn habits if your app still supports two or three versions back.
Architecture and State Management
Android architecture varies as much as backend architecture does. Distinguish between a developer who has used MVVM loosely and one who has maintained a codebase with a formal Kotlin Coroutines and Flow-based data pipeline across dozens of screens. If your app uses MVI, a multi-module Clean Architecture setup, or a custom unidirectional data flow pattern, name it explicitly, because ramp time on an unfamiliar architecture is one of the largest hidden costs in an Android hire. Also state your dependency injection framework, since Hilt, Dagger, and Koin each carry a different learning curve.
Persistence and Networking Depth
Room experience is not uniform. A developer who has added a Room entity to a small app is different from one who has managed schema migrations across a database with dozens of entities and resolved conflicts in a multi-module setup. Describe the complexity you actually have, and state whether the developer will inherit the existing data layer or help build out a new one with DataStore for preferences. On the networking side, specify whether your app uses Retrofit, Ktor, or a code-generated client from an OpenAPI spec, and whether offline caching or sync is a requirement.
CI/CD and Release Ownership
Specify your build and release toolchain. If you run Gradle with GitHub Actions or Bitrise for automated internal-testing track builds, say so and state whether the developer will maintain the Gradle build scripts and module graph itself. If app signing is manual today versus handled through Play App Signing, note that honestly. Teams that expect a developer to also own Play Console metadata, screenshots, and staged rollout percentages should list that as a real requirement rather than an assumption.
Nice-to-Have Skills
Limit preferences to three or five items and keep them clearly separate from requirements. A preference list longer than that reads as a second requirements list and filters out strong candidates who do not check every box.
Genuine preferences for most Android roles include:
- Java reading fluency for teams with legacy code still in production
- Experience with Jetpack libraries such as Paging 3, WorkManager, or Navigation Compose
- Accessibility work with TalkBack and content descriptions
- Prior Play Store policy rejection troubleshooting and Google Play Console familiarity
- A relevant certification or coursework, such as the Associate Android Developer track or a completed Android Basics with Compose curriculum
Google’s Associate Android Developer certification was retired, so treat certifications as a soft signal, not a filter. A developer who has shipped three apps to the Play Store and handled two policy rejections is a stronger signal of readiness than any course completion certificate.
Skip the JD Process Entirely
Tell us your UI toolkit, architecture, and release process. We surface pre-vetted nearshore Android developers from Costa Rica within 72 hours.
The Full JD Template
The template below targets a mid-to-senior Android developer role for a nearshore or remote hire. Customize the bracketed fields for your app and remove sections that do not apply rather than leaving generic placeholders in a live posting.
About the Role
We are hiring an Android Developer to build and maintain our [Jetpack Compose / XML View / hybrid] app, supporting Android API level [minSdk] and above, targeting [targetSdk]. You will own features from design handoff through Play Console release, working inside a codebase built on [MVVM / MVI / Clean Architecture] with [Room / DataStore] for local persistence and [Hilt / Dagger / Koin] for dependency injection. You will work directly with our product and backend teams in real-time US hours and join sprint ceremonies from day one.
What You Will Own
- Build and maintain screens and components in [Jetpack Compose / XML layouts], following our [MVVM / MVI / Clean Architecture] pattern
- Integrate and consume our [REST / GraphQL] API with [Retrofit / Ktor], including offline caching and error handling
- Maintain the [Room / DataStore] persistence layer, including schema migrations
- Write unit tests with JUnit and instrumentation tests with Espresso, maintaining coverage on new features
- Maintain our [Gradle-based / Bitrise / GitHub Actions] CI/CD pipeline for internal-testing and production track builds
- Prepare Play Console submissions, including metadata, screenshots, and staged rollout percentages
- Triage crash reports and ANRs from [Firebase Crashlytics / Play Vitals] and ship fixes
- [If applicable] Support accessibility requirements including TalkBack and content descriptions
Required Qualifications
- 3+ years of production Android development experience with Kotlin
- Deep hands-on experience with [Jetpack Compose / XML View system] in a shipped, Play Store-live application
- Experience with [MVVM / MVI / Clean Architecture] or a comparable structured pattern at scale
- Working knowledge of [Room / DataStore] including schema migrations
- Experience integrating REST or GraphQL APIs, including authentication and offline handling
- Experience with Play Console submission, staged rollouts, and Google Play policy requirements
- Strong written and spoken English; comfortable in US-timezone standups and sprint planning
Preferred Qualifications
- Java reading fluency for legacy code maintenance
- Experience with Paging 3, WorkManager, or Navigation Compose
- Gradle build script and multi-module configuration experience
- Accessibility implementation experience (TalkBack, content descriptions)
- Prior experience resolving Play Store policy rejections directly with Google
- Experience migrating an XML View codebase to Jetpack Compose
What We Offer
- Fully remote role with real-time collaboration in US business hours
- Competitive compensation: [$42,000 to $66,000 USD annually based on experience]
- Full benefits package including health, dental, and vision coverage
- Paid time for conference talks, Android developer community involvement, and skills training
- 90-day structured onboarding with a dedicated engineering mentor
- Paid time for Play Store policy triage and release-week coverage
Once the JD is live and applications start coming in, pair it with our Android developer interview questions guide so the screening bar matches what you just published.
Compensation Ranges
Publishing a salary range in your Android developer JD raises qualified application volume because it filters out mismatched expectations before the first call. For nearshore Android developers hired through a staffing partner in Costa Rica, the ranges below reflect 2026 all-in placement costs through Kore BPO. For a full breakdown of rates by experience level and specialization, see our nearshore Android developers salary guide.
| Experience Level | Years of Experience | Annual Range (USD) | Notes |
|---|---|---|---|
| Mid-Level | 2-4 years | $30,000 – $44,000 | One UI toolkit, limited release ownership |
| Senior | 4-7 years | $45,000 – $68,000 | Full feature and release ownership, architecture depth |
| Lead / Staff | 7+ years | $70,000 – $85,000 | Multi-app portfolios, mentoring, Play Store strategy |
These ranges cover salary, benefits administration, and account management support, with no upfront search fees. All-in costs remain 40 to 60% below the equivalent US-based senior Android developer role, where total compensation for the same experience level typically runs $115,000 to $155,000 annually.
Remote-Ready JD Considerations
A JD written for a nearshore or remote Android developer needs a few additions that domestic postings often skip. These signal that your team has hired distributed mobile engineers before and that the role is genuinely remote-first rather than a hybrid seat with an optional work-from-home day.
State the Timezone Requirement Precisely
“Full availability during US Central hours (9 am to 5 pm CT, UTC-6)” leaves no room for interpretation. “US timezone overlap” does. Costa Rica runs UTC-6 year-round with no daylight saving time, so there is no seasonal shift and no ambiguity about whether Central Time is five or six hours behind depending on the month. Engineers hired through Kore BPO in Costa Rica have full overlap with US Central and near-full overlap with US Eastern.
Clarify Release-Week and On-Call Expectations
Mobile releases behave differently than backend deploys. A rejected Play Store submission or a post-release crash spike surfaced through Play Vitals can require fast turnaround outside standard hours. State whether the Android developer is expected to monitor crash dashboards during the 48 hours after a staged rollout and how that time is compensated. If release-week coverage rotates among team members, say so; if it always falls on one person, say that too, since it changes the workload calculation for the role.
Spell out the onboarding structure as well. “First two weeks are read access to the repo and the internal-testing track; no production Play Console access until day 15” tells a candidate your team understands the cost of handing over release credentials before someone knows the codebase. It also attracts developers who value careful, tested work over rushed shipping, which is the right tradeoff for anyone who can trigger a public Play Store rollout.
Common JD Mistakes
Listing Compose and XML Views as Interchangeable Requirements
Requiring “Jetpack Compose and/or XML View experience” without specifying your actual codebase mix tells candidates you have not thought through what they will encounter on day one. A developer who has only built greenfield Compose apps may struggle in an XML-heavy codebase with fragment transactions and manual view binding, and the reverse is just as true. Name your actual split and let candidates self-select.
Treating Java as Optional When It Is Not
If any meaningful portion of your app is still in Java, say so in the requirements, not the nice-to-haves. A developer hired on the assumption of a pure-Kotlin codebase who discovers a legacy Java networking layer in week one will disengage quickly, and that mismatch is entirely avoidable with an honest JD.
Skipping the Minimum and Target SDK Versions
“Support for current Android versions” is not a requirement, it is a guess. State the actual minSdk and targetSdk values, since those two numbers determine which APIs are available and how much conditional-behavior code the developer will need to write and maintain across device fragmentation.
Omitting the Real State of the Release Pipeline
A developer inheriting a manual, Android Studio-driven upload process operates in a very different environment from one working inside a mature Gradle and GitHub Actions pipeline with automated staged rollouts. Both are legitimate starting points. However, a JD that describes the pipeline honestly attracts candidates who are ready for that reality, while a JD that implies a mature pipeline when none exists sets up an early mismatch.
Frequently Asked Questions
Should I require Jetpack Compose or XML View experience in the job description?
Require whichever toolkit makes up the majority of your current codebase, and list the other as a plus if any legacy screens remain. Production apps in 2026 typically use a mix of both, so a candidate with deep experience in only one toolkit can usually ramp on the other within a few weeks if the architecture is otherwise familiar. Being explicit about the actual split in your codebase, rather than listing both as equally required, reduces mismatched expectations after the offer.
Do I need to require Java experience?
Only if a meaningful portion of your app is still written in Java. Many apps built since 2018 are pure Kotlin, in which case Java reading fluency is unnecessary. If your app has a legacy networking layer, a shared library, or older activities still in Java, list it as a required skill rather than a preference, since candidates without that experience will need real ramp-up time before touching that code confidently.
How do I write the salary range for a nearshore Android hire?
For nearshore placements through Kore BPO, the salary range in your JD reflects what you pay through the staffing arrangement. Senior Android developers from Costa Rica typically fall in the $45,000 to $68,000 range all-in, which is 40 to 60% below equivalent US-based compensation for the same experience level. You can review current ranges directly in a Kore BPO discovery call before committing to a public posting, which lets you sanity-check the range against your budget early.
Should I ask candidates to walk through a Play Store policy rejection they have handled?
Yes, and it is one of the more revealing screening questions for a mid-to-senior Android role. A candidate who can describe a specific rejection, what policy it violated, and how they resolved it demonstrates real production experience with Google Play’s review process. A candidate who has only ever worked on internal-testing-track builds will not have this story, which is a useful signal if release ownership is part of the role.
Can Kore BPO help build the JD if I am starting from scratch?
Yes. During the discovery call, a Kore BPO account manager will walk through your UI toolkit, architecture pattern, persistence layer, and release process to build a role specification that reflects what you actually need. Many clients find that this conversation surfaces requirements they had not fully articulated on their own. A formal JD is optional for nearshore placements through Kore BPO, since we can source candidates against the specification directly.
Related Articles
HIRE YOUR NEARSHORE ANDROID DEVELOPER
Get pre-screened Android candidates from Costa Rica on your desk within 72 hours. 90-day replacement guarantee on every placement.
GET STARTED TODAYNo upfront fees | 90-day replacement guarantee