Staff mobile engineer interview: what the system design round tests

TL;DR. Public descriptions of the mobile system design round agree on the direction of the change from senior to staff: less "can you build it" and more "can you decide what to build, how to ship it safely, and who has to be involved". In practice that means you lead the conversation, state your assumptions, and spend time on rollout, risk, measurement, privacy and ownership, not only on architecture. We cannot tell you what any specific company asks. This guide separates what public sources say from our own synthesis, shows one worked example (the lost acknowledgement in a chat app) at three levels, and gives a four-week practice plan built on our ten case studies.

1. What changes from senior to staff

Two public sources describe level expectations for this round, and they line up. The ByteByteGo mobile course introduction says a senior candidate should lead requirements gathering with little guidance, identify critical design aspects without being prompted, and justify decisions and trade-offs. For Staff+ it says the candidate should drive the conversation, anticipate future challenges, design for extensibility, show strategic thinking about business and product impact, assess risk, and raise advanced topics such as caching, offline-first design and failure recovery without prompting. The weeBox guide says the staff-level discussion becomes strategic, covering audience, resources, traffic, deadlines and risk. It also says years of experience are only a rough guide and do not translate directly to a level.

Outside mobile, one published engineering ladder (Foursquare's) makes a related point in general terms: it describes its staff level as a multi-team or product leader, says that level sets technical direction and helps define requirements, and calls it a different job from the level below, not just more of the same. That is a company document about one ladder, not a rule for interviews.

Our synthesis, built on those sources and on the "What changes by level" sections of our case studies, is six shifts:

• Scope. A senior answer designs the feature. A staff answer also decides which parts are a shared module, an SDK, or someone else's service.
• Ambiguity. The staff candidate narrows the problem deliberately: who the users are, which platforms, what is out of scope, and why.
• Trade-offs across teams. "Build versus adopt" and "who owns this" become part of the design, not an afterthought.
• Risk. What fails, how you notice, and how you stop the damage.
• Rollout. Flags, staged exposure, backward compatibility with old app versions, and migration.
• Organization. Modular boundaries so several teams can work without blocking each other.

2. What interviewers can observe

We have no insider view of how any company scores this round. What follows is a framing of observable behaviors, labelled as our synthesis. The idea: an interviewer can only grade what happens in the room, so think about which behavior at which moment would show the shift.

First 10 minutes (framing)

• You ask about users, platforms and scale, then say your assumptions out loud and ask if they hold.
• You cut scope on purpose ("I will cover send and sync, and leave search out") and name the risk of what you cut.
• You ask what success looks like and how it would be measured before drawing boxes.

The hard part (the deep dive)

• You raise failure modes before being asked: process death, lost responses, duplicate delivery, old clients.
• You give two options for a decision, say what each costs, and pick one with a reason tied to the stated constraints.
• When the interviewer adds a constraint, you adjust the design and say what moved, instead of defending the first draft.
• You name where the design touches another team or service and what contract you would want from it.

Wrap-up (last 5 to 10 minutes)

• You describe how you would ship it: flag, cohort, metric to watch, and the condition that triggers a rollback.
• You say what you would measure and which gaps you cannot observe.
• You list what you would do in the second quarter, not only the first release.

If you do the first-10-minutes behaviors but never reach the wrap-up, the round can still read as senior. That is a hypothesis from our reading, not a finding.

3. Worked example: the lost acknowledgement in a chat app

The sub-problem: the user taps send, the request reaches the server, the response is lost. The app does not know whether the message was delivered. Our chat app case study designs it this way: the message is inserted into Room with a pending status and a client-generated clientId, a unique WorkManager job sends it, the server is idempotent on clientId, and the retry returns the original serverId and seq instead of creating a second message. The case study's level section lists what it expects at each level; the three answers below are our illustration of how that could sound.

Mid-level answer. "I save the message locally, show it, and send it in the background. If it fails, I retry." That is a working send flow with retry. The gap: it does not say what happens when the failure is a lost response, so the retry may create a duplicate.

Senior answer. "The client generates a clientId and the server treats it as an idempotency key, so a retry after a lost ack returns the original message. Pending messages have no seq yet, so I render confirmed messages by seq and pending ones by creation time. Retries use exponential backoff with jitter, and permanent 4xx errors mark the message failed with a manual retry." Note the specifics: the key, ordering, backoff, and which errors stop retries. The case study also expects a senior to mention Doze and battery unprompted.

Staff answer. Everything above, plus the layers around it:

• Measurement. "I would track time to send-ack, failed-send rate, retry rate and duplicate rate, because a rising duplicate rate means the idempotency contract is broken somewhere."
• Rollout. "A change to the send path goes behind a flag and out to a small cohort first, since a bug here corrupts conversations."
• Contract. "The idempotency window and the retention of clientId on the server are a contract with the backend team, and old app versions must keep working."
• Multi-device and encryption. "With several devices the server stays the ordering authority, and end-to-end encryption changes what the server can dedupe or search."
• Ownership. "Send, sync and rendering sit in separate modules so more than one team can own them."

The staff answer is not longer for its own sake. It moves the conversation from "does it work" to "how do we know it works in production and who maintains it".

4. Staff-level topics most mobile answers skip

Each topic below has a case study that works through it. The pointers come from the "What changes by level" sections of those case studies.

• Rollout and kill switches. Remote config with a kill switch and staged exposure: see the analytics SDK and push SDK cases. Payment-path changes behind flags: booking app. Player changes compared between cohorts: video app.
• Observability and metrics. Delivery latency and retry rates in the chat app; time to first content and jank in the news feed; gap and resync rate in the live ticker; drop counters by reason in the analytics SDK.
• Multi-team ownership and modularization. A shared feed module in the news feed; search, checkout and trips as separate modules in the booking app; a shared playback module in the video app.
• Backward compatibility and SDK versioning. Binary compatibility, deprecation windows and version-adoption telemetry in the pagination library; API stability across years of app versions in the push SDK; a stable API and interceptor chain in image loading.
• Cost of changes. The cost model of a feed (fan-out, subscription limits) in the live ticker; CDN bytes versus engagement in the video app; backend cost and chunk-size rollout in photo and file sync; the build-versus-adopt question in image loading and the pagination library.
• Testing strategy. Fake APIs that drop the response after success, force error states and send out-of-order events, as in the booking app and live ticker follow-ups; testing a library itself in the pagination library.
• Privacy and consent. Consent gating, opt-out deletion and store disclosures in the analytics SDK; consent and remote kill switches in the push SDK; dedupe privacy versus end-to-end encryption in photo and file sync.

5. A four-week practice plan

Practice rule for every session: speak aloud (to a recording or a peer), time-box to 45 minutes, and state your assumptions at the start and again when you change them. The 45 minutes is our choice for practice; the weeBox guide describes a 45 to 60 minute round with the deep discussion taking 20 to 30 minutes, and formats vary.

1. Week 1: framing and the core loop. Do the chat app and the news feed. Focus on the first 10 minutes: scope, assumptions, success metrics. Then answer the case study's follow-up questions without reading them first.
2. Week 2: unreliable systems. Do photo and file sync and the live ticker. Focus on failure modes and what the OS will and will not run in the background. End each session with a two-minute rollout and metrics wrap-up.
3. Week 3: libraries and SDKs. Do the pagination library, image loading, analytics SDK and push SDK, one or two sessions each. Focus on API stability, versioning, build versus adopt, and consent.
4. Week 4: integrated products and mixed review. Do the booking app and the video app, then redo one earlier case with a changed constraint (for example, add end-to-end encryption or a second app that must reuse the module). Listen to your recordings and count how many of the staff topics in section 4 you raised unprompted.

6. Common mistakes

These are our observations from the public guidance and from how the case studies are structured, not data about candidates.

• Spending the whole round on architecture layers and never reaching rollout or metrics.
• Treating "staff" as "more components" instead of more decisions with stated reasons.
• Skipping scope and assumptions, then designing for a product nobody described.
• Presenting one option as the only option.
• Saying "feature flag" without saying what you would watch and what triggers a rollback.
• Claiming metrics you cannot measure, such as push delivery, without naming the unobservable gaps.
• Recommending a custom library without addressing build versus adopt.
• Ignoring old app versions when proposing a protocol or schema change.
• Freezing when the interviewer adds a constraint, instead of saying what changes.

7. What we do not know

• Company loops vary. The weeBox guide itself says interview structure depends on the interviewer's style. We have not verified what any specific company asks at staff level, and we do not claim to.
• We have no insider data. The author of this site has not run these interviews and does not claim to know how loops are scored.
• Anecdotes are anecdotes. A Blind thread from 2022 that we read was a short exchange in which one reply said some companies skip LeetCode-style questions for Android roles. It is one person's claim, several years old, and does not tell you how any loop works today.
• Level labels differ between companies. The ladder we cite is one company's, and "staff" can mean different things elsewhere.
• From public sources: the level expectations in section 1 (ByteByteGo introduction, weeBox guide, one company ladder). Our synthesis: the six shifts, the behavior signals in section 2, the three illustrative answers in section 3, the practice plan and the mistakes list.
• No promises. Preparing this way does not guarantee any outcome in any process.

8. Further reading

• ByteByteGo: Mobile System Design Interview, introduction (mid, senior and Staff+ expectations)
• weeBox: mobile-system-design (GitHub) (format, approach and level expectations)
• Foursquare: Engineering levels and progression (one published ladder, not an interview guide)
• Blind: Sr/Staff mobile Android engineer interview thread (a 2022 anecdote, included to show what is out there)
• DesignGurus: Grokking Modern Mobile System Design Interview (course page; the lesson titles on the level and company topics are visible, the lesson content was not)

Keep reading

• Offline-first mobile system design: one model, six case studies
  The official offline-first model applied to chat, feed, upload, booking, analytics and push.
• Native vs cross-platform: write the decision record
  A staff-level ADR for a framework bet: criteria, the assumption that flips it, migration, parity tests, orphaned libraries, rollback, and a free template.
• Design a chat app
  Outbox, idempotent sends, WebSocket and push sync.
• Design a news feed
  Pagination, optimistic writes, cache invalidation.