A mobile app lives a harder life than a web page. It has to work on cheap and expensive phones alike, loses signal in lifts and metro tunnels, gets killed by the operating system when memory runs short, and every fix waits for store review and for users to update. Mobile interviews probe exactly those conditions, so preparing for them pays off more than learning one more UI library.

What a mobile developer's fortnight involves

Many app teams ship on a release train: a build is cut on a fixed schedule, tested, then rolled out to users in stages. Here is a plausible fortnight for an Android developer at a consumer company:

  • a crash spike since the last release, limited to low-memory phones from one manufacturer, traced to full-resolution images decoded inside a scrolling list;
  • a new reorder screen built against a mocked response, because the backend endpoint is still in review;
  • a discussion with product about which actions can be queued offline and which must fail clearly;
  • watching crash-free rates as the rollout widens, ready to halt it.

This role is most often mixed up with two others. A frontend developer can ship a fix in minutes and every user gets it on the next page load; you cannot, so old app versions stay in use for months and every API change has to keep them working. A full stack developer owns the server and the database; a mobile developer usually consumes an API and owns everything on the device: local storage, background work, permissions, memory and battery.

Native or cross-platform: how postings split and how to choose

Postings fall into four tracks. They overlap less than tutorials suggest, because each has its own build system, debugging tools and failure modes.

TrackWhat postings nameWhere you see it most
Native AndroidKotlin, Jetpack Compose (XML views in older code), coroutines and Flow, Room, Hilt, WorkManager, sometimes Kotlin MultiplatformConsumer apps, fintech, commerce, GCCs with large apps
Native iOSSwift, SwiftUI (UIKit in older code), Swift concurrency, Core Data or SwiftDataThe same employers, often with smaller iOS teams
FlutterDart, Riverpod or Bloc, platform channelsStartups, agencies, services firms building for clients
React NativeTypeScript, React, Expo, native modulesTeams that already run React on the web

Three rules make the choice easier:

  • Follow the users. Most phones in India run Android, so many Indian consumer products build Android first and staff it more heavily. The live data in this guide counts how often current postings name Android, iOS, Flutter and React Native, so check the split before committing.
  • Hardware decides iOS. Xcode runs only on macOS, so day-to-day iOS work needs a Mac whichever framework you use. Without regular access to one, start with Android, or with Flutter targeting Android.
  • Native skills travel outwards. Cross-platform developers who can read a Gradle error, an Xcode signing failure or a native crash log are the ones teams rely on, because that is where cross-platform projects get stuck. If you pick Flutter or React Native, learn one native platform well enough to debug it.

Skills that matter after the first screen works

  • Lifecycle and state. Know what survives rotation, backgrounding and process death on your platform: ViewModel versus saved state on Android, scene phases and state restoration on iOS, AppLifecycleState in Flutter. Many bugs users call random, such as a form that empties itself, start here.
  • Offline-first data. The UI reads from a local database (Room, SwiftData or Core Data, Drift or another SQLite layer in Flutter) while a sync layer talks to the server. Panels want to hear about a queue of pending writes, retries with idempotency keys, and a conflict rule you chose on purpose.
  • Performance and battery. Cold start, dropped frames in long lists, oversized images and work on the main thread. Block Android's main thread for a few seconds and the system reports an ANR (Application Not Responding). Both platforms restrict apps that keep waking the device, so prefer push through FCM or APNs to polling, and batch background work.
  • Crash monitoring. Firebase Crashlytics or Sentry, readable stack traces (upload R8 mapping files and dSYMs with every build), and Android vitals in Play Console for crash and ANR rates. Know your crash-free rate the way a backend developer knows their error rate.
  • Release management. Signing keys, build variants, Play testing tracks and staged rollouts, TestFlight and phased release on the App Store, the review guidelines, and a forced-update or kill-switch flag for the release that goes wrong.

Differentiators panels notice: accessibility with TalkBack, VoiceOver and large font sizes; UPI payment flows; support for Indian languages; and UI tests with Espresso, Compose testing or XCUITest.

Levels, titles, and how employers differ

ExperienceCommon titlesWhat you are trusted with
0–2 yearsAndroid Developer, iOS Developer, Flutter Developer, SDE IScreens and bug fixes in one platform's language and UI toolkit, with networking, JSON and a local database; someone else owns releases
3–5 yearsSDE II, Senior Android or iOS EngineerWhole features with their analytics events, tests and flags; turns on release duty and crash triage; negotiating API contracts with backend teams instead of accepting whatever arrives
6+ yearsSDE III, Staff, Lead Mobile Engineer; Mobile Architect at services firmsArchitecture and module boundaries, the shared component library, build times, the release process, and keeping Android and iOS consistent

