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
Amazon mobile mock interview: practise the loop in 2026
An Amazon mobile mock interview built on Amazon's published SDE prep: assessment, four 55-minute rounds, Leadership Principles, six prompts and a rubric.
An Amazon mobile mock interview has more to work from than most, because Amazon publishes a detailed prep page for software development engineers. It describes an online assessment, a loop of four interviews, and behavioural questions tied to the Leadership Principles. It does not describe a mobile-specific loop, so the mobile part is yours to prepare.
This page summarizes what Amazon publishes, with links, then gives you a mock that follows that published shape with mobile content inside it: six practice prompts with follow-ups and the rubric I use when I write up a candidate.
The prompts are practice prompts I wrote. They are generic mobile engineering problems, not questions Amazon has asked. This site never attributes a question to a named company.
What Amazon publishes about its interviews
As described on Amazon’s careers pages, specifically the SDE II interview prep page:
- The process runs from application to an online assessment, then an interview loop, then an outcome.
- The online assessment gives 90 minutes for two technical questions, followed by 20 minutes of systems design scenarios and an 8-minute multiple choice work style survey.
- The loop is four interviews of 55 minutes each with members of Amazon’s software development community, covering technical competencies and non-technical competencies based on the Leadership Principles, with different interviewers assigned to evaluate different areas.
- Code should be syntactically correct, not pseudocode. The page names scalable, robust and well-tested code as the main evaluation criteria, and asks you to check edge cases and bad input.
- Candidates should expect at least one system design question.
- Each interviewer will typically ask two or three behavioural questions tied to the Leadership Principles. The page recommends the STAR method (situation, task, action, result) and metrics or data where applicable.
Amazon’s Leadership Principles page lists sixteen principles, including Customer Obsession, Ownership, Dive Deep, Bias for Action and Have Backbone; Disagree and Commit. Amazon’s main hiring hub also mentions Bar Raisers in the loop without describing the role in detail on that page, so I will not describe it either.
The SDE II page is for a general software engineering role at a particular level. Your loop may differ by level and team. Ask your recruiter whether your design question will be mobile or backend, and whether coding happens in a shared editor.
What that means for a mobile candidate
Two things stand out. First, the published instruction to write syntactically correct code, not pseudocode, is strict. Mobile engineers who sketch in shorthand and plan to “clean it up later” lose points here. Write real Swift or Kotlin, or whatever language you choose, from the first line.
Second, behavioural questions are not a separate round you can wing. The published description says each interviewer typically asks two or three of them, so stories are part of every interview, not only one. In my experience, candidates who prepare technical content and leave stories until the night before are the ones who come across as vague. You need a set of mobile stories ready, each one mapped to more than one principle, with numbers.
The mock loop at a glance
The assessment timings and the four 55-minute interviews come from Amazon’s SDE II page. How the content is spread across the rounds below is my practice layout, not Amazon’s; real loops differ by team and level.
| Round | Time | Format | Focus |
|---|---|---|---|
| Assessment | 90 + 20 + 8 min | Solo, timed | Two coding problems, design scenarios, work style survey |
| 1. Coding | 55 min | Shared editor | Correct code, tests, plus two behavioural questions |
| 2. Mobile system design | 55 min | Drawing tool | Client design, plus two behavioural questions |
| 3. Coding with mobile depth | 55 min | Shared editor | Concurrency and lifecycle, plus two behavioural questions |
| 4. Behavioural focus | 55 min | Conversation | Three stories against the principles |
Split each 55-minute technical round as roughly 35 minutes technical and 20 minutes behavioural. That split is my practice suggestion, not something Amazon publishes; it follows from the page saying each interviewer typically asks two or three behavioural questions, and it makes you rehearse switching modes inside one interview.
Round 1: coding
Prompt 1: retry with backoff
Write a function that performs a network request and retries on failure with exponential backoff and jitter, up to a maximum number of attempts. Some errors must not be retried.
Follow-ups: Which errors are not retryable, and why? What happens if the user leaves the screen during a retry? How do you test it without real delays?
What a strong answer shows: a clear classification of retryable errors (timeouts and server errors yes, most client errors no, and an authentication failure handled by a token refresh rather than a blind retry), a capped delay with random jitter, cancellation tied to the caller’s lifetime (task cancellation in Swift, a coroutine scope in Kotlin), and tests with an injected clock and a fake transport.
Prompt 2: deduplicate order updates
A stream of order status updates arrives out of order and sometimes twice. Each update has an order ID, a status and a sequence number. Keep the latest status for each order and ignore stale or duplicate updates.
Follow-ups: What if sequence numbers can reset after a server migration? How much memory for a user with a thousand orders?
What a strong answer shows: a map from order ID to the highest sequence number seen, a comparison that rejects stale updates, tests for duplicate, out-of-order and first-seen cases, and an honest answer to the reset follow-up that asks the server team rather than guessing.
Remember the published instruction on syntax. I would have your partner mark every line that would not compile, and count them.
Round 2: mobile system design
Prompt 3: live order tracking
Design the client for a screen that shows a delivery’s live status and the driver’s position on a map, updating while the screen is open, and a notification when the order arrives.
Follow-ups: Polling, a long-lived connection, or push? What does the screen show when the connection drops? How do you avoid draining the battery? How do you roll this out safely?
What a strong answer shows: a choice between polling and a persistent connection with the cost of each named, push notifications for the arrival event rather than a connection held in the background, a local model the UI renders from so that a dropped connection shows the last known state with a clear “updating” indicator, and a rollout behind a remote flag with a fallback to the old screen. A staff candidate would also say what they would measure to know it works in the field.
A good design answer ties back to the customer. The best answer to “polling or push” is not the most sophisticated one; it is the one that gives the user a correct screen at an acceptable cost.
Round 3: coding with mobile depth
Prompt 4: a download manager with limits
Write a download manager that runs at most three downloads at a time, queues the rest, supports cancel, and reports progress per download.
Follow-ups: What happens to queued downloads when the app is suspended? How do you make the queue survive a relaunch? How do you prevent two downloads of the same file?
What a strong answer shows: a concurrency limit implemented with a clear owner of the queue, deduplication by URL, cancellation that frees a slot and starts the next item, persisted queue state, and on the suspension follow-up, the platform tool for background transfers rather than trying to keep the app alive.
This round separates candidates who have shipped download or upload features from those who have only read about them. I listen for what they say about the app being suspended, because that is where the real bugs live.
Round 4: behavioural
Amazon’s prep page recommends STAR answers with metrics or data where applicable. Prepare at least six mobile stories and map each one to two or three principles, so you are not left without a story when the same principle comes up twice.
Prompt 5: a crash spike you investigated
Tell me about a time a metric looked wrong and you dug into it until you found the cause.
Follow-ups: What was the first data you looked at? What did you rule out? What did you change so it would be caught earlier next time?
What a strong answer shows: a specific metric and number, the investigation in steps, the root cause, the fix, and the prevention. This is a Dive Deep story, and it also works for Ownership if you fixed something that was not strictly your area.
Prompt 6: a decision you disagreed with and then supported
Describe a technical or product decision you argued against, said so openly, and then committed to.
Follow-ups: How did you raise the disagreement? What did you do after the decision was made? What was the outcome?
What a strong answer shows: a disagreement raised with evidence, a clear decision point, and full commitment afterwards that the candidate can show with actions, not only words. It maps directly to Have Backbone; Disagree and Commit.
Answers that use “we” throughout are the most common miss in this round. The STAR format helps only if the A, the action, is yours.
The rubric
Score each round 1 to 4 on these rows, with one line of evidence each.
| Signal | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Code correctness | Pseudocode or does not compile | Compiles, happy path | Correct, edges handled, tests stated | Correct and structured for the follow-up |
| Design | Components without decisions | Decisions without costs | Decisions with costs and a rollout | Measures, fallbacks and ownership included |
| Mobile depth | Server habits on a phone | Platform details when asked | Suspension, battery, old versions unprompted | Designs for failure first |
| Customer focus | Not mentioned | Mentioned when asked | User experience drives a decision | Trades cost against user impact explicitly |
| STAR stories | Vague, no result | Result without numbers | Specific, own actions, measured result | Maps to several principles naturally |
| Ownership | Team story | Own tasks | Own decisions and why | Fixed something beyond their own area |
For a senior bar, look for 3s across all rows with no 1s. A single story round at 1 can outweigh strong code in a real debrief, so treat it as seriously as a coding miss.
How to run it
- Run the assessment alone, timed, before the loop.
- Keep your partner to 55 minutes per round, including the behavioural question.
- Write your stories down in STAR form and time each at two to three minutes.
- Record, replay, fix the lowest row, and run it again with new prompts.
The written stories are the part most people skip. They are also the part that improves fastest with practice, because a story told three times gets tighter every time.
Sources
- Amazon Jobs, How we hire
- Amazon Jobs, SDE II interview prep
- Amazon Jobs, Leadership Principles
These pages were read on 24 September 2026. The SDE II page describes one role and level; your loop may differ, so confirm the format with your recruiter.
What to do next
- Mobile system design interview, for round 2
- Mobile live coding interview, for rounds 1 and 3
- FAANG mobile mock interview, the general version of this loop
- Practice, to run prompts under a timer
Prepare the stories as seriously as the code. Stories are part of the published loop, not an extra, and the candidate with six ready stories walks in calmer than the one with two.
