Mobile Developer interview scorecard template
A structured scorecard for interviewing a Mobile Developer: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The Mobile Developer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Platform lifecycle and state handling Whether the candidate handles what the operating system does to an app — backgrounding, process death, restoration — instead of only the happy path. | 20% | Describes screens and navigation but has never dealt with an app killed in the background losing what the user had typed. | Explains where state is persisted, what survives process death, and a bug they fixed that only reproduced after the system reclaimed memory. |
| Release ownership through store review Whether the candidate has shipped to a store end to end — versioning, signing, staged rollout, rejection — or handed builds to someone else. | 18% | Says another team publishes the app and cannot describe what happens between a merged branch and a user installing the update. | Describes their release checklist, a submission that was rejected and why, and how they held back a rollout after a bad crash signal. |
| Offline behavior and data synchronization How the app behaves on a bad or absent connection, which determines how much of the product works outside an office network. | 18% | Treats network failure as an error dialog, and has not considered what happens to an action the user took while offline. | Describes what is queued, what is retried, how conflicts are resolved on reconnect, and a data-loss bug that pattern prevented. |
| Performance on real devices Whether startup time, memory and battery are measured on hardware users actually own, rather than judged on a simulator or a flagship phone. | 16% | Reports the app feels fast on their own device and has never profiled startup time or memory on a low-end handset. | Names the metric they tracked, the device class they tested on, the change they made, and the measured improvement afterward. |
| Crash triage from production telemetry Whether the candidate uses crash and error reporting to find real causes, given that mobile bugs rarely reproduce on the developer machine. | 16% | Waits for user reports or a reproducible case, and describes crashes as issues on certain devices with no further detail. | Reads a stack trace against device and OS breakdowns, states the hypothesis it supported, and shows the crash rate before and after the fix. |
| Adaptive UI and accessibility Whether the interface holds up across screen sizes, system font scaling and assistive technology, instead of only on the design reference device. | 12% | Builds against one screen size and treats layout breakage on other devices as a design problem to be reported elsewhere. | Describes testing with enlarged system fonts and a screen reader, and names a layout they rebuilt because it broke under those conditions. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Tell me about a bug that only appeared on real devices in production. What did the crash data show, and how did you confirm the cause?
- Walk me through your last release, from merged code to users installing it. What is on your checklist, and when did you last hold a rollout back?
- Describe how your app behaves when the connection drops mid-action. What did you queue or retry, and what conflict did that create on reconnect?
- What performance number did you improve — startup, memory, battery? Which device did you measure on, and what was it before and after?
- Point to a screen you had to rebuild after testing with larger system fonts or a screen reader. What broke, and what did you change?
Red flags
- Has shipped apps for years but has never seen a store submission rejected or delayed.
- Describes crashes as device-specific issues without ever reading a stack trace from production.
- Tests only on the newest phone they own and treats older hardware as out of scope.
- Names frameworks fluently but cannot explain what happens when the system kills the app.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a Mobile Developer →
Frequently asked questions
What should a mobile developer interview scorecard include?
Weighted competencies specific to mobile rather than generic engineering: platform lifecycle and state handling, release ownership through store review, offline behavior and sync, performance on real devices, crash triage from production telemetry, and adaptive UI with accessibility. Weight lifecycle and release highest, because those are where mobile differs most from web work and where a mis-hire shows up publicly in reviews.
How do you interview for mobile skills without a live coding test?
Ask about production evidence the candidate could not invent. What their crash rate was and how they moved it, what a store rejection taught them, what happens to a user action taken offline. These require having shipped and watched an app in users hands, which no amount of tutorial work produces.
Should you hire a native or a cross-platform mobile developer?
Decide from your roadmap before you screen, not during. If the app needs deep platform integration, prioritize native depth; if two platforms must move at one team speed, cross-platform experience carries more weight. Either way score the same competencies — lifecycle, release, offline behavior, performance — since those judgment questions do not change with the framework, and keep the evidence cited next to each rating.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.