At the junior end, one app you can explain in detail, ideally published, does more than any certificate. Employers shape the rest: product companies with large apps run separate Android and iOS teams, often with platform groups for builds and performance. Startups tend to hire one or two people for both platforms, which is where Flutter and React Native are common. Services firms put you on client apps, sometimes several a year, trading depth for variety. GCCs maintaining a global brand's app often bring strict release processes and accessibility requirements.

How mobile interviews run, and what to practise

The usual rounds

After a recruiter screen, and sometimes an online test, expect a fundamentals round on your platform and its language: Kotlin null safety and sealed classes, Swift value and reference types, or Dart's async model. Then comes a live build of 60 to 120 minutes, typically a paginated list from a JSON endpoint with pull-to-refresh, empty and error states, and a detail screen; interviewers watch your structure and whether you handle failures without being asked. Senior candidates also get a mobile system design round (offline sync, image caching, push handling, modularisation) and a hiring manager conversation about a release that went wrong.

Questions worth rehearsing

  1. A user is halfway through a long form, rotates the phone, then switches to a UPI app to pay, and the OS kills your app in the background. What survives when they return, and how?
  2. Find the leak: a screen registers a location listener in onStart and never removes it, or a timer's closure captures self strongly. Fix it, and say how LeakCanary or Xcode's memory graph debugger would have shown it.
  3. Load a profile and an order list from two endpoints in parallel, show them together, and cancel both if the user leaves the screen. (async inside viewModelScope, Swift's async let, or Future.wait in Dart.)
  4. A list of 2,000 products with images stutters on a low-end phone. What do you measure first, and with which profiler?
  5. Design attendance capture for teachers in schools with patchy network. Where do unsynced records live, how do retries avoid duplicates, and what happens when two teachers edit the same register offline?
  6. Walk through MVVM in your last codebase: who owns navigation, where validation lives, and how one-off events such as a snackbar avoid replaying after rotation.
  7. Yesterday's release doubled the crash rate and the traces are obfuscated. What do you do in the next hour? (Halt the rollout, check the mapping uploads, segment by device and OS version, flip a remote flag, then hotfix.)
  8. How would you cut cold start time? (Defer SDK initialisation, keep disk and network work off the path to the first frame, use Baseline Profiles on Android, and measure before and after.)

What your mobile resume has to prove

Say which platform and which part of the app you owned, the scale in terms you are allowed to share, and what changed because of your work. If the app is public, link its store listing. Treat the figures below as illustrations, not targets:

  • Example: Rebuilt checkout in Jetpack Compose around a single ViewModel-driven UI state, replacing three Fragments; crash-free users on checkout rose from 98.9% to 99.8% over two releases.
  • Example: Added an offline order queue (Room, WorkManager, client-generated idempotency keys) to a field-sales app used by about 1,500 agents; duplicate orders from retries fell to zero.
  • Example: Cut iOS cold start from 2.6 s to 1.4 s by deferring three SDK initialisations and lazy-loading the feed module, measured with Instruments and MetricKit.

What weakens a mobile resume:

  • Android, iOS, Flutter and React Native listed at equal strength after two years. Lead with the platform you would be interviewed on.
  • "Published apps" that are store-listed tutorials, untouched for years.
  • Nothing about releases, crashes or performance, which is what separates a mobile engineer from someone who has built screens.
  • Only older tools, such as AsyncTask (deprecated since Android 11), with no coroutines or Compose work even in side projects.

A realistic route in, and where it leads

Pick one track and go deep before adding a second:

  • Android: Kotlin, Compose, coroutines and Flow, Retrofit, Room, Hilt, WorkManager, then testing.
  • iOS: Swift, SwiftUI with enough UIKit to read older screens, async/await, URLSession, SwiftData or Core Data, and Instruments.
  • Flutter: Dart, layout and widgets, one state-management approach, and platform channels for the native parts.

Then ship something to a store. Signing, store listings, privacy declarations and review feedback are what tutorials skip and panels ask about. Both stores charge for developer accounts, so check current fees first.

Projects that hold up in an interview:

  1. An offline-first expense or stock tracker with background sync, a conflict rule you can defend, and tests around the sync logic.
  2. A cricket-score or transit app with pagination, image caching, deep links and push notifications, with Crashlytics or Sentry wired in and notes on what you measured.
  3. A small published utility with a real changelog. A few hundred users give you staged rollouts, crash reports and reviews to talk about.

React Native developers can move into web frontend roles, native developers who want to own the API can grow towards full stack work, and generalist software engineer roles value what mobile teaches: backward compatibility, careful releases and respect for constrained devices.

Where to look and what to do next