Interview questions

Mid-Level Mobile Engineer Interview Questions

Mid-level mobile interviews test whether you can own features end-to-end — not just write working code, but make sound architectural decisions for a screen, flow, or module without constant guidance. Expect to be probed on platform internals (lifecycle, memory, threading), UI performance, and how you navigate real trade-offs like offline support, battery impact, or cross-platform vs. native. You'll need concrete examples from shipped work, not theoretical answers.

What to expect

A typical loop runs 4–5 rounds: one coding screen (data structures applied to a mobile-adjacent problem, or a small feature implementation), one or two platform-depth interviews covering lifecycle, rendering, networking, and storage, one system/feature design focused on a single app feature (e.g., a feed, image cache, or offline sync), and one behavioral round. Some companies add a take-home. At mid-level, you're expected to write bug-free code under mild time pressure, explain why you'd use a specific pattern without being prompted, and demonstrate that you've debugged real production issues — not just built toy features.

12 questions, with how to answer them

1. Coding

   1. Implement a least-recently-used (LRU) cache in your primary mobile language. Walk through both the data structure choice and thread safety.

   How to answer: Use a LinkedHashMap (Android/Java/Kotlin) or a combination of a Dictionary + doubly-linked list (Swift). Explain O(1) get/put via the hash map and O(1) eviction via the linked list. For thread safety, show a simple lock/synchronized wrapper or discuss a read-write lock if reads dominate. Mention that on mobile you'd layer this under a disk cache (DiskLruCache or URLCache) for a real image pipeline.

   What they look for: Whether you nail the classic structure without hints, whether you proactively surface thread safety without being asked, and whether you connect the abstract problem to a real mobile use-case (image caching, API response caching). A mid-level candidate shouldn't need to be walked to the linked list insight.

2. Coding

   2. Given a deeply nested JSON payload from an API, write a parser/model layer that is null-safe and handles missing or malformed fields gracefully without crashing.

   How to answer: In Kotlin use data classes with nullable types and Moshi/Gson with lenient parsing or custom adapters; in Swift use Codable with optional properties and a custom init(from:) that provides defaults. Walk through which fields truly must be non-null vs. which can degrade gracefully. Show how you'd surface a partial parse error to a caller (sealed Result type or throwing function) rather than silently swallowing it.

   What they look for: Practical JSON-handling skill rather than toy parsing. Interviewers want to see null-safety discipline, awareness of crash risks from force-unwrapping or non-optional model fields, and a pattern for communicating errors up the call stack — all of which surface in production.

3. Platform Internals — Android

   3. Explain the Activity and Fragment lifecycle in enough detail to debug a bug where data is lost on screen rotation.

   How to answer: Walk through onCreate/onStart/onResume/onPause/onStop/onDestroy and the fact that rotation destroys and recreates the Activity. Explain ViewModel surviving rotation via the ViewModelStore, onSaveInstanceState for lightweight transient UI state (scroll position, text field contents), and when to use both together. Distinguish process death (ViewModel gone, must restore from SavedStateHandle or persistent storage) from rotation (ViewModel survives).

   What they look for: Precise understanding of the lifecycle state machine — not just the names but what triggers each callback and what's still alive. Mid-level engineers must debug rotation/process-death bugs independently; interviewers probe whether you know the ViewModel/SavedState boundary without prompting.

4. Platform Internals — iOS

   4. What is the iOS view controller lifecycle and how do viewDidLoad, viewWillAppear, and viewDidAppear differ in terms of when it's safe to do what?

   How to answer: Explain that viewDidLoad fires once after the view hierarchy loads from nib/storyboard or programmatic layout — safe for one-time setup, adding subviews, configuring constraints. viewWillAppear fires every time before the screen is visible — safe for refreshing data or showing/hiding elements that depend on app state. viewDidAppear fires after the animation completes — safe for starting animations or triggering camera/audio that requires the view to actually be on screen. Mention the paired disappear callbacks for cleanup.

   What they look for: Whether the candidate understands the 'fires once vs. every appearance' distinction and can correctly place code — a common source of duplicate observers, missed refreshes, or janky animations in production iOS apps.

