Mobile Developer interview questions

Mobile interviews go after the things that only break on a phone: a flaky network, a killed process, a release you can't take back. Expect a coding round, a platform round and a design round, and expect every one of them to ask what happens when the user walks into an elevator. Here's what they ask and what a good answer sounds like.

The process

What happens in each round

  1. 1

    Recruiter screen

    What happens

    Which platforms and frameworks you've shipped on, whether you've owned a release end to end, and whether your stack matches theirs closely enough to be worth a technical round.

  2. 2

    Coding round

    What happens

    Data structures and clean code, often in Swift or Kotlin rather than a generic language. Some teams skip puzzles and ask you to build a small screen that loads and shows a list from an API.

  3. 3

    Platform deep-dive

    What happens

    How well you know iOS or Android under the framework: lifecycle, threading, memory, background work, permissions, and how you debug a crash you can't reproduce.

  4. 4

    Mobile system design

    What happens

    Whether you can design a feature like a chat screen or a photo feed on the client side, including caching, pagination, offline behaviour, and how the app talks to the backend.

  5. 5

    Behavioural and team fit

    What happens

    How you work with designers, product managers and backend engineers, how you handle a bad release, and how you push back when a request would hurt the app.

Questions you're likely to get

1.Walk me through what happens to an app when the user switches away and the system kills it in the background.

Why they ask

Process death is where half of real mobile bugs live. They want to know you've seen a user come back to a blank screen or lost form input and fixed it.

How to answer

  • Name the platform hooks: scene phases or app delegate callbacks on iOS, onSaveInstanceState and SavedStateHandle on Android
  • Separate what must survive (a half-typed message, scroll position, the current screen) from what can be refetched
  • Explain where you persist it and how you restore it on relaunch
  • Mention how you test it, such as the Don't keep activities developer option or killing the app from Xcode
2.How would you design a screen that has to work offline and sync when the connection comes back?

Why they ask

Offline support separates developers who've shipped to real users from those who've only tested on office wifi.

How to answer

  • Make the local database the source of truth, using Core Data, SwiftData or Room, and have the UI read from it
  • Queue writes locally with a status so the user sees their change right away
  • Sync with a background job such as WorkManager or BGTaskScheduler and retry with backoff
  • Say how you'd handle a conflict when the server copy changed too, and admit the tradeoff you'd pick
3.A crash is spiking in Crashlytics after a release, and you can't reproduce it. What do you do?

Why they ask

Every mobile team lives through this. They want calm, ordered steps, not a guess.

How to answer

  • Read the symbolicated stack trace and group by device, OS version and app version
  • Check what changed in that release and whether the crash lines up with a feature flag
  • Halt the staged rollout or turn off the flag before you understand it fully
  • Add breadcrumbs or logging if the trace isn't enough, then write a test that locks in the fix
4.How do you find and fix a memory leak?

Why they ask

Leaks cause slow screens and out-of-memory crashes that users blame on the whole app.

How to answer

  • Name the tools: Instruments and the memory graph debugger in Xcode, or the Android Studio memory profiler and LeakCanary
  • Describe a common cause, such as a closure capturing self strongly or a listener holding an activity
  • Explain the fix, for example a weak reference or unregistering in the right lifecycle method
  • Tell a short story about one you actually found
5.Which architecture do you use for a screen, and why?

Why they ask

They're checking whether you can keep a codebase testable as it grows, and whether you have opinions you can defend.

How to answer

  • Name what you use, such as MVVM with a unidirectional data flow, or TCA on iOS
  • Explain where state lives and how the view observes it through Combine, Flow or StateFlow
  • Say how it makes the screen testable without a device
  • Admit when it's overkill, like a simple settings screen
6.Design the client side of an infinite photo feed.

Why they ask

This is the classic mobile system design prompt. It touches networking, caching, memory and scrolling performance at once.

How to answer

  • Use cursor-based pagination from the API and load the next page before the user hits the bottom
  • Recycle cells with LazyColumn, a collection view or FlatList, and downsample images to the size on screen
  • Cache images in memory and on disk, and cancel requests for rows that scroll off
  • Cover pull to refresh, empty and error states, and what the user sees on a slow connection
7.How do you decide between native and a cross-platform framework for a new project?

Why they ask

Teams argue about this constantly. They want a judgement call, not loyalty to one camp.

How to answer

  • Ask what the app needs: heavy camera, Bluetooth or animation work leans native
  • Weigh team skills and how many people will maintain it
  • Mention the cost of bridging to native modules when the framework doesn't cover something
  • Give a clear recommendation for a concrete example
8.Tell me about a release that went wrong and what you changed afterwards.

Why they ask

You can't hotfix a phone instantly. They want to see that bad releases taught you process.

How to answer

  • Set the scene briefly: what shipped and what broke for users
  • Say what you did in the first hours, including pausing the rollout or flipping a flag
  • Name the process change, such as staged rollouts, a release checklist, or more UI tests in CI
  • Own your part without blaming QA or the backend
9.How do you make sure an app is accessible?

Why they ask

Accessibility is often a legal and brand risk, and many mobile developers ignore it until a complaint lands.

How to answer

  • Test with VoiceOver and TalkBack yourself, not only with a scanner
  • Set content descriptions and labels, and group elements so a screen reader makes sense
  • Support Dynamic Type and font scaling, and check colour contrast
  • Make touch targets big enough and don't rely on colour alone
10.A designer hands you a screen that will be slow or awkward to build. What do you do?

Why they ask

Mobile developers work closely with design, and pushback done badly sours the team.

How to answer

  • Ask what the design is trying to achieve for the user before objecting
  • Show the cost concretely, for example with a quick prototype on a real device
  • Offer an alternative that uses a platform-native pattern
  • Agree on the tradeoff together and write it down
11.What's your approach to testing a mobile app?

Why they ask

UI tests on mobile are slow and flaky, so they want to see sensible priorities.

How to answer

  • Lean on unit tests for view models and business logic
  • Keep a small set of UI tests with XCTest or Espresso for the flows that make money, like sign-in and checkout
  • Run them in CI on every pull request, using Fastlane or a hosted build service
  • Mention snapshot tests for layouts that break across screen sizes
12.How would you handle a request to add push notifications to our app?

Why they ask

Push touches permissions, the backend, and user trust. It shows whether you think past the code.

How to answer

  • Cover the plumbing: APNs and Firebase Cloud Messaging, device tokens, and sending them to the backend
  • Ask for permission at a moment the user understands, not on first launch
  • Handle deep links when a notification opens the app from a cold start
  • Raise how often to send them, since too many drive uninstalls

Mistakes that sink good candidates

Talking only about the framework you like and dismissing the other platform

Describing features you built without ever mentioning crashes, testing or rollout

Blaming App Store review, QA or the backend for every past problem

Designing a system with no answer for a slow or missing network

Need more Mobile Developer interviews to prep for?

HeroApply applies to Mobile Developer jobs that match you, every day. 236 jobs are open today.

Find Mobile Developer jobs