How to Hire an Android App Developer: Scorecard and Paid Task

Define the Job Before You Source Candidates

Start with a one-page role brief, not a marketplace or an hourly rate. Name the product's hardest flow, the current codebase, supported devices, backend and SDK dependencies, release responsibilities, working hours, and the first delivery milestone.

Separate required ownership from skills that can be supplied by another team member. A developer who will own one feature needs a different evidence bar from a technical lead responsible for architecture, review quality, Play Console, and production incidents.

Ask for Evidence That Matches the Actual Project

Repository and Stack Fit

• Relevant Kotlin or Java work in the same class of product, with the candidate's contribution identified.
• Experience with the UI system already in use, whether that is Jetpack Compose, Android Views, or a cross-platform framework.
• Ability to run and change the existing Gradle, dependency, CI, lint, and test setup without replacing it by default.

Architecture and Failure Handling

• A clear model for state, navigation, data ownership, concurrency, caching, offline behavior, and recovery.
• Tradeoff decisions tied to product constraints rather than a preferred architecture diagram.
• Tests and observability for the failure modes that matter to the first milestone.

Release and Handover Ownership

• Signing, target API, privacy and SDK declarations, device coverage, release notes, rollout, and rollback responsibilities.
• Incremental commits, reproducible run instructions, decision notes, and a handover another developer can follow.
• Estimates that name assumptions, unknowns, dependencies, and the next point at which the estimate will be revised.

Source Candidates Without Lowering the Evidence Bar

Referrals, Android and Kotlin communities, GitHub, freelance marketplaces, recruiters, and agencies can all produce viable candidates. The source changes the amount of sourcing work; it does not replace technical and delivery verification.

• Referrals and communities: ask the referrer what the person owned, when they worked together, and whether the work resembles your scope.
• Public code and apps: use them to start a technical discussion, then verify the candidate's exact role and the private constraints that are not visible.
• Marketplaces and recruiters: send the same brief and require the same evidence, scorecard, and paid task.
• Agencies: identify the named technical owner and the people who will do the work; do not score only the salesperson or company portfolio.

Compare the Full Delivery Cost

Collect quotes for the same milestone, timezone overlap, engagement model, and acceptance criteria. Record what each quote includes and who absorbs review, correction, and maintenance work.

• Scope: user flows, backend, integrations, offline states, devices, accessibility, and release work.
• Team: named senior owner, contributors, QA, design, project management, and availability.
• Quality gates: code review, automated tests, security, performance, observability, and acceptance evidence.
• Operations: CI/CD, signing, Play Console, incident response, maintenance, and handover.
• Commercial terms: currency, taxes, platform fees, minimum hours, revisions, warranty, and termination.

An hourly rate does not show review load or rework. Use the scope and budget worksheet to normalize the quotes before ranking candidates.

Android Developer Candidate Scorecard

Score each dimension from 0 to 3: 0 means no usable evidence, 1 means partial evidence or close supervision, 2 meets the role, and 3 shows strong evidence beyond the first milestone. Multiply the rating by the weight and divide by 3.

Set the decision rule before interviews. For an independent feature owner, a practical starting rule is at least 70 out of 100, no zero in implementation, tests, or release ownership, and an accepted paid work sample. Adjust the hard gates to the role, but do not average away a security, ownership, or release blocker.

Run the Interview Against the Scorecard

1. Verify Attributable Work

Ask for the candidate's exact role in a relevant release, a code or architecture sample they are allowed to discuss, and one defect or tradeoff they personally owned. A public app proves that the product exists, not who made each decision.

2. Walk Through One Product Constraint

Use a constraint from your brief. Ask how the candidate would model loading, empty, error, retry, offline, authentication-expired, and partial-data states. Follow the answer into tests, monitoring, rollout, and recovery rather than asking disconnected trivia.

3. Check Ownership Boundaries

Confirm who reviews code, controls signing and accounts, prepares declarations, approves dependencies, handles production defects, and maintains the app after the first milestone. Record any responsibility that remains with your team.

Use a Bounded Paid Work Sample

Agree the fee and timebox before work starts. Provide a small starter repository with no production credentials and one real product-shaped flow. State the API contract, supported Android version, allowed dependencies, and acceptance criteria. The candidate should not need access to customer data or live infrastructure.

A useful sample has loading, content, empty, and error states. Add offline or retry behavior only when it is relevant to the role. Keep the task small enough that architecture, implementation, tests, and handover can all be reviewed inside the agreed boundary.

Acceptance Criteria

• A clean clone builds and runs with the documented command and supported toolchain.
• The agreed states behave as specified, including at least one failure path.
• Automated tests cover the core success path and the named failure behavior.
• No production secrets, hidden services, or undeclared paid dependencies are required.
• The delivery includes a focused commit or pull request, run steps, tradeoff note, and known limitations.
• Out-of-scope work is identified rather than silently omitted or expanded.

Score the result with the same matrix used in the interview. Rejecting a sample should point to a written criterion, not a preference introduced after delivery.

Red Flags That Need a Direct Answer

• The candidate cannot separate their contribution from a team portfolio.
• A fixed price or delivery date appears before core flows, dependencies, and acceptance criteria are understood.
• The proposed rewrite or framework migration is not tied to a measured constraint in the existing product.
• The sample cannot be built from a clean clone or depends on undocumented local state.
• Signing keys, personal logins, production credentials, or customer data are requested for the evaluation task.
• Testing, release work, repository access, documentation, or post-delivery ownership is treated as somebody else's problem without naming that owner.

Choose the Hiring Model That Fits the Ownership Gap

• Freelancer: fits bounded work when your team can supply product decisions, technical review, accounts, and release ownership.
• Employee: fits a continuing roadmap where product context, maintenance, and cross-team work justify a permanent role.
• Agency: fits a defined delivery when you need design, engineering, QA, and project ownership under one contract. Verify the named delivery team with the same scorecard.