Question 1

Design an offline-first mobile application for a ride-sharing app where drivers must accept trips and update status even with intermittent connectivity.

Accepted Answer

Structure the answer in layers: local data store (SQLite/Room or Core Data), a sync engine (conflict resolution strategy — last-write-wins vs. operational transforms vs. server-authoritative), a queue for outbound mutations (durable job queue with retry/backoff), and an optimistic UI layer. Define the conflict surface explicitly: what happens when two status updates collide? Discuss sync triggers (foreground, background fetch, push-triggered). Address partial sync and data expiry. Name tradeoffs between eventual consistency and UX correctness. What interviewers look for: Whether you treat offline as a first-class architectural concern rather than an afterthought. Interviewers want to see you define the conflict resolution model precisely, articulate what data must be durable vs. ephemeral, and show experience with real sync edge cases (e.g., server rejects a locally optimistic update). Staff signal: proactively scoping the failure modes before being prompted.

Question 2

You're designing a universal component library to be shared across iOS, Android, and React Native teams at a company with 40 mobile engineers. How do you approach this?

Accepted Answer

Frame the problem in three layers: API design (token-based design system, platform-agnostic contracts), implementation strategy (native per-platform vs. React Native bridge vs. multiplatform e.g. Compose Multiplatform or KMM), and governance (versioning, deprecation policy, contribution model, documentation). Discuss tradeoffs of native parity vs. lowest-common-denominator. Address distribution (private registry, versioned artifacts). Discuss adoption incentives and migration paths for existing components. What interviewers look for: Organizational thinking as much as technical thinking. Interviewers want to see you treat this as a platform product — with consumers, an API contract, and a roadmap — not just a shared codebase. Staff signal: raising governance, deprecation, and adoption strategy unprompted, and recognizing the political/cultural challenges of shared ownership.

Question 3

Walk through the architecture of the most complex mobile application you've designed or significantly shaped. What were the hardest architectural decisions and what would you do differently?

Accepted Answer

Choose a real example with genuine complexity (multi-team feature surface, real-time data, complex state). Structure the answer: constraints and requirements → chosen architecture (MVI, MVVM, VIPER, TCA, etc.) → specific hard decisions (e.g., state ownership across modules, navigation architecture, dependency injection strategy) → outcomes and retrospective. Be honest about what failed and why. Avoid vague language; name the patterns and frameworks. What interviewers look for: Depth of ownership and reflection. Interviewers are listening for evidence that you made real decisions under real constraints, not that you implemented a textbook pattern. Staff signal: demonstrating awareness of where the architecture created team-level friction or scaling problems, and showing you learned from it.

Question 4

Your iOS app's main thread is consistently showing 20ms+ frame times in Instruments during a scroll-heavy feed. Walk through your systematic debugging and resolution process.

Accepted Answer

Structure as a diagnosis workflow: start with Time Profiler to identify call stacks on the main thread, check for synchronous I/O or lock contention, inspect Auto Layout constraint solve times (use view debugger + layout pass count), examine cell reuse and off-screen rendering (Core Animation instrument, Offscreen Rendered). Discuss fixes in priority order: move work off main thread, prefetch and cache cell sizes, switch to manual layout if needed, use diffable data sources. Mention measurement before and after each change. What interviewers look for: Systematic, tool-grounded thinking rather than guessing. Interviewers want to see you reach for specific instruments (Time Profiler, Core Animation, Allocations) and interpret their output, not describe a generic 'move work to background threads' answer. Staff signal: knowing when to stop optimizing (diminishing returns, maintainability cost) and communicating tradeoffs to product.

Question 5

Explain how Android's rendering pipeline works from invalidate() to pixel on screen. Where can an app introduce jank and how do you identify and fix each class of problem?

Accepted Answer

Walk the pipeline: invalidate() → traversal (measure → layout → draw) → RenderThread → GPU composition via SurfaceFlinger. Explain where each phase can bloat: expensive onDraw(), deep view hierarchies inflating layout time, overdraw, and main-thread stalls blocking the RenderThread. Identify tools: Systrace/Perfetto for frame timing, GPU Overdraw overlay, Layout Inspector, StrictMode. Fixes: flatten hierarchies with ConstraintLayout, use hardware layers judiciously, move draw calls to Canvas with custom views, use RecyclerView prefetch. What interviewers look for: Genuine platform internals knowledge, not a surface-level 'avoid overdraw' answer. Interviewers want you to correctly name SurfaceFlinger, RenderThread, and the traversal phases. Staff signal: distinguishing between RenderThread-bound vs. main-thread-bound jank, which have different root causes and different fixes.

