Skip to content
Aethel

AI interview prep for mobile developers

Mobile interviews ask about things web developers rarely face: releases you cannot roll back in a minute, devices you do not control, flaky networks, and crashes you only see in reports. An AI screen will probe how you found a crash, shipped a risky release, kept data in sync offline and made an app feel fast on an old phone. Here are the questions, two worked answers, and the habits that weaken mobile answers.

Practice mobile questions free

Entrevista con IA para desarrolladores iOS y Android: esta guía en español

What AI screens ask mobile developers

  1. A crash you could not reproduce

    “Tell me about a crash you could not reproduce at first. How did you find the cause?”

    Listening for: Crash reports and breadcrumbs, the device or OS pattern, and how you confirmed the fix.

  2. Releases and rollouts

    “How did you ship a risky change in a mobile app?”

    Listening for: A staged rollout, remote flags, a kill switch, and what you watched.

  3. Offline and sync

    “Describe how your app handled being offline and then syncing.”

    Listening for: Conflict rules, what the user saw, and a real bug the design caused or prevented.

  4. Speed on real phones

    “What made your app slow on older phones, and what did you change?”

    Listening for: Startup time, dropped frames or memory, measured on a named device.

  5. Platform changes

    “How did you handle a new OS version or store policy that broke something?”

    Listening for: How early you tested, what broke, and how many users it reached.

  6. Old app versions

    “How did you change an API while old app versions were still in use?”

    Listening for: Version tracking, forced or gentle updates, and how long old versions lived.

  7. Native or cross-platform

    “Tell me about a choice between native code and a cross-platform framework.”

    Listening for: The team, the features, the cost, and what you would choose again.

Worked example: a crash after taking a photo

Each example shows a weak and a strong answer to the same question. The “With Aethel's rules” lines apply Aethel's published scoring rules, one concrete example of how an AI interview can judge an answer.

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “Tell me about a crash you could not reproduce at first. How did you find the cause?”

Weak answer

“There was a crash that was hard to reproduce, so I looked at the crash logs, found the issue and fixed it. It was a null pointer problem. After the fix the crash went away and the app was more stable.”

Why it is weak: It skips everything that made the crash hard. No app, no number of users affected, no device pattern, and "a null pointer problem" is a symptom, not a cause. "More stable" is not a result.

With Aethel's rules: Situation 1, reasoning 1, result 1: 3 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“I worked on the Android app of a regional bank, about 600,000 monthly users. After a release, crash-free sessions dropped from 99.7 to 98.9 percent, and nobody on the team could reproduce it. The reports showed every crash was on Android 13, mostly on two phone models with 4 gigabytes of memory, and the breadcrumbs showed users had just come back from the camera after photographing a check. The system had killed our process while the camera was open, and when it restored the deposit screen, the screen read a field that had only ever existed in memory. I reproduced it with the developer option that destroys activities in the background, moved the deposit draft into saved state so it survived the process being killed, and added that option to our pre-release test checklist. I considered catching the missing field and sending users back to the start of the deposit, which would have stopped the crash in a day, but they would have lost their photos and the amount they typed. The next release brought crash-free sessions back to 99.8 percent, and completed check deposits rose about 6 percent.”

Why it is strong: It turns "could not reproduce" into a pattern: one OS version, low-memory phones and one user path. The cause is the real mechanism (the process killed with state held only in memory), the reproduction is deliberate, and the quick fix is rejected for what it would cost users. The result is measured twice: stability and completed deposits.

With Aethel's rules: Situation 2, reasoning 2, result 2: 6 of 8 points, which is 87 on Aethel's fixed scale. A real score can differ.

What comes next: Expect: what else in the app kept state only in memory? Saying you searched other screens for the same pattern shows the fix went beyond one bug.

Worked example: a new payment screen behind a remote flag

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “How did you ship a risky change in a mobile app?”

Weak answer

“For risky changes we use feature flags so we can turn them off if something goes wrong. We also test a lot before releasing and do beta testing. That way we catch most problems before users see them.”

Why it is weak: A description of tools, not a release. It does not say what was risky, what the flag protected, what was watched or what happened, and "catch most problems" cannot be checked.

With Aethel's rules: Situation 0, reasoning 1, result 0: 1 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“At a ride-hailing company in Mexico, about 1.2 million monthly riders on iOS, I led the move of our payment screen to a new payment provider. A broken payment screen is worse on mobile than on the web, because a fix can take days to reach users through app review and slow updates. So I shipped the new screen two weeks early behind a remote flag that was off, with the old screen kept in the app as the fallback. Once that release reached most riders, we turned the new screen on for 1 percent of riders in one city and watched payment success and support tickets for three days, then 10 percent, then everyone over two weeks. At 10 percent, success dropped for one card network, and I turned the flag off for that network within minutes, without a new release, while the provider fixed their side. When the rollout finished, payment success was 0.4 points higher than before, and we removed the old screen two releases later.”

Why it is strong: It explains why mobile releases need more care than web ones, then shows each safeguard doing its job: a dark launch, staged percentages, named metrics, and a kill switch used on a real problem. The result includes the cleanup, which many answers forget.

With Aethel's rules: Situation 2, reasoning 2, result 2: 6 of 8 points, which is 87 on Aethel's fixed scale. A real score can differ.

What comes next: Expect: what happened to riders on app versions too old to have the flag? Saying how long the old screen had to stay, and how you knew, answers it.

Common mistakes in mobile answers

  • Treating app releases like web deploys. You cannot roll back an app in a minute. Say how flags, staged rollouts or settings from the server stood in for that.
  • A crash rate without context. Say crash-free users or sessions, for which platform and which versions, before and after.
  • Forgetting old app versions. Some users never update. Say how your API change kept them working, or how you moved them along.
  • Testing only on your own phone. Name the slow or low-memory devices you tested on, or the device data you used to choose them.
  • Offline as an afterthought. If your app can lose its connection, describe what the user saw and how conflicting changes were settled.
  • Framework debates with no decision. Native versus cross-platform is only interesting with your team size, your features and what you would choose again.

Numbers worth having ready

An interviewer places a case by its numbers. Find these for each of your cases before a mobile interview; rounded is fine:

  • Crash-free users or sessions, by platform, before and after a fix
  • Cold start time on a named low-end device
  • The share of users on the oldest app and OS versions you still supported
  • App download size, and how a release changed it
  • The steps of a staged rollout, and how long each lasted
  • Monthly active users, and the share on each platform

Practice mobile questions free

Pick a level, type an answer to each question, and read the quick check after each one. Free, no account, nothing saved, and not a score.

Questions from mobile developers

Will an AI interview ask about both iOS and Android?

It usually follows your answers. Say early which platforms you have shipped on, and choose cases from the one you know best. If you have worked on both, a case where they behaved differently is strong material.

Should I mention Swift, Kotlin, Flutter or React Native?

When the choice matters to the story, such as a bug that only existed on one side of a bridge, or a feature the framework could not do. Otherwise the decision and the result matter more than the language.

I build apps alone as an independent developer. Does that count?

Yes. App store numbers are real: downloads, ratings, crash rates, reviews that changed your plans. Say what you decided and how you measured it, as you would at a company.

How do I talk about a rejected app store submission?

Like an incident: what the reviewer flagged, what you changed, how long it cost, and what you do now to avoid it. A rejection you learned from is a useful case.

More developer guides

Start from the developer guide, Prepare for an AI interview as a developer, or read what Aethel's software engineering interview covers.