Mobile engineer role-specific interview questions

As asked

Your company is starting a new mobile app and asks whether to use React Native, Flutter, or two native codebases. Walk me through the decision.

Sample answer outline

Drivers: team composition (web-heavy team favours RN, fresh team can pick either), platform-specific features (heavy use of camera, AR, Bluetooth, background work all push toward native), performance ceiling (graphics-heavy games or 120fps interactions need native), and long-term maintenance (one codebase is cheaper to evolve, two codebases give better platform fidelity). Real answer: most consumer apps ship fine on RN or Flutter; native is right when the app IS the device experience (audio editor, camera app, AAA game). The cost of cross-platform is a lower platform-fidelity ceiling, not raw performance.

Expect these follow-ups

• What is the migration story from RN to native if you outgrow RN?
• When does Flutter beat React Native?
• What is the team size where one native codebase per platform is cheaper than RN?

As asked

Your mobile app is 80MB on install and you need to get it under 30MB. Walk me through where you would look.

Sample answer outline

Profile the bundle. Common culprits: bundled assets (PNG vs WebP/HEIF, redundant resolutions, video files that should be remote), unused frameworks linked statically, debug symbols and dSYMs left in the release build, multiple architectures shipped where the store would have stripped them. On iOS, app thinning and on-demand resources cut by 30 to 50 percent for asset-heavy apps. On Android, App Bundle (AAB) plus dynamic feature modules. Move rarely used flows to download-on-demand. Verify before and after with the actual store install size, not the IPA/APK on disk.

Expect these follow-ups

• Why is install size different from download size?
• What is your strategy for fonts and localised assets?
• When does shipping a smaller binary actually move retention?

As asked

Your app needs to sync data in the background every 15 minutes. How do you do this without getting killed by the OS or trashing the battery?

Sample answer outline

On iOS: BGAppRefreshTask via BGTaskScheduler. The OS schedules these based on user behaviour, not the 15 minute interval. You request, the system grants when convenient. On Android: WorkManager with PeriodicWorkRequest, constraints for network and charging state. Both platforms aggressively kill foreground services that hold resources. Design for opportunistic sync: when granted a window, do the most valuable work first (incremental sync, not a full refresh), respect network type (Wi-Fi only for large transfers), and tell the user what last synced and when.

Expect these follow-ups

• How do you test background work that the OS schedules?
• What is your fallback if the OS never schedules the task?
• When is silent push the better option?

As asked

Your iOS app has a cold launch time over five seconds on older devices. How would you diagnose and reduce it?

Sample answer outline

Measure first with Instruments and real devices, separating pre-main time from work after application launch. Common wins include reducing dynamic frameworks, delaying non-critical SDK initialisation, moving network and database work off the launch path, and making the first screen render from cached state. The answer should mention that AppDelegate and scene setup often become dumping grounds for analytics, feature flags and dependency graph construction. Optimisation should preserve correctness by defining what the user must see at first interactive frame. Candidates trip up by optimising isolated functions without proving they affect launch metrics.

Expect these follow-ups

• What is pre-main time and why can dynamic frameworks hurt it?
• Which launch work is safe to defer?
• How would you prevent launch regressions in CI?

As asked

A React Native app works in debug builds but crashes on launch for 8 percent of Android users after release. Walk me through your triage.

Sample answer outline

Start from crash reporting segmented by app version, device, OS, ABI, and startup path. Release-only points toward minification, ProGuard or R8 rules, native library packaging, Hermes bytecode, missing permissions, or environment-specific config. Reproduce with a release build locally and on a representative device, then use symbolicated native stacks and JavaScript source maps. Mitigation may be a staged rollout halt, remote config kill switch, or rollback depending on store constraints. Strong answers include what telemetry they wish had existed before the release.

Expect these follow-ups

• How do you symbolicate a Hermes stack trace?
• What would you include in a mobile release checklist?
• How do staged rollouts change the incident response?