Why Android hiring needs its own checklist
Android engineers deal with problems iOS teams rarely see: thousands of device models, manufacturer-specific battery restrictions, varied screen densities and foldables, and an OS version spread that can stretch back years. A candidate who has only worked on a single flagship phone may write clean Kotlin and still ship crashes on budget devices.
So our screening leans on production experience. We want to hear how a candidate traced an ANR, handled a background-work restriction on a specific vendor, or reduced APK size for users on limited data plans. If you are looking for a team to build the app end to end instead, our Android development service covers that model.
Android seniority matrix
Mid-level Android developer
- Writes idiomatic Kotlin: null safety, data classes, extension functions, sealed types.
- Builds Compose screens from designs and understands recomposition basics.
- Uses coroutines and Flow inside an existing ViewModel pattern.
- Works with Retrofit or Ktor, Room and DataStore under guidance.
- Writes unit tests and fixes issues reported from QA on a defined device list.
Senior Android developer
- Structures multi-module projects and sets up Hilt or Koin dependency graphs.
- Diagnoses performance with Android Studio profilers, Baseline Profiles and StrictMode.
- Handles WorkManager, foreground services and the restrictions that come with each Android version.
- Migrates XML views to Compose incrementally without breaking interop.
- Triages crashes and ANRs from Play Console vitals and Crashlytics.
Lead Android developer
- Owns Gradle configuration, build performance and version catalogs.
- Sets architecture direction and code review standards for the Android team.
- Plans target SDK upgrades ahead of Play deadlines and manages staged rollouts.
- Works with backend and security teams on authentication, encryption and data storage.
Assessment areas before you interview
| Area | What we ask | What a strong answer shows |
|---|---|---|
| Lifecycle and state | A screen loses user input on rotation and process death. How do you fix it? | Correct use of SavedStateHandle and ViewModel scope, not just config-change hacks |
| Coroutines | Review code that launches work in GlobalScope and collects Flow in onCreate | Understanding of structured concurrency, lifecycle-aware collection and cancellation |
| Compose performance | A list stutters while scrolling. Where do you look? | Stability, keys, remember usage and Layout Inspector recomposition counts |
| Fragmentation | A feature works on Pixel but fails on another vendor's phone | A method for reproducing, isolating vendor behavior and testing on a device farm |
| Build and release | Builds take too long and release signing is manual | Practical steps: configuration cache, modularization, Play App Signing, CI lanes |
| Collaboration | Write a PR description and respond to review comments | Clear reasoning and comfort with async, written communication |
After our screen, you run your own interviews. Our hiring and vetting guide suggests questions if you do not have an Android lead in-house to run them.
Google Play Console access practices
Your Play Console holds your signing configuration, user reviews, financial reports and policy history. We keep access tight by default.
Owner stays with you
Your organization keeps the account owner role. Engineers are invited as individual users, never through shared logins.
App-level permissions
Access is granted per app and per permission: release management and testing tracks, usually without financial data or user management.
Play App Signing
We recommend Google-managed app signing so the app signing key is never on an engineer's laptop. Upload keys live in your CI secrets.
Service accounts for CI
Automated uploads use a service account with release permissions only, created and owned by your Google Cloud project.
Onboarding and daily collaboration
In the first week the engineer gets the project building locally, runs it on the devices in your test matrix and ships a small fix through your normal review path. That first pull request tells both sides whether conventions, branch rules and CI checks are clear.
Day to day, Android engineers attend your standups and planning inside the agreed overlap window. Outside it, they work through tickets with written updates in your tracker. If you also have an iOS engineer on the team, we encourage paired design reviews so both platforms solve the same problem the same way; our page on hiring iOS developers covers that side.
Contracts, replacements and scaling
- 1
Agreement
A services agreement with IP assignment and confidentiality terms, reviewed by your counsel before signing.
- 2
Regular check-ins
Your delivery manager asks for feedback at set intervals so small concerns are raised before they grow.
- 3
Replacement process
If an engineer is not the right fit, we restart the search from the original brief and overlap the incoming engineer with the outgoing one where possible.
- 4
Scaling
Add engineers through the same shortlist process, or reduce headcount with the notice period set in the agreement.
Android specialist or cross-platform engineer?
If your product depends on Android-specific behavior, such as background location, Bluetooth peripherals, managed devices for field staff or deep OS integrations common in enterprise mobile apps, a native Kotlin engineer is the safer hire. If both platforms share most screens and logic, consider whether a Flutter developer could cover both with one codebase. We are happy to talk through that choice before you commit to a role.