October 13, 2026·6 min read
Mobile hiring has a shape problem. You cannot ship an app inside an hour, the simulator is not the device, and the thing you are really buying is how someone behaves over months of small releases to users who never read release notes.
So most teams fall back on two things that do not predict much: an algorithm puzzle, and a walk through a portfolio app the candidate built alone, with no deadline, no legacy and no second developer.
Building something alone and joining a codebase four people wrote are different skills. Only one of them appears in a portfolio.
The useful interview is inside an existing project, with bugs that only exist on real devices and real networks.
Not architecture opinions. The things that generate one-star reviews are narrower than that:
Each of those is testable in under twenty minutes on a project that already exists.
The setup. A listener, observer or callback registered when a screen opens and never removed. Navigate in and out a few times and memory climbs. On Android it might be a listener on a long-lived object; on iOS a strong reference cycle in a closure.
Ask: memory climbs every time this screen is opened. Find out why.
Strong looks like: they reproduce it deliberately, open and close the screen several times, and take a measurement rather than reading code hopefully. They talk about ownership: who holds a reference to whom, and when it is released. They fix it and prove the fix with the same measurement.
Weak looks like: scattering weak references until the number stops climbing, with no account of what was holding what.
Why it works: lifecycle ownership is the single most mobile-specific skill there is, and it is invisible in a portfolio app that has four screens and is never left open for an hour.
The setup. A form or a list that loses what the user typed or where they had scrolled, when the screen is rotated or when the process is reclaimed in the background.
Ask: fill this form in, rotate the device, and then make the behaviour right.
Strong looks like: they know the difference between configuration change and process death, and they test both, including the simulated low-memory case rather than only rotation. They put state where it survives, and they can say which state deserves to survive at all, because restoring everything is its own bug.
Weak looks like: disabling rotation. It is a real product decision in some apps and a quiet admission of defeat in most.
Why it works: this is the most common user-visible mobile defect and the one that users describe as "the app is buggy" without ever being able to reproduce it on request.
The setup. Device network throttled to something that resembles a train: high latency, intermittent loss. The app has no timeout policy worth the name, shows a spinner forever, and fires the same request again on every retry tap.
Ask: use the app on this connection for two minutes, then tell me what you would change.
Strong looks like: they distinguish slow from offline and treat them differently. They talk about timeouts, cancellation when a screen is dismissed, retry with backoff, and what the user sees while waiting. The strongest candidates notice a stale response overwriting a newer one, which is the bug nobody finds on a fast connection.
Weak looks like: adding a loading indicator and calling it handled.
Why it works: your users are on trains, in lifts and on rural mobile data. Nothing about a desk connection prepares an app for that, which is why this has to be tested rather than discussed.
The setup. The app is backgrounded, something changes underneath it, a revoked permission, an expired token, a deleted file, and it crashes or hangs on resume.
Ask: here is a crash report from a user who reopened the app the next morning. Reproduce it.
Strong looks like: reproducing before fixing. They read the report properly, including which thread and which version, and they recreate the conditions deliberately rather than hoping. Then they fix the resume path and say what they would log so the next occurrence is self-explanatory.
Weak looks like: a defensive null check at the crash site, which stops the crash and leaves the user staring at an empty screen with no explanation.
Why it works: most mobile bug reports arrive like this: secondhand, with no reproduction steps. Watching someone turn a vague report into a reproducible case is the closest thing to watching the actual job. The same instinct is what how to assess debugging skill, not just coding ability is built around.
Four rows, the same for every candidate:
None of those rows is "knows the newest UI framework". That is visible in ten minutes of watching them work, and it changes every two years anyway.
These tasks need a project that builds, a device or emulator, a throttled network and a real crash report. A whiteboard carries none of that, and a take-home gives you the result without the process.
EasyEnv gives the candidate a Linux box with the Android toolchain, the project, an emulator and the leak, the lost state and the retry bug already committed. The recipe is identical for every candidate, so the bugs do not drift between interviews and comparison is fair. The session is recorded, so you can see whether they measured memory or guessed.
The honest limit, since it matters here more than usual: iOS builds need macOS, so for an iOS role this setup covers the project, the API layer and the reasoning, while the device-level work stays on your own hardware. For Android, and for cross-platform work in React Native or Flutter, the whole exercise runs on the box.
Also plainly: this is a 45 to 60 minute session that needs a mobile engineer to review, and for a role that is one screen a quarter inside a larger product, two tasks are enough.
Stop walking through the portfolio app. Put a leak that survives the screen, state lost on rotation, a train-grade network and a crash on resume in front of the candidate.
If you only run one, run the slow network. Everything an app gets wrong in the real world is hiding behind a connection that is present but bad.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Give an analyst clean tables and a clear question and nearly everyone looks capable. Here are four tasks on a deliberately messy database, duplicated rows, nulls that mean two different things, a timezone that moves a month boundary, and a number that disagrees with finance.
PHP hiring still runs on framework questions while the failures are operational and silent. Here are four tasks on a running Laravel application, a queue nobody noticed had stopped, a listing page that issues hundreds of queries, a migration that ran on one server, and uploads that vanish behind a load balancer.
Read more
.NET gives you so much for free that the mistakes hide inside the framework rather than in the code under review. Here are four tasks on a running service, a deadlock under load, a captured dependency, a query that drags the whole table into memory, and a background worker that died quietly.
Read more