Question 6

Implement a thread-safe, memory-bounded LRU image cache in Swift or Kotlin without using any third-party libraries. The cache should support concurrent reads and serialized writes.

Accepted Answer

In Swift: use a doubly linked list + dictionary for O(1) get/put, wrap in a custom class with a concurrent DispatchQueue (using .barrier for writes, normal async for reads — reader-writer lock pattern). Add a byte-budget cap that evicts LRU entries when exceeded. In Kotlin: same structure with a ReentrantReadWriteLock or Kotlin coroutines + Mutex for write serialization, and a LinkedHashMap with removeEldestEntry. Discuss memory pressure callbacks (UIApplicationDidReceiveMemoryWarning / onTrimMemory). What interviewers look for: Ability to implement classic data structures correctly under platform-specific concurrency constraints. Interviewers are checking you understand reader-writer concurrency, not just that you know what an LRU cache is. Staff signal: bringing up memory pressure callbacks and byte-budget eviction proactively — treating it as production code, not an interview toy.

Question 7

Given a deeply nested JSON structure representing a dynamic UI configuration (server-driven UI), write a parser and recursive renderer in Swift or Kotlin that maps component types to native views, handles unknown types gracefully, and is extensible for new component types without modifying existing code.

Accepted Answer

Define a sealed class / enum hierarchy for component types with an 'unknown' fallback case. Parse JSON into the ADT using Codable (Swift) or Kotlin serialization with polymorphic deserialization. For rendering, implement a Visitor or Registry pattern: a ComponentRegistry maps type strings to factory functions, so adding new components is a registration call. Unknown types render a no-op or placeholder view. Discuss type discrimination (using a 'type' field), recursive child rendering, and how to handle rendering errors without crashing. What interviewers look for: Design pattern judgment and extensibility thinking, not just JSON parsing skill. Interviewers want to see you reach for the Open/Closed Principle correctly (registry/factory) rather than a switch statement that grows unboundedly. Staff signal: raising error isolation (one bad component shouldn't crash the tree) and testability of the registry.

Question 8

Compare Swift Concurrency (async/await + actors) and GCD. In what situations would you choose one over the other in a new iOS codebase, and what are the correctness pitfalls of actors that engineers commonly miss?

Accepted Answer

Contrast models: GCD is queue-based and manual (DispatchQueue, DispatchGroup, semaphores); Swift Concurrency is structured, with cooperative cancellation, task hierarchies, and actor isolation enforced by the compiler. Swift Concurrency wins on readability, cancellation propagation, and eliminating data races at compile time. GCD still has a role for interop with existing callback-based APIs and for fine-grained priority control. Actor pitfalls: reentrancy (awaiting inside an actor does not hold the lock — state can change), actor isolation doesn't prevent data races on reference types stored in actors, and MainActor overuse causing unnecessary hops. What interviewers look for: Deep correctness knowledge, especially actor reentrancy — most engineers know the happy path but miss the reentrancy hazard. Interviewers want to see you distinguish 'safe from data races' from 'free from logical races.' Staff signal: being able to give a concrete before/after code example of an actor reentrancy bug without prompting.

Question 9

You've identified that your company's mobile release process — currently a manual 2-day effort — is causing the team to ship only twice a month. How do you drive the initiative to automate it end-to-end?

Accepted Answer

Frame as a standard staff-level change initiative: quantify the cost (engineering hours, opportunity cost, delayed bug fixes), get alignment with mobile EM and adjacent teams (QA, DevOps). Design the target state: CI pipeline (Fastlane + GitHub Actions or Bitrise), automated test gates, artifact management (TestFlight/Play Internal Track), feature flags for decoupling deploy from release, and a rollout strategy. Create a phased migration plan with quick wins first. Identify stakeholders who will resist (e.g., QA team that relies on manual gates) and address their concerns proactively. What interviewers look for: Whether you treat this as a technical problem or a sociotechnical one. The automation tooling is the easy part; getting cross-functional buy-in and managing the transition is the hard part. Staff signal: proactively addressing the humans who will be disrupted by the change, not just the CI/CD architecture.

Question 10

A mid-level engineer on your team insists on using a third-party library for a capability you believe should be built in-house due to security and long-term maintenance concerns. How do you handle this?

Accepted Answer

Start by steel-manning the engineer's position — understand their reasoning fully before forming a response. Then structure the evaluation: security audit of the library (license, maintainers, CVE history), build-vs-buy analysis (lines of code, capability gap, maintenance burden), and risk framing (what happens if the library is abandoned or has a critical CVE). Bring data to the conversation, not just opinion. If you still disagree after honest evaluation, escalate the criteria not the decision — define with the team what bar the decision must meet, and let the criteria resolve it. Document the decision record either way. What interviewers look for: Technical humility and constructive conflict resolution. Interviewers want to see you distinguish 'I have seniority' from 'I have a better argument,' and that you empower engineers rather than overruling them. Staff signal: the decision-record framing — institutionalizing the reasoning so the team learns from it regardless of outcome.

Question 11

Tell me about a time you changed the technical direction of a mobile platform decision after initially advocating for a different approach. What caused you to change your mind and how did you handle it?

Accepted Answer

Choose a real example with genuine stakes. Structure: what you initially advocated and why → what new information or argument shifted your view → how you communicated the change of direction to stakeholders and the team → what you learned about your own technical biases. Be specific about what the new evidence was (benchmark results, a proof-of-concept, a colleague's argument you hadn't considered). Avoid making it sound like you were 'obviously right all along.' What interviewers look for: Intellectual honesty and ego management. Interviewers are evaluating whether you can update your beliefs publicly — a critical staff-level quality. Staff signal: demonstrating that your credibility actually increased by changing your position, because engineers trust people who update on evidence.

Question 12

Your company is considering adopting React Native or Flutter for new features to enable code sharing with the web team. You're asked to lead the technical evaluation. How do you structure it and what's your framework for making the recommendation?

Accepted Answer

Define evaluation criteria upfront with stakeholders: performance on target devices, hiring market (is there RN/Flutter talent?), interop with existing native code, long-term maintenance (framework maturity, community, corporate backing), and developer experience. Build a time-boxed proof-of-concept on a realistic feature (not a hello world). Benchmark on low-end devices — this is where cross-platform frameworks often fail. Evaluate the native interop story for platform APIs you rely on. Consider the organizational angle: does the web team actually want to share code, or is this a top-down mandate? Make the recommendation with explicit assumptions and the conditions under which it would be wrong. What interviewers look for: Structured decision-making and healthy skepticism about the premise of the question. Interviewers want to see you question whether 'code sharing' is actually the right goal (shared code ≠ shared team velocity). Staff signal: naming the low-end device performance test as a critical gate, and recognizing the organizational dynamics that will determine whether the cross-platform strategy actually delivers its promised value.

Staff Mobile Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Design an offline-first mobile application for a ride-sharing app where drivers must accept trips and update status even with intermittent connectivity.

2. You're designing a universal component library to be shared across iOS, Android, and React Native teams at a company with 40 mobile engineers. How do you approach this?

3. Walk through the architecture of the most complex mobile application you've designed or significantly shaped. What were the hardest architectural decisions and what would you do differently?

4. Your iOS app's main thread is consistently showing 20ms+ frame times in Instruments during a scroll-heavy feed. Walk through your systematic debugging and resolution process.

5. Explain how Android's rendering pipeline works from invalidate() to pixel on screen. Where can an app introduce jank and how do you identify and fix each class of problem?

6. Implement a thread-safe, memory-bounded LRU image cache in Swift or Kotlin without using any third-party libraries. The cache should support concurrent reads and serialized writes.

8. Compare Swift Concurrency (async/await + actors) and GCD. In what situations would you choose one over the other in a new iOS codebase, and what are the correctness pitfalls of actors that engineers commonly miss?

9. You've identified that your company's mobile release process — currently a manual 2-day effort — is causing the team to ship only twice a month. How do you drive the initiative to automate it end-to-end?

10. A mid-level engineer on your team insists on using a third-party library for a capability you believe should be built in-house due to security and long-term maintenance concerns. How do you handle this?

11. Tell me about a time you changed the technical direction of a mobile platform decision after initially advocating for a different approach. What caused you to change your mind and how did you handle it?

12. Your company is considering adopting React Native or Flutter for new features to enable code sharing with the web team. You're asked to lead the technical evaluation. How do you structure it and what's your framework for making the recommendation?

Study tips