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.
They work for hiring one engineer directly and for evaluating an agency, and they work if you cannot read code yourself, which is covered further down. If you’re earlier in the process, our guide to hiring app developers in India covers where to look and what to pay before you get to the interview.
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. A strong answer usually mentions catching it in a beta or staged rollout before it reaches everyone.
“How do you use AI coding tools, and what do you do differently because of them?” New in the last couple of years and genuinely revealing. The answer you want involves review and scepticism, particularly around dependencies a model suggests. Both “we don’t” and “constantly, it’s brilliant” suggest nobody has thought about it, and there are ownership implications that most teams have not considered yet.
“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?” Apple’s own figures put the rejection rate at roughly one in four submissions. 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. Our breakdown of why apps get rejected covers the guidelines behind each, so you can follow the answer without knowing the rules yourself.
“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 you are building anything medical or financial, where the wrong answer is a compliance problem rather than a code review comment.
“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, and the iOS development page covers what a full-team engagement looks like instead.
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. Our piece on Android device fragmentation explains the problem well enough to follow the answer.
“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. Ask what they would pick for an Indian audience specifically, since the version spread there runs wider than most Western teams expect.
“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.
“What does the Play Console tell you that your own analytics doesn’t?” Android vitals reports crash and ANR rate per device model from real installs, and Google’s thresholds turn a quality problem into a ranking one. Anyone who has run a live Android app knows this screen. Our Play Console guide covers where it sits.
“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, and the Android development page covers full-team delivery.
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, and the React Native company page covers the full-team version.
Interviewing a Flutter Developer
“How do you handle platform differences when Flutter draws its own widgets?” Flutter renders everything itself, which gives consistency across manufacturers and means your app can look subtly wrong on both platforms at once. Strong candidates talk about adaptive widgets, platform checks for navigation patterns, and knowing when to stop chasing native feel. Weak ones treat pixel-identical output as the goal.
“When have you written platform channel code?” The Dart layer covers most things until it does not, usually around hardware, background execution or a vendor SDK with no Flutter package. An engineer who can drop into Kotlin or Swift and bridge back is worth considerably more than one who declares the requirement impossible.
“How do you manage state, and why that choice?” Flutter’s state management debate is unusually noisy, with Provider, Riverpod, Bloc and several others all defensible. You are not testing which one they name. You are testing whether they can explain the tradeoff and whether they would use something different on a small app than a large one.
“What breaks when you upgrade Flutter?” Anyone maintaining a Flutter app for more than a year has been through a version bump that broke packages. The specifics matter less than whether the story exists at all.
If Flutter is the direction, our Flutter development page covers how those teams are staffed, and Flutter versus React Native covers the choice itself if it is still open. Flutter benches in India tend to run deeper than React Native ones, mostly because Google pushed it hard through the Indian training market, so these roles fill faster.
Interviewing an Agency Rather Than a Person
Different situation, and most question lists ignore it entirely. You are assessing a company as well as the engineers inside it.
“Can we interview the specific people who will do the work?” Ask first, because a no ends the conversation. You are being sold a resource pool, and the people on the call will not be the people on the project.
“Who else has worked on this account in the last year?” Rotation is the thing agencies do not volunteer. A project that has passed through four engineers has lost most of its context, whatever the headcount says.
“Will any part of this be subcontracted?” Ask in writing. Undisclosed subcontracting means every check you ran was run against the wrong company, and it is one of the risks worth naming explicitly before you sign anything.
“What is your attrition rate, and how long have these specific people been here?” The aggregate number matters less than the tenure of the people assigned to you.
“What did the last client who left receive?” A concrete answer means handover is a process. A vague one means it is an improvisation and you will be the one improvising. Our contract checklist covers what that handover should contain.
“Who fixes a store rejection, and is it billable?” At a one in four rate this is not hypothetical, and the answer should be that it sits inside the engagement.
The wider version of this, including how to check the company legally exists, is in choosing a mobile app development company.
What Good Candidates Ask You
The reverse direction carries as much signal and costs you nothing to observe.
Strong candidates ask who decides priorities, what the codebase currently looks like, whether there are tests, what happened to the last person in the role, and how success will be measured. Those are the questions of somebody imagining themselves doing the work.
Candidates who ask nothing, or only about salary and start date, are not necessarily bad. They are frequently just under-prepared. But nobody who is genuinely excited about a product fails to ask anything about it.
Take the awkward questions as a good sign. Somebody asking why your last developer left is doing the same diligence on you that you are doing on them, and that instinct is the one you want on your side once they are hired.
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. Install one, use it for ten minutes, and ask them what they would fix. A candidate who cannot criticise their own shipped work has either not thought about it since or was not really responsible for it. Ours is StockGenie, and we will happily tell you what we would do differently.
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.
One more thing that works without technical knowledge. Ask the same question twice, a week apart, phrased differently. Consistent answers come from experience. Inconsistent ones come from somebody constructing an answer in the moment, and you will hear the difference even if you cannot evaluate the content.
Be aware of a cultural pattern that catches American and European buyers. Direct disagreement is less comfortable in Indian professional settings, so “yes, we can do that” occasionally means “I have understood you” rather than a commitment. Ask questions that cannot be answered yes. “What worries you about this timeline” gets further than “can you hit this timeline”, and this is on our list of offshore risks because it is manageable rather than disqualifying.
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 choosing the platform is the more important question.
What seniority do we actually need?
Most teams ask for senior and need mid-level. Junior is good value on defined tickets with review. Mid-level suits owning a feature end to end. Senior earns its cost when there is nobody technical above them or the product does something genuinely hard. Our cost to hire guide covers what each band prices at in India.
Should we ask about their availability across our timezone?
Yes, and ask it as a number rather than a feeling. India runs nine and a half to twelve and a half hours ahead of the US, so overlap is bought with somebody’s evening. Ask who is shifting their day and whether it is sustainable, because a team quietly working late for six months does not stay the same team.
Before You Start Interviewing
Work out which stack you actually need first, because it changes who you should be talking to. If the platform decision is still open, Android or iOS first settles the native question on revenue and the cross-platform comparison settles the other one.
The hire app developers in India guide covers the arrangements, and if you are hiring locally instead, hiring an app developer in Pune covers a market where you can meet people in person.
We put every engineer through this before they meet a client, which is easy to claim, so ask us the questions and check the answers against the apps we have shipped. If you would rather skip the interviewing entirely and talk about the project, get in touch.