5. UI Performance

   5. Your list/feed is dropping frames. Walk me through how you'd diagnose and fix it.

   How to answer: Start with profiling tools: Android Studio CPU Profiler / Systrace / GPU rendering bars; Xcode Instruments Time Profiler / Core Animation. Identify if jank is from overdraw, heavy work on the main thread (layout inflation, image decoding, synchronous network), or cell reuse bugs. Fixes: move image decoding off the main thread, pre-size cells to avoid dynamic layout recalculation, use view recycling correctly (RecyclerView ViewHolder pattern / UICollectionView prefetching), consider DiffUtil/snapshot diffing for smart updates rather than notifyDataSetChanged.

   What they look for: A structured debugging approach rather than a list of guesses. Interviewers want to see that you open a profiler first, can read the output, and then target the specific bottleneck. Naming the actual tools is important — it signals you've done this in production.

6. Networking & Data

   6. Design the networking and caching layer for a feature that must work offline and sync when connectivity returns.

   How to answer: Describe a local-first architecture: writes go to local DB (Room/SQLite or Core Data/Realm) immediately and are reflected in the UI, a background sync worker (WorkManager on Android, BGTaskScheduler/URLSession background task on iOS) flushes the queue when online. Discuss conflict resolution strategy (last-write-wins, server-wins, or user-prompted merge). Mention exponential backoff for retries, distinguishing read cache (HTTP cache-control headers + ETags for GET requests) from write queue (mutation log). Address what 'sync complete' means in the UI.

   What they look for: Whether the candidate can reason about eventual consistency and user-visible state at a feature level. Many mid-level engineers know 'cache stuff locally' but can't articulate conflict resolution, queue durability, or how the UI reflects pending vs. committed state.

7. Architecture & Patterns

   7. Compare MVC, MVVM, and MVI/Unidirectional Data Flow for a non-trivial screen. When would you pick each?

   How to answer: MVC: simple, but on iOS/Android the controller/Activity balloons and becomes hard to test. MVVM: ViewModel exposes observable state, View is thin and reactive — good for most CRUD screens; testable because ViewModel has no View dependency. MVI: single immutable state + explicit intents + reducer — best for screens with complex state machines (multi-step forms, real-time updates) where you need deterministic, replayable state; higher boilerplate. Mention that 'MVVM' without a reactive binding library often collapses back to MVP in practice.

   What they look for: Genuine architectural taste, not pattern-name dropping. A strong candidate explains what problem each pattern solves and can cite a screen type where each is the right or wrong choice. They should note testability as a first-class concern, not an afterthought.

8. Memory & Performance

   8. What causes memory leaks in mobile apps and how do you detect and fix them?

   How to answer: On Android: static references to Context, non-static inner classes (especially anonymous Runnables/Listeners) holding Activity references, LiveData observers not removed, bitmaps not recycled in older APIs. On iOS: strong reference cycles (delegates should be weak, closures capturing self strongly). Detection: LeakCanary (Android) / Xcode Memory Graph Debugger and Instruments Allocations (iOS). Fix by auditing ownership — use weak/soft references, unregister listeners in onDestroy/deinit, and use Instruments to confirm the heap object count drops after navigating away from a screen.

   What they look for: Production debugging experience, not textbook knowledge. Interviewers listen for whether you've actually run LeakCanary or the Memory Graph tool, and whether you understand why the leak happens (ownership model) rather than just what to search for.

9. Feature Design

   9. Design the client-side architecture for a photo feed (think Instagram main feed): infinite scroll, image loading, and skeleton loading states.

   How to answer: State model: sealed class/enum covering Loading, Content(items), LoadingMore, Error, Empty. Pagination: cursor-based preferred over page-number (handles inserts). RecyclerView/UICollectionView with a PagingSource (Paging 3) or manual append-trigger at scroll threshold. Image loading: Glide/Coil (Android) or Kingfisher/SDWebImage (iOS) with memory + disk LRU cache, placeholder and error drawables, thumbnail-first strategy. Skeleton: show shimmer placeholder cells of fixed height while first page loads, not a spinner. Discuss prefetching the next page when user is 70% through the current one.

   What they look for: Ability to turn a product requirement into a concrete layered design covering state management, pagination strategy, and image lifecycle — all in one coherent answer. Interviewers watch for whether the candidate models loading states explicitly or treats them as an afterthought.

