Android Developer Interview Questions and Scorecard
Free Android developer interview questions for employers with no technical team: 6 sets on Kotlin, Compose, shipping, plus a scorecard. Download as DOCX.
Android Developer Interview Questions and Scorecard
Six question sets for the owner or manager running the interview: Android fundamentals, Kotlin and Compose, shipping and releases, architecture and testing, ownership, and a scoring rubric. Every question comes with what a good answer sounds like. Download as DOCX.
The hardest part of hiring an Android developer at a small company is not writing the questions. It is knowing whether the answer you just heard was good. Most owners making this hire cannot read the code, have no engineer on staff to sit in, and are choosing between three candidates whose resumes look interchangeable.
This kit is built for that situation. Every question below comes with a note on what a strong answer sounds like and what a weak one sounds like, so you are listening for a recognizable pattern instead of grading technical accuracy. At FirstHR, we build for the owners and managers who run these interviews themselves, alongside everything else.
Six sets, downloadable as one Word document: Android fundamentals, the Kotlin stack, shipping and releases, architecture and testing, ownership, and a scoring rubric. Pair them with the Android developer job description you posted, so the interview tests what you actually advertised.
TL;DR
Interview an Android developer on five things: shipped apps you can install, platform depth (lifecycle, fragmentation, background limits), the modern Kotlin stack (coroutines, cancellation, Compose), release ownership (staged rollout, monitoring, rollback), and communication. The best single screening question is what happens to a screen when the user rotates the phone. Benchmark pay to software developers: a $135,980 national median (BLS OEWS, May 2025). Download six sets and a scorecard as DOCX.
What to Assess in an Android Developer
Assess five things: shipped Android work you can verify, depth in the platform itself, fluency in the current Kotlin stack, ownership of the release process, and the ability to explain a trade-off to someone who does not write code. A candidate can be strong in the first three and still be wrong for a small business if they have never pushed a release or never had to talk to an owner.
Android has a specific quality that shapes the interview: the same app runs on an enormous range of devices, Android versions, screen sizes, and network conditions. Careless code works fine on a new phone in an office and falls apart on a three-year-old device on a weak connection. Questions that surface that awareness are worth more than questions about syntax.
Shipped Android work
Live apps you can install and open
A clear line between their work and the team's
Real decisions they can defend
Platform depth
Lifecycle and saved state under interruption
Fragmentation across versions and devices
Background limits and permission changes
Release ownership
Has pushed releases, not only merged code
Staged rollout, monitoring, and rollback
Treats the store account as a company asset
Ownership and clarity
Raises slipping deadlines early with options
Explains trade-offs to a non-developer
Shares knowledge instead of hoarding it
There is no separate federal occupation code for Android developers. The Bureau of Labor Statistics counts them inside software developers, quality assurance analysts, and testers, a group of 1,693,800 people in 2024 that is projected to grow 15 percent through 2034, with about 129,200 openings a year. That matters for the interview too: generic software-developer question lists will not test the platform-specific judgment this role needs.
Which Question Set Should You Use?
Use the fundamentals set on every candidate, then add the sets that match the role. A short contract to fix a defect needs the fundamentals and the technical sets. A first mobile hire who will own the app alone needs all six, especially shipping and ownership.
Android Fundamentals
First call, 25 minutes
The screening set any interviewer can run: shipped apps, the activity lifecycle, fragmentation, and how they learn a release went wrong. Start here.
Kotlin, Coroutines, Compose
Technical round
The modern stack: Kotlin null safety, coroutines and cancellation, threading, Compose state hoisting, and a real performance fix they measured.
Shipping and Releases
The set most lists skip
Build to staged rollout, store account ownership, signing keys, rollback under a crash spike, and forced target-version migrations.
Architecture and Testing
Your maintenance cost
How they structure an app, where logic lives, what they test and deliberately do not, offline behavior, dependencies, and code review.
Ownership and Behavioral
Solo developer reality
Knowledge sharing, disagreeing with a non-technical decision maker, thin requirements, early warning on deadlines, and interest in your product.
Scoring Rubric + Red Flags
Rate and protect
A six-area 1-to-5 scorecard, an Android-specific red-flag list, and a business-protection checklist for the store account, keys, and code ownership.
Match the Set to the Hire
First mobile hire who will own the app alone: all six sets, with extra weight on Shipping and on Ownership. Adding a developer to an existing mobile team: Fundamentals, Kotlin, and Architecture, since your team already owns the release. Short contract on a defined defect: Fundamentals and Kotlin only. Junior hire: Fundamentals and Ownership, and judge the technical set on reasoning rather than coverage. The Scoring Rubric goes with every combination.
6 Free Android Developer Question Sets to Download
Download all six as one Word document, or copy the sets you need. Each follows the same structure: when to use it, the questions with good-answer notes in parentheses, what to listen for, and space for notes. The last file is the rubric, with red flags and a business-protection checklist.
Download All 6 Android Developer Question Sets
Fundamentals, Kotlin and Compose, shipping and releases, architecture and testing, ownership, and a scoring rubric with red flags. All in one DOCX.
Set 1: Android Fundamentals Screening Questions
The 25-minute first call, written so a non-technical interviewer can run it: shipped apps, the activity lifecycle, fragmentation, and how they find out a release went wrong. Start here for every candidate.
Android Fundamentals Screening Questions
ANDROID FUNDAMENTALS SCREENING QUESTIONS
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the first-call set. It takes about 25 minutes and it is written so a
non-technical interviewer can run it. Ask 6 to 8 questions. Every question below
carries a note on what a good answer sounds like, so you are listening for a
pattern rather than grading code. Score on the rubric in Set 6.
The goal of this call is not to find the best engineer. It is to rule out the
candidates who have never actually shipped an Android app.
QUESTIONS
1. Tell me about the Android app you are proudest of. What was it, and what
part of it did you personally build?
(Good answer: names a live app, separates their own work from the team's,
and can describe a decision they made. Weak answer: "I worked on the app.")
2. Send me a link to something you shipped that I can install right now.
(Good answer: gives a Play Store link without hesitation, or explains
plainly why the work was internal or under NDA and offers a code sample.)
3. What are the main building blocks of an Android app, and what is each for?
(Good answer: activities and screens, services for background work,
broadcast receivers for system events, content providers for shared data.
Explains them in plain language rather than reciting a list.)
4. Walk me through what happens to a screen when a user rotates the phone or
takes a phone call in the middle of using the app.
(Good answer: describes the activity lifecycle, explains that the screen can
be destroyed and recreated, and says how they save and restore state. This
is the single best screening question for real Android experience.)
5. Which Android versions and devices did your last app support, and who
decided that?
(Good answer: knows the minimum supported version, ties it to real user
data, and treats it as a business decision. Weak answer: no idea.)
6. What breaks on Android that does not break on other platforms?
(Good answer: device and version fragmentation, background execution limits,
permission changes between releases, memory on cheap devices, manufacturer
differences. A candidate who cannot name any has not shipped much.)
7. How do you find out that something went wrong in a released app?
(Good answer: crash reporting, the vitals dashboards in the store console,
user reports, and a habit of checking them rather than waiting for
complaints.)
8. What is the last thing you learned about Android that changed how you work?
(Good answer: something specific and recent. The platform moves fast, and a
candidate who is not tracking it will fall behind inside a year.)
WHAT TO LISTEN FOR
•Real shipped work, with a clear line between their part and the team's
•Plain-language explanations, not memorized definitions
•Awareness that Android runs on wildly different devices
•Curiosity about the platform, not just the code
NOTES
__
__
Set 2: Kotlin, Coroutines, and Compose Questions
The technical round on the modern stack: Kotlin null safety, coroutines and cancellation, threading, Compose state hoisting, and a performance problem they measured before fixing.
Kotlin, Coroutines, and Compose Questions
KOTLIN, COROUTINES, AND COMPOSE QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
Use this set on the technical round, once the candidate has cleared the
fundamentals screen. It covers the modern Android stack: Kotlin as the primary
language, coroutines for asynchronous work, and Compose as the current way to
build user interfaces. If nobody on your side can judge the answers, hire two
hours of an outside senior developer and hand them this page.
QUESTIONS
1. Kotlin or Java for a new Android app today, and why?
(Good answer: Kotlin, because it is the language the platform documentation,
libraries, and tooling are built around now. A candidate who argues for Java
on a greenfield app should have a specific reason, such as an existing Java
codebase you already own.)
2. Explain null safety in Kotlin as if I were not a developer.
(Good answer: the language forces you to say up front whether a value is
allowed to be missing, which removes a whole category of crashes. Bonus if
they mention that overriding the check with a shortcut operator is a smell.)
3. What is a coroutine, and what problem does it solve?
(Good answer: a way to do slow work, such as a network call, without
freezing the screen, written so it reads top to bottom instead of as a chain
of callbacks.)
4. What happens to in-flight work when a user leaves the screen?
(Good answer: the work should be cancelled with the screen unless it must
outlive it, and they can name the scope they tie work to. A candidate who
has never thought about cancellation will leak work and battery.)
5. Which thread does network or database work belong on, and why does it
matter?
(Good answer: off the main thread, because the main thread draws the screen
and blocking it produces a freeze and eventually an application-not-
responding dialog.)
6. Where do you stand on Compose versus the older layout system?
(Good answer: has an opinion grounded in real work, knows the two can live
in the same app, and does not insist on rewriting a working screen for the
sake of it.)
7. In Compose, what is state hoisting and why does it matter?
(Good answer: state lives above the component that displays it, so the
component stays reusable and testable and the screen has one source of
truth.)
8. Tell me about a performance problem you found and fixed on Android.
(Good answer: names the symptom, the tool they used to measure it, the
cause, and the result. Measurement before the fix is the tell.)
WHAT TO LISTEN FOR
•Fluent, current Kotlin, not Java habits written in Kotlin syntax
•Understands cancellation and threading, not just syntax
•Pragmatic about Compose adoption rather than dogmatic
•Measures before optimizing
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
The set most question lists skip and the one that matters most for a solo hire: build to staged rollout, store account ownership, signing keys, rollback under a crash spike, and forced platform migrations.
Shipping, Releases, and Store Questions
SHIPPING, RELEASES, AND STORE QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
This is the set most interview lists skip, and for a small business it is the
most important one. Writing Android code and getting an app safely into users'
hands are different skills. If your new hire will be the only mobile developer,
they own the release process, the store account, and the incident response. Ask
every question here.
QUESTIONS
1. Walk me through everything that happens between "the feature is done" and
"a user has it on their phone."
(Good answer: code review, automated checks, a build, an internal or beta
track, then a staged release to a small percentage of users, watched before
going wider. Vagueness here means somebody else always did it for them.)
2. Have you managed a store developer account and the release listing?
(Good answer: yes, and they know the account belongs to the company, not to
a person. Ask this even if the answer is no; you need to know.)
3. How do you handle app signing keys, and what happens if one is lost?
(Good answer: keys are held by the business, backed up, and never sitting
only on a laptop. A candidate who shrugs at this is a real risk to you.)
4. A release goes out and crash reports spike within an hour. What do you do?
(Good answer: halt or roll back the staged release first, then diagnose.
Stopping the bleeding before debugging is the mark of someone who has
actually been on call.)
5. The platform requires apps to target a recent version to publish updates.
How have you handled that kind of forced migration?
(Good answer: has done at least one, treats it as scheduled maintenance
rather than an emergency, and can name what broke. Every Android app faces
this on a repeating cycle, so budget for it.)
6. How do you decide when to drop support for an older Android version?
(Good answer: looks at the share of real users still on it, weighs the
engineering cost, and brings the decision to the business rather than
deciding unilaterally.)
7. What do you watch after a release, and for how long?
(Good answer: crash-free rate, application-not-responding rate, and the
specific metric the feature was supposed to move, watched for days, not
minutes.)
8. Describe the worst production incident you were part of and what changed
afterward.
(Good answer: tells it honestly, including their own mistakes, and names a
process change that came out of it.)
WHAT TO LISTEN FOR
•Has personally pushed releases, not just merged code
•Treats the store account and signing keys as company assets
•Rolls back first, debugs second
•Watches the numbers after shipping
NOTES
__
Set 4: Architecture, Testing, and Code Quality Questions
For a hire whose structural choices become your maintenance cost: app structure, where logic lives, what they test and deliberately do not, offline behavior, dependency judgment, and code review.
Architecture, Testing, and Code Quality Questions
ARCHITECTURE, TESTING, AND CODE QUALITY QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
Use this set when the hire will be your only developer on the app, or the first
of a small team, because then their structural choices become your maintenance
cost for years. Skip it for a short contract fixing a specific defect. The
answers matter less than whether the candidate can explain a trade-off out loud.
QUESTIONS
1. How do you structure an Android app, and why that way?
(Good answer: separates the screen from the logic and the data, names a
pattern they actually use, and explains what it buys them. A candidate who
names a pattern but cannot say why it helps is repeating a job posting.)
2. Where does business logic live in your apps, and why not in the screen?
(Good answer: outside the screen class, so it survives rotation and can be
tested without a device.)
3. What do you test on Android, and what do you deliberately not test?
(Good answer: heavy automated coverage on logic, a thin layer of interface
tests on the paths that must never break, and an honest statement that
testing everything through the interface is slow and brittle.)
4. How do you handle a screen that has to work offline or on a bad connection?
(Good answer: local storage as the source of truth, background syncing, and
a real answer for what the user sees while data is stale.)
5. How do you decide whether to add a third-party library or write it
yourself?
(Good answer: weighs maintenance risk, size, and licensing. A candidate who
adds a dependency for everything, or refuses all of them, is telling you
something.)
6. How do you keep the app size and startup time under control?
(Good answer: knows that unused code and resources get stripped at build
time, measures startup, and knows that install size affects conversion on
slow connections.)
7. What does a good code review look like to you?
(Good answer: focused on correctness and clarity, delivered kindly, and
understood as a two-way conversation.)
8. Show me a piece of code you are proud of and walk me through it.
(Good answer: can narrate their own reasoning, including what they would
now do differently. This is the highest-signal question in this set.)
WHAT TO LISTEN FOR
•Explains trade-offs rather than reciting best practices
•Tests logic, not everything
•Thinks about the user on a bad connection and a cheap device
•Comfortable being questioned about their own code
NOTES
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Set 5: Ownership, Collaboration, and Behavioral Questions
The solo-developer reality: knowledge sharing, disagreeing with a non-technical decision maker, thin requirements, raising a slipping deadline early, and genuine interest in your product.
Ownership, Collaboration, and Behavioral Questions
OWNERSHIP, COLLABORATION, AND BEHAVIORAL QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
At a small business the Android developer is often the only person who
understands the app, works with no technical manager above them, and talks
directly to the owner. That makes ownership and communication as load-bearing as
technical skill. Ask for real past examples and follow every answer with "what
was the result?"
QUESTIONS
1. Tell me about a time you were the only person who understood a system.
How did you keep the business from depending on you alone?
(Good answer: wrote things down, brought someone else along, made the
handover possible. Someone who enjoys being the only one who knows is a
risk you will feel later.)
2. Describe a time you disagreed with a non-technical decision maker. What
happened?
(Good answer: explained the trade-off in business terms, and either changed
the decision or committed to it. Contempt for the business side is a red
flag in a small company.)
3. How do you decide what to build when the requirements are thin?
(Good answer: asks questions, ships something small, checks it against
reality. At your size nobody is going to hand them a specification.)
4. Tell me about a deadline you were going to miss. When and how did you say
so?
(Good answer: early, with options. Late disclosure is the most expensive
habit a solo developer can have.)
5. What is the last thing you had to explain to someone non-technical, and how
did you explain it?
(Good answer: a concrete example, translated cleanly. You will be that
person for the next few years.)
6. What kind of work makes you want to leave a job?
(Good answer: honest and specific. Compare it against what this role
actually is before you make the offer.)
7. Why this company and this app?
(Good answer: has used the app or looked at the market. Real interest here
correlates strongly with staying.)
8. What would you want from us in your first 30 days to be effective?
(Good answer: access, context, and one clear first task. It also tells you
what to put in the onboarding plan.)
WHAT TO LISTEN FOR
•Documents and shares rather than hoarding knowledge
•Raises problems early, with options attached
•Translates technical trade-offs into business terms
•Specific interest in your product, not any job
NOTES
__
Set 6: Android Developer Scoring Rubric and Red Flags
A six-area 1-to-5 rubric with evidence lines, an Android-specific red-flag list, and a business-protection checklist covering the store account, signing keys, code hosting, and IP assignment.
Android Developer Scoring Rubric and Red Flags
ANDROID DEVELOPER SCORING RUBRIC AND RED-FLAG CHECKLIST
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO SCORE
Score each area from 1 to 5 immediately after the interview, while it is fresh.
Anchor every score to something the candidate actually said. If more than one
person interviews, each scores independently before anyone compares. Use the
same rubric and the same core questions for every candidate for this role.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
Shipped Android experience: live apps, their own scope, real decisions
How to Judge Answers Without a Technical Background
You do not need to verify the technical content of an answer. You need to tell a specific, honest, plain-language answer from a rehearsed or evasive one. That distinction is learnable in an afternoon, and it filters out most bad hires on its own. The three questions below carry the most signal per minute.
What happens to a screen when the user rotates the phone mid-task?
Strong answer: The screen can be destroyed and rebuilt, so anything the user typed has to be saved and restored deliberately. A strong answer walks the lifecycle in plain language, says where the data was held so it survived, and mentions that the same thing happens on a low-memory device or a permission change. This single question separates people who have shipped Android apps from people who have read about them.
Weak answer: A weak answer says the screen just reloads, or treats rotation as an edge case nobody hits. That candidate has never chased a bug report about a form that emptied itself.
Walk me through everything between the feature being done and a user having it.
Strong answer: Code review, automated checks, a build, an internal or beta track, then a staged release to a small share of users, watched before it goes wider. A strong answer names what they watch afterward, crash-free rate and the metric the feature was meant to move, and says how they halt a bad rollout. This tells you whether they can own your release process alone.
Weak answer: A weak answer stops at the code being merged, or describes a process someone else always ran for them. If this is your only mobile hire, that gap becomes your problem in week two.
What happens to in-flight work when a user leaves the screen?
Strong answer: The work should be cancelled along with the screen unless it genuinely has to outlive it, and the candidate can name the scope they tie work to. A strong answer explains why: uncancelled work drains battery, writes results into a screen that no longer exists, and produces crashes that only show up on slow connections.
Weak answer: A weak answer has never considered cancellation at all, which is common in candidates who learned coroutines from tutorials rather than from a shipped app under real network conditions.
Two habits make this work. Follow every answer with some version of what was the result, because a candidate with real experience has a number or an outcome ready. And when a candidate uses a term you do not know, ask them to explain it to you as if you were not a developer. Someone who cannot do that will not be able to explain a delayed release to you either.
Signal
What it usually means
Names the app, the version, the device
Has shipped and remembers the details
Separates their work from the team's unprompted
Honest about scope; easy to reference-check
Explains a trade-off instead of a best practice
Has made the decision, not read about it
Measured before optimizing
Engineering discipline rather than guesswork
Volunteers what they would now do differently
Learns from shipped work; low ego
Answers stay abstract under follow-up
Studied the topic rather than lived it
The Shipping Questions Most Lists Skip
Writing Android code and getting an app safely into users' hands are different skills, and almost every interview-question list online covers only the first. For a small business this is backwards, because if your new hire is the only mobile developer, they own the release process, the store account, and the response when something breaks at nine on a Friday.
Android also forces a recurring maintenance cycle that surprises non-technical owners. The store requires apps to target a reasonably recent platform version in order to publish updates, so every app faces a migration on a repeating schedule whether or not you asked for new features. Ask how the candidate has handled one, and budget for it.
1
Ask them to narrate a release end to end
From merged code to a user's phone: review, automated checks, build, internal or beta track, staged rollout to a small share of users, then wider. Vagueness means someone else always did this part.
2
Ask what they watch afterward, and for how long
Crash-free rate, application-not-responding rate, and the specific metric the feature was meant to move, watched for days rather than minutes. Named metrics are the tell.
3
Give them a crash spike and see what comes first
A strong candidate halts or rolls back the staged release, then diagnoses. Debugging while users keep updating is the answer of someone who has never been on call.
4
Ask who owned the store account and the signing keys
You are listening for the understanding that both belong to the company. This one answer can save you from an app you cannot update after the developer leaves.
5
Ask about a forced platform migration they lived through
Has done at least one, treats it as scheduled maintenance rather than an emergency, and can name what broke. This is recurring work you will pay for every year.
Never Let a Developer Register the Store Account Personally
The most damaging shortcut in small-company mobile hiring is letting the first developer create the store developer account under a personal email because it takes five minutes and the company paperwork is not ready. When that person leaves, the business cannot publish an update to its own app, and recovery is slow and sometimes impossible. Register the account to the company, hold the signing keys where the owner can reach them, add the developer as a user with defined permissions, and put access removal on the offboarding checklist next to the laptop.
Follow-Ups and Red Flags
The questions open the door; the follow-ups tell you what is behind it. Push for the specific version, the actual metric, the real outcome, and the part they personally owned. Most weak candidates hold up fine for one question and thin out on the second.
No app you can install
Every question in the fundamentals set assumes a shipped app behind it. A candidate who cannot point at one, or explain plainly why it is internal, is answering from theory.
Merged code but never released
Plenty of strong engineers have never owned a release because someone else did. That is fine on a team and disqualifying if this is your only mobile hire.
Casual about keys and accounts
A shrug at signing keys or a suggestion to register the store account under a personal email is the most expensive red flag on this page.
Every failure was someone else
Ask about the worst production incident. A candidate who owns none of it will not tell you when the next one is coming either.
Weigh red flags rather than counting them. A strong engineer who has never owned a release is a fine hire onto an existing team and a poor one as your only mobile developer. A candidate who is careless about signing keys is a risk in every configuration, which is why that item sits on the checklist rather than the scorecard.
Work Samples and Paid Take-Home Exercises
A short paid exercise beats a long unpaid one, and reviewing work the candidate has already done often beats both. Asking someone to walk you through their own code for fifteen minutes produces more signal than a weekend project, because you hear the reasoning rather than reading the result.
Approach
Walkthrough of existing work
Multi-day unpaid project
Reveals reasoning, not just output
Costs the candidate under an hour
Keeps strong candidates in the process
Comparable across candidates
Tests work on your actual codebase
When you do need a take-home, keep it to two to four hours, pay for the time, make the brief resemble real work, and say in advance how it will be judged. Give the same exercise to every candidate for the role and score it on the same criteria, which is what the EEOC guidance on employment tests and selection procedures asks of any selection tool. This is general information, not legal advice.
Fair, Legal, and Structured Interviewing
Ask the same job-related questions of every candidate, score them on the same rubric, and you get the fair version and the effective version at once. That is the whole method, and it is the part the technical question lists leave out entirely.
Same Questions, Same Rubric, Better Decisions
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC's rules against basing decisions on protected characteristics.
Keep every question tied to building and shipping Android software. Avoid the small-talk traps about age, graduation year, family plans, origin, and health, which come up easily in a friendly technical conversation. Several states and cities also restrict salary history questions, so check your own jurisdiction. Structuring the interview this way is also one of the more effective ways to reduce bias in hiring. This is general information, not legal advice.
What an Android Developer Costs
There is no separate Bureau of Labor Statistics occupation for Android developers, so benchmark against software developers, occupation code 15-1252, then adjust down for a smaller market and a smaller app. The federal data covers the whole software developer population, which skews toward large employers in expensive metros.
Median $135,980 a Year (BLS OEWS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers earned a national median of $135,980 per year, or $65.38 per hour. The percentile ladder runs $82,460 at the 10th, $105,210 at the 25th, $171,980 at the 75th, and $214,670 at the 90th (U.S. Bureau of Labor Statistics, OEWS national estimates).
Hiring situation
Where it usually lands
What to say in the interview
Mid-level, small business, outside a tech metro
25th to 50th percentile
Name a range, and be specific about the app and the scope
Senior or lead, owns the app alone
Above the median
Price the release ownership, not just the coding
Junior, first mobile role
Near the 10th to 25th percentile
Be explicit about mentoring, or you will not get one who grows
Contract or fractional, project-scoped
Hourly, above salaried equivalent
Confirm classification separately from the rate
Bring the range into the interview rather than saving it for the offer. Candidates with options will not sit through three rounds for an unstated number, and several states now require a good-faith range in the posting anyway. Setting it early also keeps the offer letter from becoming a negotiation you already lost.
Interviewing an Android Developer Without HR
A large company runs this hire through a recruiter, a panel of engineers, and a calibrated scorecard. A small business runs it through one owner between everything else, usually without anyone who can grade a technical answer. Here is how to make that version rigorous.
You are hiring a developer and you cannot read code
Most owners making their first Android hire cannot grade a technical answer, and that feels disqualifying. It is not. Three moves close almost the entire gap. First, install what the candidate shipped and use it for ten minutes on your own phone, paying attention to a bad network, a wrong password, and an empty screen. Second, run the fundamentals set on this page and listen for the pattern the good-answer notes describe rather than for correctness. Third, buy two hours of an outside senior developer for one technical conversation and one code-sample review. That last one costs a few hundred dollars and turns an unmakeable decision into a normal hiring decision.
One developer becomes a single point of failure
When the Android developer is your only mobile person, everything they know that is not written down is a risk you are carrying. Interview for that directly. Ask how they kept a business from depending on them alone the last time they were the only one who understood a system, and listen for documentation, pairing, and deliberate handover rather than pride at being indispensable. Then remove the structural version of the same risk before the first commit: register the store developer account to the company rather than a personal email, hold the app signing keys where the owner can reach them, host the code in a company repository, and put a signed intellectual property assignment in the offer package.
The interview is inconsistent, so the comparison is meaningless
Without a recruiter, interviews drift. One candidate gets a friendly conversation, the next gets an interrogation, and by the third you are comparing impressions rather than evidence. The fix is the same one large companies use: the same core questions for every candidate, scored on the same rubric right afterward, with each interviewer scoring before anyone talks. That is what makes the six sets and the scorecard here worth downloading rather than reading. After you choose someone, the work becomes access and paperwork, which is where FirstHR fits: e-signature on the offer and the intellectual property assignment, documents stored on the employee profile, and a task workflow for repository, pipeline, and store access. Applicant tracking is coming soon to FirstHR.
Everything above is a version of the same idea: replace judgment you do not have with structure you can run. The same core questions for every candidate, scored right after each interview you conduct, plus a paid outside opinion on the one dimension you genuinely cannot assess. Reference calls close the loop, so ask the people who watched them ship, using the reference check questions rather than a character conversation. Applicant tracking is coming soon to FirstHR, which will hold the candidates, the notes, and the scores in one place instead of a folder of Word files.
From Interview to Onboarding
The interview is step one. A developer hire is mostly access: repositories, build pipelines, crash reporting, API keys, and the store console, all granted inside the first two days, alongside the signed offer and the intellectual property assignment. Get the sequence written down once and it becomes reusable, including in reverse when someone leaves.
Offer and IP assignment
Confirm role, pay, and classification in writing, and get the intellectual property assignment signed before any code is written for you.
Access, granted deliberately
Repository, build pipeline, crash reporting, API keys, and the store console, each granted to a named account you control and can revoke.
Company owns the assets
Store developer account under the company entity, signing keys backed up by the business, and the code in a company-owned repository.
Records in one place
Signed offer, IP assignment, I-9, W-4, and policy acknowledgments stored against the employee profile instead of scattered across inboxes.
Score everyone before you decide, then close the loop with a clear interview feedback step so rejected candidates hear back and your notes stay usable. For engineering hires specifically, our guide to onboarding remote developers covers the sequence from access grants to the first shipped change.
FirstHR runs that sequence as one tracked workflow: e-signature on the offer and the IP assignment, documents stored against the employee profile, and a task list for every access grant so nothing is discovered missing in week three. FirstHR is an onboarding and HR platform, not a code hosting service or a mobile build system, so connect those separately. Applicant tracking is coming soon to FirstHR. More hiring kits sit in the hiring templates library.
Key Takeaways
Assess five areas: shipped Android apps, platform depth, the Kotlin stack, release ownership, and communication.
The best single screening question is what happens to a screen when the user rotates the phone, because saved state under interruption is learned only by shipping.
Ask the shipping questions most lists skip: staged rollout, monitoring, rollback, and who owned the store account and signing keys.
You do not need to verify technical content; listen for specific, plain-language, honest answers using the good-answer notes.
Buy two hours of an outside senior developer for one technical conversation and one code-sample review if nobody on your side can judge it.
Benchmark pay to software developers (BLS OEWS, May 2025): a $135,980 national median, with the 25th percentile at $105,210 and the 75th at $171,980.
Register the store developer account to the company and hold the signing keys before the first commit.
Frequently Asked Questions
What questions should I ask an Android developer in an interview?
Ask across five areas: shipped Android experience, platform depth, the modern Kotlin stack, release ownership, and behavior. The highest-signal openers are: tell me about the Android app you are proudest of and what you personally built; send me a link to something I can install right now; walk me through what happens to a screen when the user rotates the phone or takes a call; which Android versions did your last app support and who decided that; and walk me through everything between the feature being done and a user having it on their phone. The rotation question separates people who have shipped from people who have studied, because saved state under interruption is something you only learn by fixing it. The release question matters most when the hire will be your only mobile developer. This page ships six downloadable sets covering all of it, each question paired with what a good answer sounds like.
How do I interview an Android developer if I am not technical?
You can, with three moves. First, install what the candidate shipped and use it for ten minutes on your own phone, paying attention to how it handles a bad network, a wrong password, and an empty screen; those three moments reveal care better than a resume. Second, run the fundamentals set on this page and listen for the pattern rather than grading correctness, because every question here carries a note on what a good answer sounds like: specific, plain-language, and honest about scope. Third, buy two hours of an outside senior developer for one technical conversation and one code-sample review. That costs a few hundred dollars and turns an unmakeable decision into a normal hiring decision. Score every candidate on the same rubric immediately after the interview so you compare written evidence rather than impressions.
Should an Android developer know Kotlin or Java?
Kotlin, for almost any role you are hiring for now. Kotlin is the language the platform documentation, sample code, libraries, and tooling are built around, and a candidate arguing for Java on a new app should have a concrete reason, such as an existing Java codebase you already own and want maintained. Java knowledge is still useful because many production Android apps are mixed and older code has to be read and maintained, so treat it as a bonus rather than a requirement. In the interview, test fluency rather than syntax: ask them to explain null safety in plain language, what a coroutine solves, and what happens to in-flight work when a user leaves the screen. A candidate writing Java habits in Kotlin syntax will show up in those answers. The Kotlin set on this page covers the modern stack in full.
What is an Android developer interview scorecard?
It is a simple rubric that rates each candidate from 1 to 5 on the same areas, with space for the evidence behind each score. The scorecard on this page uses six areas: shipped Android experience, platform depth, the modern Kotlin and Compose stack, release ownership, architecture and testing, and ownership and communication. Each interviewer scores independently and immediately after the interview, then the group compares written evidence before discussing, which stops a single strong impression or the most senior voice in the room from setting the decision. The same file includes an Android-specific red-flag list and a business-protection checklist covering the store developer account, the app signing keys, code hosting, and the intellectual property assignment. A downloadable scorecard is the asset most interview-question lists leave out.
How much does an Android developer cost?
There is no separate federal occupation for Android developers, so the right benchmark is software developers, occupation code 15-1252. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers earned a national median of $135,980 per year, or $65.38 per hour, with the 10th percentile at $82,460, the 25th at $105,210, the 75th at $171,980, and the 90th at $214,670. Those national figures skew toward large employers in expensive metros. A small business hiring a mid-level Android developer outside a major tech market usually lands between the 25th and 50th percentiles, while senior mobile roles at product companies sit above the median. Benchmark to your local market and to the size of the app rather than to the national number, and publish a good-faith range wherever pay transparency law requires one.
Should I give an Android developer a take-home test?
A short paid exercise beats a long unpaid one, and reviewing existing work often beats both. If the candidate has shipped apps you can install, or a code sample they can walk you through, start there; asking someone to narrate their own code for fifteen minutes is the highest-signal exercise available and it costs nobody a weekend. When you do need a take-home, keep it to two to four hours, pay for the time, make the brief resemble real work on your app, and tell candidates in advance how it will be judged. Multi-day unpaid projects lose you the strongest applicants, who have options, and can create wage exposure depending on how the work is used. Whatever you choose, give the same exercise to every candidate for the role and score it on the same criteria. This is general information, not legal advice.
What questions are illegal to ask in a developer interview?
Avoid anything that probes a characteristic protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. In practice that rules out questions like how old are you, when did you graduate, where are you originally from, do you plan to have children, and any health question, even as small talk before the technical part starts. You may ask whether someone can perform the essential functions of the job and whether they are legally authorized to work in the United States. Several states and cities also restrict asking about salary history, so check your own jurisdiction before you ask. Keeping every question tied to building and shipping Android software, and asking the same questions of every candidate, is the simplest way to stay both fair and compliant. This is general information, not legal advice.
How many interview rounds does an Android developer hire need?
Two or three is usually right for a small business. Round one is a 25 to 30 minute fundamentals screen you can run yourself, aimed at ruling out candidates who have not actually shipped an Android app. Round two is the technical round covering Kotlin, coroutines, Compose, architecture, and testing, ideally with a code-sample walkthrough; if nobody on your side can judge it, bring in a paid outside senior developer for that hour. Round three is the ownership and behavioral conversation, usually with the owner, covering knowledge sharing, deadlines, and disagreement with non-technical decision makers. Adding rounds beyond that mostly costs you candidates rather than improving the decision. Score after each round rather than at the end, and use the same core questions for every candidate so the comparison holds up.
