Most interview question lists for mobile developers are quiz sheets. What is the Activity lifecycle, explain ARC, what does useEffect do. A candidate can memorise all of it in an evening and still write software that falls apart in production.
The questions below are different. Each one is hard to answer without having shipped something and watched it break, which is the only thing you are really screening for.
Key Takeaway: Stop asking what things are and start asking what went wrong. Every engineer who has carried an app in production has a story about a release that failed, and they tell it immediately and with feeling. A candidate whose projects all went smoothly has either not shipped much or is managing your impressions.
The Questions That Work for Any Stack
“Tell me about a release that went badly.” The single most useful question on this page. You are listening for specifics: what broke, how they found out, what they changed afterwards. Vague answers or a claim that nothing has ever gone wrong is the answer.
“What is in your codebase that you would do differently now?” Engineers who think about maintainability answer this readily and often at length. Engineers who write code and move on have nothing to say. There is no wrong answer except silence.
“How do you find out your app is broken before users tell you?” You want crash reporting, alerting thresholds, and some notion of a metric they watch. Somebody who relies on store reviews to discover problems has not operated an app, only built one.
“Walk me through a pull request you were proud of.” Then ask what the reviewer pushed back on. Candidates who have worked with real review discipline describe it naturally. Those who have always worked alone tend to reveal that here.
“What would you need from us to be productive in week one?” Strong candidates ask about API documentation, environment setup and who decides priorities. Weak ones say they will figure it out, which sounds accommodating and means they have not thought about it.
Interviewing an iOS Developer
“What is the last App Store rejection you dealt with?” Roughly a fifth of submissions get rejected. Anyone who has genuinely shipped has hit guideline 4.2 on minimum functionality, a privacy label mismatch, a missing account deletion flow, or the Sign in with Apple requirement. They will describe it with visible irritation. A perfect record means they have not shipped much.
“When would you reach for UIKit instead of SwiftUI?” You want a considered answer about finer control, complex collection views, or supporting older iOS versions. A candidate who says SwiftUI always, or UIKit always, is reciting a preference rather than making a judgement.
“How do you keep sensitive data off the device?” Listen for Keychain, encrypted Core Data, and awareness that crash reports and analytics can capture things they should not. This matters enormously if your product touches health or payment data.
“How do you test something the simulator cannot reproduce?” Camera behaviour, biometrics, memory pressure on older hardware and background suspension all need real devices. Somebody who has only used the simulator will not know what is missing from it.
If those questions land well, our hire iOS app developers in India page covers how we screen for the same things before putting anyone in front of a client.
Interviewing an Android Developer
“How do you keep background work alive on a Samsung or Xiaomi device?” This is the highest-signal Android question there is. OEM battery managers kill work that runs perfectly on a Pixel, and users report it as your app being broken. Engineers who have shipped to real users answer immediately. Those who have only tested on a Pixel do not know the problem exists.
“How do you decide the minimum API level to support?” The right answer involves your analytics rather than a number they always use. Each level supported downward carries a cost, so it should be an evidence-led decision with a tradeoff attached.
“What happens when Google raises the target API requirement?” It happens annually, and apps that miss the deadline stop reaching new users on current devices. A candidate who treats this as routine maintenance has operated an app. One who has never encountered it has not.
“How do you profile a memory problem that only appears on cheap hardware?” Loading full-resolution images into a list or leaking an Activity reference passes review on a modern phone and gets your app killed on a 2GB device. You want somebody who profiles rather than assumes, because these problems do not reproduce on good hardware.
Our hire Android app developers in India page goes into the fragmentation testing side in more depth.
Interviewing a React Native Developer
“Have you migrated an app to the New Architecture?” This separates engineers who have maintained React Native from those who have only started fresh projects on it. The Fabric and TurboModules migration caught a lot of teams badly, and having been through it is worth a great deal.
“When did you last write a native module, and why?” React Native covers most needs through packages, but the ceiling arrives the moment you need something no package provides. An engineer who can drop into Swift or Kotlin and bridge it back is a different proposition from one who stops at the JavaScript layer and calls the requirement impossible.
“Expo or bare workflow, and when would you switch?” Both are correct in different situations. What you are testing is whether they can articulate the tradeoff rather than defend a habit.
“How do you handle a library that has been abandoned?” Every long-running React Native project accumulates dependencies that stopped being maintained. Candidates who have carried an app for years have forked something, vendored something, or ripped something out. Those who have not will not have considered it.
The hire React Native developers in India page covers a genuine advantage here, which is that your own React web engineers can review this work properly. That changes the risk of an offshore hire more than any interview question does.
Questions That Waste Everyone’s Time
Trivia with a lookupable answer. If it is in the documentation, testing recall of it tells you nothing about judgement.
Algorithm puzzles unrelated to mobile work. Reversing a binary tree predicts very little about whether somebody can ship a stable app.
Take-home exercises longer than about two hours. They measure who has free evenings rather than who is good, and strong candidates with jobs simply decline them.
Asking for a portfolio without opening it. If you are not going to install the app, do not ask for the link.
Scoring the Interview Without a Technical Background
Plenty of founders hire a first mobile engineer with nobody technical to assess them. It is harder but not hopeless.
Ask the questions above and grade on specificity rather than correctness. Strong candidates give concrete answers with names, numbers and consequences. Weak ones stay general.
Ask them to explain a technical decision to you as if you were not technical. Anybody who genuinely understands something can do this. Anybody hiding behind vocabulary cannot.
Then insist on a short paid pilot on real work, because two weeks of actual pull requests tells you more than any interview will. If a vendor resists that, the resistance is your answer.
Frequently Asked Questions
How many candidates should we interview?
Three to five for a single role. Fewer and you have no comparison. More and you are usually avoiding a decision rather than gathering information.
Should we use a take-home test?
Generally no. A live session where requirements change mid-exercise gives you better signal in less time, and does not filter out good candidates who have jobs and families.
Can we interview through an agency’s account manager?
You can, and you should refuse to. Interview the engineer who will do the work. A vendor unwilling to arrange that is selling you a resource pool and will staff the project with whoever is free.
What if we cannot assess the technical answers ourselves?
Grade on specificity, ask them to explain decisions in plain language, and lean on a short paid pilot rather than the interview alone. Our guide on how to hire app developers in India covers the wider process around this.
How do we compare candidates across different stacks?
You mostly should not. Decide the stack first based on your product and your existing team, then compare candidates within it. Comparing a Swift engineer against a React Native engineer usually means the platform decision has not been made yet, and that is the more important question.
Before You Start Interviewing
Work out which stack you actually need first, because it changes who you should be talking to. The hire app developers in India guide covers the arrangements, and if the platform decision is still open, the cross-platform comparison is the place to settle it.