Question 1

Design a ride-sharing app's real-time location tracking feature for the passenger side — the passenger sees the driver's car moving on a map in near real-time.

Accepted Answer

Start by clarifying update frequency requirements and battery/data constraints. Architect the data flow: driver app pushes location updates (WebSockets vs. long-polling vs. push notifications for background state), a backend fan-out layer, and the client receiving and rendering updates. On the client, discuss debouncing/throttling updates, interpolating position between updates for smooth animation (dead-reckoning), and handling the app moving to background (stop rendering, but maintain connection or use silent pushes). Address failure modes: what happens when the WebSocket drops? How do you reconcile stale state on reconnect? What interviewers look for: The interviewer wants to see that you can reason about mobile constraints (battery, background execution limits, network flakiness) as first-class design concerns, not afterthoughts. Strong candidates distinguish between foreground and background behavior and propose a smooth UX under degraded network conditions.

Question 2

Design an offline-first mobile app for a task management tool — users can create, edit, and delete tasks without connectivity, and changes sync when back online.

Accepted Answer

Define the local data layer (SQLite via Room/CoreData, or a document store), a sync queue that persists pending mutations, and a conflict resolution strategy (last-write-wins vs. CRDTs vs. server-authoritative merge). Walk through the sync lifecycle: optimistic local writes, background sync trigger (connectivity change + periodic job), and reconciliation on response. Address edge cases: delete-then-edit conflicts, partial sync failures, and how you surface sync status to the user without being annoying. Mention idempotency keys on mutations so retries are safe. What interviewers look for: Interviewers are testing whether you understand the full complexity of distributed state between client and server. They want to see you proactively raise conflict resolution — candidates who only describe 'save locally, sync later' without addressing conflicts are at mid-level, not senior.

Question 3

Walk me through how you would architect a large-scale feature module in a mobile app used by multiple teams. How do you enforce boundaries and prevent coupling?

Accepted Answer

Describe a modular architecture: feature modules with explicit public APIs, dependency injection (Hilt/Dagger on Android, or a service locator / Swinject on iOS) so modules don't import each other directly. Discuss how you'd use interfaces/protocols to invert dependencies. Explain your build graph structure and how you'd avoid circular dependencies. Address shared resources: a common UI kit module, a networking layer, and how feature modules consume these. Mention how you'd enforce boundaries via build tooling (module-level lint rules, Swift package access control, internal visibility modifiers in Kotlin). What interviewers look for: The interviewer wants evidence you've worked in a multi-team codebase and thought seriously about maintainability at scale. Specific tooling and access control mechanisms are the signal that separates real experience from theoretical knowledge.

Question 4

Your app's main feed scrolls with noticeable jank on mid-range Android devices. Walk me through your diagnostic and optimization process.

Accepted Answer

Start with profiling before optimizing: use Android GPU Profiler and systrace/perfetto to identify where frame budget is being exceeded — overdraw, layout inflation on the main thread, expensive RecyclerView bind calls, or Bitmap decoding. Describe fixes in order: flatten view hierarchies (ConstraintLayout, merge tags), move work off the main thread (async image loading, pre-computing item heights), use DiffUtil for smart RecyclerView updates, and implement view recycling correctly. For images, discuss memory caches and loading the right resolution for the target view size. Mention that you'd profile after each change to validate impact rather than optimizing blindly. What interviewers look for: The interviewer is checking whether you have a systematic profiling-first approach or whether you jump to guessing. Naming specific tools (Perfetto, GPU Profiler, Choreographer frame callback) and specific RecyclerView mechanisms shows hands-on experience.

Question 5

Explain iOS memory management in a Swift app. When would you use weak vs. unowned references, and what are the consequences of getting it wrong?

Accepted Answer

