Mobile system design · 17 min
Mobile system design interview: how the round is scored
How a mobile system design round runs, the seven things a senior answer covers, a worked offline sync example, and how Senior and Staff are scored.
Senior and Staff loops · 12 min read
Meta mobile mock interview: a practice loop for 2026
A Meta mobile mock interview based on what Meta's careers pages publish: a 45-minute screen, a full loop, six practice prompts, follow-ups and a scoring rubric.
A Meta mobile mock interview is easiest to plan from the two things Meta states on its careers pages: the first technical screen is a 45-minute conversation with an engineer, and the full loop that follows is made up of several different conversations. The detail beyond that sits in downloadable guides and in what your recruiter tells you.
This page summarizes what Meta publishes, with links, then gives you a mock loop for a senior mobile engineer: a timed screen, three loop rounds, six practice prompts with follow-ups, and the rubric I use to write up a candidate. It works for iOS and Android candidates; where the answer differs by platform, I say so.
The prompts are practice prompts I wrote. They are generic mobile engineering problems, not questions Meta has asked. This site never attributes a question to a named company, because loops change and nobody outside the company can verify such a list.
What Meta publishes about its interviews
As described on Meta’s careers pages for software engineering candidates:
- The initial technical screen is a 45-minute conversation with an engineer, designed to assess technical skills.
- The full loop is designed to assess technical skills, let hiring managers get to know you, and show you what building at Meta looks like. It consists of several different conversations.
- Each page links a downloadable preparation guide for that stage.
The web pages themselves do not list the round types, their lengths, or anything mobile-specific. The downloadable guides may say more; I have not quoted them here because I only cite what I could read on the pages linked below. Download the current guide yourself when you get your invitation, and ask your recruiter which rounds your loop includes and whether any design round is mobile-focused.
What that means for a mobile candidate
A 45-minute screen with an engineer is short. If the time goes to coding, which is the common shape of a technical screen, you have very little slack: every minute spent unsure of the problem is a minute not spent solving it. Mobile engineers who are used to thinking with an IDE open tend to lose time here, so the first thing this mock trains is speed of framing.
For the loop, the phrase “several different conversations” means you should expect variety: some coding, some design, some conversation about your past work. In a mobile design conversation, the interviewer usually cares about the product experience as much as the architecture: what the user sees while things load, fail, or sync.
The mock loop at a glance
The 45-minute screen length is Meta’s; everything else in this table is a practice shape I chose, not a published Meta format. Real loops differ by team and level.
| Round | Time | Format | Focus |
|---|---|---|---|
| Screen | 45 min | Shared editor or document | Two short coding problems, clear communication |
| 1. Coding | 45 min | Shared editor or document | Correctness and speed with tests |
| 2. Coding with a mobile twist | 45 min | Shared editor or document | State, concurrency, lifecycle |
| 3. Mobile product design | 45 to 60 min | Drawing tool | A feature end to end, client first |
| 4. Past work | 45 min | Conversation | Impact, conflict, growth |
Run the screen alone first, a few days before the rest. If it goes badly, fix that before booking the loop, because in most hiring processes the screen decides whether there is a loop at all.
The screen: speed without silence
Prompt 1: collapse notification bursts
Given a list of notifications sorted by time, each with a type and a timestamp, collapse any run of the same type within sixty seconds of the previous one into a single entry with a count.
Follow-ups: What if the list is not sorted? What if it arrives as a stream instead of a list?
Prompt 2: first unread message in a paged thread
Messages in a thread are stored in pages; you can fetch a page by index and each message has a read flag. Reads are expensive. Find the first unread message, assuming everything after the first unread message is also unread.
Follow-ups: What is the number of page fetches in the worst case? What changes if the assumption does not hold?
What a strong screen shows: both problems framed in under three minutes each, the second recognised as a binary search over pages, code that runs on the first walk-through, and test cases spoken aloud. Getting through both with time left for follow-ups is the goal; a perfect first problem and an unstarted second is a weaker result than two solid ones.
In a short screen, silence is the most expensive thing you can do. If you are thinking, say what you are thinking about. That is not filler; it is the evidence.
Rounds 1 and 2: coding
Prompt 3: a thread-safe event batcher
Analytics events are logged from many threads. Write a batcher that collects events and flushes them to a sender when either fifty events are queued or five seconds pass since the first queued event, whichever comes first.
Follow-ups: What happens to queued events when the app goes to the background? What if the send fails? How do you test the timer without waiting?
What a strong answer shows: a single owner for the buffer (an actor on iOS, a single-threaded dispatcher or a mutex on Android), a timer that starts on the first event and is cancelled on a size flush, a flush on backgrounding using the platform’s short background window, a retry policy that does not drop or duplicate, and an injected clock in tests.
This is the round where the “mobile twist” matters. A server engineer writes a good batcher. A mobile engineer writes one that survives the app being backgrounded and the process being killed.
Round 3: mobile product design
Prompt 4: a feed with infinite scroll
Design the client for a feed with infinite scroll, mixed content types (text, photos, video) and pull to refresh.
Follow-ups: How do you paginate, and what does the cursor look like? What does the user see when page three fails to load? How do you keep memory flat after scrolling five hundred items? A new content type ships next month. What happens on old app versions?
What a strong answer shows: cursor-based pagination rather than offsets, a local cache so the feed opens instantly, prefetching a page ahead, cell or composable reuse with media paused off screen, a clear error state per page rather than for the whole feed, and an unknown-type fallback so old clients skip content they cannot render. The best answers start with what the user should experience and work backwards to the architecture.
Prompt 5: video upload from a phone
Design uploading a two-minute video from the phone, with the user free to leave the app while it uploads.
Follow-ups: Where do you compress, and what does it cost the battery? What happens if the network drops at 80 percent? How does the user know it worked?
What a strong answer shows: on-device compression with a stated trade-off, a resumable upload split into chunks, background transfer that survives suspension (background URLSession on iOS, WorkManager on Android), a persisted job record, and a notification or in-app state when the upload finishes or fails.
For a staff candidate, I would also ask who owns the upload service contract and how the client and server teams agree on chunk size and retry rules. The technical answer is only half the round at that level.
Round 4: past work
Prompt 6: the project you are proudest of
Walk me through the project you are proudest of from the last two years. What was your part, and what would have gone differently without you?
Follow-ups: What was the hardest disagreement on it? What would you do differently now? How did you measure the impact?
What a strong answer shows: a clear scope, first-person decisions, a named disagreement and how it resolved, and a measured result. A candidate who can answer “what would have gone differently without you” with specifics is showing exactly the evidence a hiring manager is looking for.
If you are interviewing for staff, pick a project that crossed team boundaries. A project that stayed inside your own codebase, however hard, makes it difficult for the interviewer to see the scope the role asks for. Past-work rounds also check for growth. “What would you do differently now” is not a trap; it is an invitation to show that you learned something specific.
The rubric
Score each round 1 to 4 on these rows, with one line of evidence each.
| Signal | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Speed of framing | Still unsure at minute five | Clear by minute five | Clear in two or three minutes, with edge cases named | Reframes to a simpler problem |
| Coding | Does not run | Happy path only | Clean, handles edges, complexity stated | Clean and ready for the follow-up |
| Communication | Silent stretches | Explains after | Narrates while working | Invites correction and uses it |
| Mobile judgement | Server thinking on a phone | Platform details when asked | Background, memory, old versions unprompted | Designs from the user’s experience inward |
| Product sense | Ignores the user | Mentions UX when asked | Loading, error and empty states designed | Trades technical cost against user impact |
| Impact and ownership | Team story | Own tasks | Own decisions and results | Results that needed them specifically |
A senior bar is mostly 3s. For staff, product sense and impact need to be 4s, because the scope of the role is larger than one feature.
How to run it
- Run the screen first, alone with a partner, strictly 45 minutes.
- Book the loop rounds on one day if you can, to feel the fatigue.
- Record every round and replay the first five minutes of each.
- Fix the lowest row, then run the loop again with new prompts of the same shape.
Most candidates discover that their framing is slower than they thought. Timing it is the only way to know.
Sources
- Meta Careers, Preparing for your technical screen
- Meta Careers, Preparing for your full loop interview
- Apple Developer, Downloading files in the background
- Android Developers, WorkManager
The Meta pages were read on 24 September 2026. Their downloadable guides are the fuller source; read the current one when you are invited, and treat your recruiter as the final word on your loop.
What to do next
- Mobile system design interview, for round 3
- Mobile live coding interview, for the screen and coding rounds
- FAANG mobile mock interview, the general version of this loop
- Practice, to run prompts under a timer
Start with the screen. If you cannot frame and solve two short problems in 45 minutes while talking, that is the first thing to fix, and everything after it gets easier.