10. Testing

    10. How do you write a meaningful unit test for a ViewModel that fetches data from a repository?

    How to answer: Inject a fake/mock repository (interface-based DI — Hilt/Koin on Android, constructor injection on iOS). Use TestDispatcher (Kotlin Coroutines) or XCTestExpectation (Swift async) to control async execution. Assert on the emitted states: initial Loading → Success(data) or Error(message). Show at least three test cases: happy path, network error, empty response. Avoid testing implementation details (private methods); test observable state transitions. Mention that a good test fails for the right reason — it shouldn't break when you refactor internals.

    What they look for: Whether the candidate understands test isolation, fake vs. mock semantics, and how to handle async in tests without Thread.sleep hacks. A mid-level engineer should write tests that are readable and resilient, not just tests that pass.

11. Cross-Platform Awareness

    11. Your team is debating adding React Native or Flutter for a new feature. What questions do you ask and what factors drive the decision?

    How to answer: Questions to ask: What's the team's existing skill set? Does the feature need deep platform API access (Bluetooth, camera background processing, NFC)? What are the performance requirements (60fps animations, large lists)? What's the maintenance horizon? Arguments for: faster iteration if team knows JS/Dart, single codebase, good for CRUD forms and content screens. Arguments against: native feel in animations/gestures is harder, bridging native APIs adds complexity and lag, debugging across the JS/native boundary is painful, hiring a specialist is harder. Conclude that hybrid works well for greenfield content features, poorly for performance-critical or device-API-heavy features.

    What they look for: Intellectual honesty about trade-offs rather than advocacy for one side. Interviewers want to see that you evaluate based on constraints (team, feature, timeline) rather than technology preference, and that you understand where cross-platform frameworks leak abstraction.

12. Behavioral

    12. Tell me about a time you found and fixed a bug that was hard to reproduce. How did you track it down?

    How to answer: Use STAR: Situation (what feature, what symptoms — e.g., crash only in production, only on specific devices/OS versions), Task (your responsibility to investigate), Action (how you narrowed it — crash logs via Firebase Crashlytics, adding structured logging, building a reproduction harness, bisecting recent commits, using a device lab or specific emulator config), Result (fix shipped, monitoring confirmed reduction). Be specific about the debugging tools and reasoning steps, not just 'I searched StackOverflow.'

    What they look for: Real debugging methodology and ownership. Interviewers distinguish candidates who've debugged real production issues from those who've only written tutorial code. Specificity about tools (Crashlytics, logcat, lldb, Instruments) and the deductive process is what makes the answer credible.

Study tips

• Profile before you optimize: pick one app you've shipped (or any open-source app) and run it through Android Studio Profiler or Xcode Instruments until you can read a flame graph and identify the actual bottleneck — interviewers will ask how you've diagnosed performance issues and 'I used a profiler' without details isn't enough.
• Know your reactive/async primitive cold: whether it's Kotlin Coroutines + Flow, RxJava, Swift async/await, or Combine — be able to explain its error handling, cancellation, and threading model without pausing. Interview questions about lifecycle bugs are almost always secretly questions about async code holding references longer than expected.
• Build one small feature end-to-end with offline support: implement an offline-capable list (local DB write, background sync, conflict handling). You'll understand the hard parts — queue durability, UI state for pending items — that interviewers probe in design questions but that are invisible until you've implemented them.
• For behavioral questions, prepare three substantial 'I owned it' stories from your shipped work — one debugging a production issue, one where you disagreed with a technical decision and how you resolved it, one where you improved code quality proactively. Mid-level behavioral bars are about demonstrated ownership, not leadership of people.
• Review the platform's memory ownership model specifically: for iOS, understand ARC, strong/weak/unowned, and why closures create cycles; for Android, understand the GC roots, why non-static inner classes leak, and how WeakReference is and isn't a solution. Leak questions come up at mid-level far more often than at junior or staff.