Explain ARC and the retain cycle problem. Use a concrete example: a view controller holding a closure that captures self — show why this creates a cycle and how [weak self] breaks it. Distinguish weak (optional, becomes nil when referencing object is deallocated) from unowned (non-optional, crashes if the object is already deallocated — use only when you're certain the referenced object outlives the closure). Walk through delegate patterns (always weak), closures in async callbacks, and timer retain cycles. Mention Instruments' Allocations and Leaks tool for detection. What interviewers look for: This tests genuine platform depth. Interviewers look for a crisp explanation of ARC, a correct distinction between weak and unowned with real examples, and awareness of the crash risk of unowned — not just reciting definitions.

Question 6

Describe how Android handles process death and how you ensure your app's state survives it correctly.

Accepted Answer

Explain that Android can kill background processes without warning to reclaim memory. ViewModel survives configuration changes but NOT process death. For process death survival, you need SavedStateHandle (in ViewModel) or onSaveInstanceState for transient UI state, and persistent storage (DataStore/SharedPreferences/Room) for anything else. Walk through a concrete scenario: user is filling a form, gets a call, app is killed, user returns — what's preserved? Discuss the difference between what should be persisted (user inputs) vs. what should be re-fetched (remote data). Mention WorkManager for deferrable background tasks that must survive process death. What interviewers look for: Many candidates confuse ViewModel lifecycle with full process death survival. The interviewer wants to see you clearly separate these two concepts and demonstrate you've actually dealt with this bug in production.

Question 7

Your team is deciding between React Native and native iOS/Android for a new app. How do you structure this decision?

Accepted Answer

Frame it as a set of tradeoffs rather than a universal answer. Factors favoring RN/Flutter: small team, shared business logic, heavy form/CRUD UI, web-leaning organization, faster iteration cycle. Factors favoring native: performance-critical UI (60/120fps animations, heavy list rendering), deep platform API usage (ARKit, health sensors, custom camera), separate platform-specialized teams. Discuss the hidden costs of cross-platform: bridge overhead (in RN specifically), debugging complexity across layers, keeping up with platform OS updates, and the risk of hitting the ceiling of what the framework supports. Ask about the org's mobile expertise and long-term maintenance capacity. What interviewers look for: Interviewers want to see structured tradeoff reasoning, not advocacy for one approach. Strong candidates acknowledge the org/team context matters as much as the technical factors, and they proactively name the failure modes of each path.

Question 8

How do you design a robust networking layer in a mobile app that handles authentication token refresh, retries, and cancellation cleanly?

Accepted Answer

Describe an interceptor/middleware pattern (OkHttp Interceptors on Android, URLProtocol or Alamofire RequestAdapter/Retrier on iOS) to handle token injection and refresh transparently to call sites. For token refresh, explain the synchronization problem: multiple concurrent requests can all 401 at once, triggering multiple refresh calls. Solve this with a mutex or a shared in-flight refresh observable (using a single refresh coroutine/flow or RxJava flatMap with share()). For retries, distinguish between idempotent (GET, safe to retry) and non-idempotent (POST) requests. For cancellation, tie request lifecycle to the calling scope (structured concurrency in Kotlin coroutines, async/await task cancellation in Swift). What interviewers look for: The simultaneous 401 refresh race condition is the key signal. Candidates who don't raise this have not built production-quality auth flows. Structured cancellation tied to lifecycle shows senior-level awareness.

Question 9

Tell me about a time you introduced a significant architectural change to a mobile codebase. How did you get buy-in, and what did the rollout look like?

Accepted Answer

Use STAR structure but go beyond the story: explain the technical problem precisely (not just 'it was messy'), articulate how you built the case (benchmarks, incident data, a prototype), how you got alignment from skeptical engineers or a PM whose roadmap was affected, and how you managed the incremental migration (strangler fig pattern, not a big bang rewrite). Be honest about what went wrong and what you'd do differently. Strong answers quantify impact: build time, crash rate, feature velocity. What interviewers look for: Interviewers are evaluating technical leadership, not just technical skill. They want to see influence without authority, pragmatic incrementalism over perfectionism, and self-awareness. Candidates who only describe the happy path signal low ownership.

Question 10

Describe a situation where you had a serious technical disagreement with a peer or tech lead. How did you handle it, and what was the outcome?

Accepted Answer

Pick a real disagreement with genuine stakes (library choice, data model design, release process). Show that you argued on evidence and principles, not seniority or stubbornness. Describe how you actively tried to understand the other perspective, what you did to de-escalate when it got heated, and how you reached resolution — whether you won, compromised, or conceded and why. The concede-and-commit story is often the strongest because it shows intellectual humility. What interviewers look for: This tests psychological safety and collaboration under disagreement. Interviewers are looking for evidence of intellectual humility, structured debate (data over opinions), and the ability to commit to a decision you disagreed with and execute it well.

Question 11

Implement a simple in-memory image cache with a max capacity that evicts the least recently used entry when full. Write this in Swift or Kotlin.

Accepted Answer

Implement an LRU cache using a LinkedHashMap (Kotlin's LinkedHashMap with accessOrder=true makes this clean) or a combination of a HashMap + doubly-linked list in Swift. In Kotlin: subclass or wrap LinkedHashMap, override removeEldestEntry or track manually. Ensure thread safety with a ReentrantLock or Mutex for concurrent access — this is the part most candidates skip. Discuss why NSCache on iOS is actually a reasonable real-world answer (automatic memory pressure eviction) but explain you can still implement it from scratch for the interview. Walk through get() touching recency and put() triggering eviction. What interviewers look for: The LRU structure itself is table stakes. Thread safety is the senior-level signal. Interviewers also want to see you connect the data structure to the real mobile use case (image caching, NSCache) rather than treating it as a purely academic problem.

Question 12

How do you design a testing strategy for a mobile feature that involves local persistence, a network call, and UI — end to end?

Accepted Answer

Describe a testing pyramid specific to mobile: unit tests for business logic and ViewModels/Presenters (using fakes or mocks for the repository layer), integration tests for the data layer (testing Room DAOs against an in-memory database, testing network layer with MockWebServer/WireMock), and UI tests (Espresso/XCUITest) for critical flows only due to their flakiness and slowness. Discuss the key design pattern that makes this possible: dependency injection so you can swap real implementations for fakes. Specifically call out testing the sync logic (offline queue) as the hardest part and worth targeted integration tests. Mention snapshot tests for UI regression if the team ships frequently. What interviewers look for: Interviewers want to see a pyramid-shaped strategy (most unit, fewer integration, fewest E2E) and the insight that testability is a design constraint, not an afterthought. Candidates who only describe UI tests or who can't explain how to test without hitting the real network are below senior level.

Senior Mobile Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Design a ride-sharing app's real-time location tracking feature for the passenger side — the passenger sees the driver's car moving on a map in near real-time.

2. Design an offline-first mobile app for a task management tool — users can create, edit, and delete tasks without connectivity, and changes sync when back online.

3. Walk me through how you would architect a large-scale feature module in a mobile app used by multiple teams. How do you enforce boundaries and prevent coupling?

4. Your app's main feed scrolls with noticeable jank on mid-range Android devices. Walk me through your diagnostic and optimization process.

5. Explain iOS memory management in a Swift app. When would you use weak vs. unowned references, and what are the consequences of getting it wrong?

6. Describe how Android handles process death and how you ensure your app's state survives it correctly.

7. Your team is deciding between React Native and native iOS/Android for a new app. How do you structure this decision?

8. How do you design a robust networking layer in a mobile app that handles authentication token refresh, retries, and cancellation cleanly?

9. Tell me about a time you introduced a significant architectural change to a mobile codebase. How did you get buy-in, and what did the rollout look like?

10. Describe a situation where you had a serious technical disagreement with a peer or tech lead. How did you handle it, and what was the outcome?

11. Implement a simple in-memory image cache with a max capacity that evicts the least recently used entry when full. Write this in Swift or Kotlin.

12. How do you design a testing strategy for a mobile feature that involves local persistence, a network call, and UI — end to end?

Study tips