Take-homes stopped working. Whiteboard algorithm rounds never worked for mobile. What replaced them, in the loops I have seen produce good hires consistently, is a code review exercise built from a deliberately broken diff.
It takes an hour to construct, it is reusable, and it measures the thing the job now actually requires: judging code you did not write.
Here is how to build one.
The shape of the diff
Two hundred lines, roughly. Big enough to require prioritisation, small enough to read in fifteen minutes. Written in your stack, ideally lifted from a real pull request and then deliberately damaged.
Plant four categories of defect, each at a different level of subtlety.
1. A concurrency bug. A shared mutable cache written from two contexts without synchronisation, or a completion handler that touches the UI from a background thread only when a cache miss happens. The classic mobile version: a request whose callback assumes the view still exists.
2. A lifecycle or memory issue. A strong reference cycle through a closure, a listener registered in one lifecycle callback and never removed, or an observer attached to a long-lived object from a short-lived one. On Android, a coroutine scoped to the wrong lifecycle owner does nicely.
3. An unhandled failure path. A network call whose error branch logs and returns, leaving the UI in a permanent loading state. Bonus: no timeout, so on a slow network it hangs indefinitely rather than failing.
4. A design-level mistake that compiles perfectly. Caching a response keyed by user ID with no invalidation on logout, so the next user on a shared device sees stale data. Nothing crashes. It is the worst bug in the diff.
Add two or three cosmetic issues too — a badly named variable, an inconsistent formatting choice. They are the control group.
How to run it
Give the candidate the diff, plus one sentence of context about what the change is meant to do. Twenty minutes to read, twenty-five to discuss. Tools allowed and encouraged, stated explicitly.
Ask three questions:
- What would you block this pull request on?
- What would you comment on but approve anyway?
- What would you ignore?
The separation matters more than the findings. Plenty of candidates can list every issue; far fewer can rank them, and ranking is what a senior engineer does all day.
What the answers tell you
Finds the cache invalidation bug — the strongest single signal in the exercise. It requires reasoning about state across sessions rather than reading lines. Candidates who catch it are thinking about the system; candidates who only catch the syntax-adjacent issues are reading text.
Finds the concurrency bug — expected from anyone claiming senior mobile experience. Missing it is not automatically disqualifying, but ask a follow-up: what happens if this cache is written from two threads? If they still do not see it, they have not debugged production concurrency issues.
Blocks on cosmetics — a real warning sign. Someone who blocks a release on variable naming while approving an unhandled error path will make your review queue slower and your product no better.
Asks about context — a strong positive. Is this cache shared across users? Do we support device sharing? What does the design say the loading state should do on failure? Good engineers ask what they cannot know from the diff before pronouncing on it.
Tone — you are also learning what their review comments will feel like at 6pm on a Thursday. Precision without contempt is what you want, and it is visible immediately.
Why this works when take-homes do not
A take-home asks the candidate to produce code from a specification. That is precisely the task an assistant performs well, so a clean submission now proves little.
Reviewing a flawed diff inverts the problem. The code already exists; the work is evaluating it. An assistant helps here too — and that is fine, because the candidate still has to decide which of its observations matter, defend the ranking out loud, and answer follow-ups about consequences.
That is exactly the workflow of a modern engineer. When first drafts arrive cheaply, the scarce skill is deciding what to accept, and this exercise measures that directly rather than through a proxy that has stopped correlating.
Two companion exercises
Debug from artefacts. A crash report, a symbolicated trace, a log excerpt and a repro that only fires on a slow network. Grade hypothesis formation, not the fix — whether they narrow methodically, discard theories against evidence, and know which tool answers which question.
Pair on a small extension. In an existing codebase, tools on. Watch whether they verify suggestions, notice subtly wrong output, and can explain the result line by line. Someone who accepts a plausible answer and moves on has told you exactly how they will behave on your codebase.
The mobile-specific probe worth adding
If your roadmap includes on-device or hybrid intelligence, add one question: this feature calls a model — how do you decide between on-device and hosted, and what does the app do when inference fails?
Good answers cover app size against model size, thermal and battery behaviour, latency budgets, offline expectations, per-request cost, and a designed degraded state rather than a spinner. This knowledge does not transfer automatically from general mobile experience, and discovering that after the hire is expensive.
The full hiring playbook — role definition, sourcing routes, skills checklist, regional rate bands, contract terms and a thirty-day onboarding plan — is here: Hire Mobile App Developers in 2026: A Practical Playbook.
Frequently Asked Questions
How do you build a code review interview exercise?
Take a real two-hundred-line pull request in your stack and plant four defects: a concurrency bug, a lifecycle or memory issue, an unhandled failure path, and a design-level mistake that compiles perfectly, such as a cache with no invalidation on logout. Add a couple of cosmetic issues as a control.
What should I ask during a code review interview?
Three questions: what would you block on, what would you comment on but approve, and what would you ignore. The ranking reveals more than the findings — most candidates can list issues, far fewer can prioritise them the way a senior engineer must.
Why is a flawed pull request better than a take-home test?
A take-home asks for code from a specification, which is exactly what assistants do well, so a clean submission proves little. Reviewing existing flawed code measures judgement, which is the scarce skill once first drafts are cheap to produce.
What is a red flag in a code review interview?
Blocking on cosmetics while approving an unhandled failure path or a stale-cache bug. It predicts a slower review queue without a better product. Failing to ask clarifying questions about context the diff cannot contain is a milder version of the same problem.
How do I test mobile debugging skills?
Provide a crash report, a symbolicated stack trace, a log excerpt and a reproduction that only occurs on a slow network, then grade the hypothesis process rather than the fix — methodical narrowing, discarding theories against evidence, and knowing which tool answers which question.
Should I test for on-device AI knowledge?
Only if your roadmap includes it — and then explicitly. Ask how they would choose between on-device and hosted inference and what the app does when inference fails. Strong answers cover app size, thermal behaviour, latency budgets, cost per request and a designed degraded state.
Top comments (0)