Mobile Development
Mobile Engineering: FAANG Interview Prep
The mobile engineering bar at Google, Meta, Apple, and Uber is set by engineers who built the infrastructure billions of people use daily. A senior Android role at Google requires demonstrating that a candidate can design the architecture for a feature used by 2 billion users, debug a performance regression in a 5-million-line codebase, and make principled decisions between competing frameworks - all on a whiteboard or shared editor in 45 minutes. The mental models covered across this course are the exact vocabulary these interviews test.
- **Google's Android interview process** for senior engineers includes a 'mobile system design' round where candidates design features like Google Photos offline sync or Google Maps tile caching. Candidates who explicitly discuss client-server data contracts, cache invalidation strategies, and battery optimization pass at significantly higher rates than those who only discuss UI architecture.
- **Meta's mobile interview loop** (documented in their engineering blog) evaluates candidates on coding (Kotlin/Swift data structures), system design (design Instagram Reels), and behavioral rounds. The system design round specifically asks candidates to 'design for 1B users on 2G networks' - battery and data constraints are explicit requirements.
- **Uber's mobile engineering blog** documents that their senior mobile interview process was redesigned in 2021 to weight architecture questions more heavily after analysis showed that candidates who passed coding rounds but failed performance debugging were most likely to cause production regressions in their first 6 months.
Mobile Architecture Design Questions
Senior mobile interviews at Google, Meta, Apple, and Uber commonly open with: 'Design the architecture for [Instagram / Google Maps / a real-time chat app].' The expected structure: define data flow (local state, server sync, cache invalidation), choose persistence strategy (SQLite/Room, Core Data, Realm), define navigation architecture, handle offline-first requirements, and discuss testability. The answer is evaluated on whether the candidate structures thinking before coding and can reason about tradeoffs explicitly.
The most common mistake in mobile architecture questions is jumping to code before establishing data flow. Interviewers at FAANG report that candidates who draw a quick box-and-arrow diagram showing ViewModel <-> Repository <-> DataSource in the first 2 minutes consistently outperform candidates who start typing code. The diagram forces agreement on requirements and reveals hidden assumptions before they become code.
In an offline-first mobile architecture, why does the Repository pattern use local storage as the single source of truth rather than fetching from the network on every request?
Mobile Performance Debugging
Performance questions test ability to diagnose and fix jank (dropped frames), slow startup, and excessive memory use. The canonical diagnosis flow: Instruments (iOS) or Android Profiler -> identify the bottleneck category (CPU, memory, I/O, network) -> isolate the specific call -> apply the fix. Common root causes: main thread I/O (Core Data fetches on main thread), over-rendering (UITableView/RecyclerView cells recreating expensive objects), image decode on main thread, and layout passes triggered by incorrect constraint priorities.
Android RecyclerView performance checklist: setHasStableIds(true) + override getItemId() to prevent unnecessary rebinds; DiffUtil.ItemCallback for list diffing (O(n) diff vs. notifyDataSetChanged which redraws all visible items); RecyclerView.RecycledViewPool sharing between nested horizontal/vertical lists; Prefetch via LinearLayoutManager.setInitialPrefetchItemCount() for nested RecyclerViews.
Why does synchronous image loading on the main thread cause frame drops in a scrolling list?
Mobile System Design
Mobile system design questions at senior/staff level ask candidates to design complete systems: 'Design the Instagram Stories feature' or 'Design WhatsApp's message delivery system.' Unlike backend system design, mobile system design must address the client-server contract explicitly: what data does the client need, in what format, how is it cached, what are the error states, and how does the UI handle each state (loading, error, empty, content). The answer must also consider battery and data usage - not just latency and throughput.
A common mistake in mobile system design is treating the mobile client as a thin API consumer. Senior answers define the client's responsibility explicitly: local state machine for each feature, conflict resolution policy for offline changes, retry strategy for failed mutations (exponential backoff with jitter), and the exact data format negotiation between client and server. Candidates who mention protobuf vs. JSON tradeoffs, pagination cursor design, and push notification delivery receipts stand out.
Why must mobile system design explicitly address battery and data usage, unlike typical backend system design?
Mobile Tradeoffs and Decision Frameworks
Staff-level mobile interviews culminate in open-ended tradeoff questions: 'When would you choose React Native over native development?' or 'Should this feature be implemented on the client or the server?' The expected answer structure: restate the decision criteria, evaluate each option against those criteria, make a recommendation, and acknowledge what the recommendation trades away. Interviewers value explicit uncertainty ('it depends on X, if X is Y then I'd choose A, if X is Z then I'd choose B') over false confidence.
The most valued skill in senior mobile interviews is not knowing the right answer - it is structuring ambiguous questions into solvable decisions. When asked 'Should we paginate this list?', strong candidates respond: 'How many items does the typical user have? What is our p99 item count? What is the current load time? A list under 500 items usually does not need pagination if cells are lightweight.' This quantitative framing of design decisions distinguishes principal-level thinking from senior-level thinking.
Mobile FAANG interviews test trivia about API names and framework details
Senior mobile interviews evaluate systems thinking: can the candidate diagnose a performance problem using profiling tools, design an offline-first architecture with correct data flow, and make explicit tradeoff decisions with engineering rationale
Meta's mobile interview loop explicitly states that candidates are evaluated on 'problem decomposition, communication of tradeoffs, and ability to handle ambiguity' - not recall of specific SDK methods. Knowing UITableView APIs is table stakes; knowing why those APIs work the way they do and when to use alternatives is what staff-level questions probe
In a mobile staff engineering interview, what distinguishes a strong answer to 'when would you choose Flutter over React Native?' from a weak one?
Key Ideas
- **Architecture design questions** expect a data flow diagram before code: Repository pattern with local DB as single source of truth, ViewModel observing reactive queries, offline state machine, and conflict resolution policy.
- **Performance debugging** follows: profile with Instruments/Android Profiler -> identify bottleneck category (CPU/memory/I/O) -> isolate specific call -> fix with async loading, DiffUtil, view holder optimization, or offscreen rendering elimination.
- **Tradeoff questions** are evaluated on structure: define criteria, evaluate each option against criteria, make a recommendation with explicit acknowledgment of what it trades away. Blanket 'X is always better' answers are disqualifying at staff level.
Related Topics
Mobile interview preparation builds on all prior mobile topics:
- Mobile Architecture at Scale — Modularization, feature flags, A/B testing, and crash reporting are the exact topics covered in mobile system design interview questions at senior/staff level
- React Native — The React Native vs. Flutter vs. Native tradeoff question is one of the most common mobile staff interview questions, requiring deep understanding of RN architecture internals
Вопросы для размышления
- An interviewer asks: 'Design the notification system for a messaging app that must deliver messages within 2 seconds on iOS and Android, even when the app is in the background.' Walk through the full answer including APNs/FCM integration, local notification scheduling, and the data flow when the user taps a notification.
- Instruments shows a React Native app spending 40ms on the JS thread for every scroll event in a large contact list. The app uses the old architecture (bridge). What are the specific causes and what are the migration steps to the New Architecture that would fix them?
- A mobile team is debating whether to implement search filtering on the client (filter cached data locally) or the server (new API endpoint per filter combination). Define the decision criteria and walk through which factors favor each approach.