Amazon Mobile Engineer Interview: Every Round, Decoded

You applied for an iOS or Android role at Amazon. Maybe it's on the Alexa team, Prime Video, or the Amazon Shopping app. The recruiter replied. Now what?

Here is the situation: this is not a standard SWE loop with a couple of Kotlin questions bolted on at the end. The DSA bar is real. There is a mobile-specific system design round that will test instincts most backend engineers never needed. And threading through every single round is Amazon's 16 Leadership Principles, graded explicitly in each one. Also, one of your interviewers holds veto power over the entire hiring decision. You will not know which one.

Welcome to Amazon.

The Full Interview Loop at a Glance

Amazon's mobile SWE interview typically runs five to six rounds, all in a single day (virtual or on-site). Each round is 45 to 60 minutes. Every round includes a behavioral component. Not just "the behavioral round." Every. Single. One.

Round	Duration	What Gets Assessed
Online Assessment	90 min	2 DSA problems, sometimes a work simulation
Recruiter / Phone Screen	30 min	Background, basic fit, logistics
Technical Phone Screen	45-60 min	1-2 DSA problems (no execution environment)
Coding Round 1	45-60 min	DSA + behavioral questions
Coding Round 2	45-60 min	DSA + behavioral questions
Mobile System Design	45-60 min	Architecture, constraints, trade-offs
Bar Raiser / LP	45-60 min	Leadership Principles deep dive (+ possibly DSA)

SDE II loops often run five rounds. SDE III loops add a second system design round or make the existing one significantly harder.

The OA and Phone Screen: More Dangerous Than They Look

The OA is two LeetCode-style problems on HackerRank. Difficulty is almost always medium, occasionally one medium and one easy. Amazon is not trying to trick you here. The OA filters for candidates who cannot solve a standard graph traversal or sliding window problem. Pass that bar and you are through.

The technical phone screen is where many mobile engineers first underestimate the process. It is a 45-minute conversation with a single DSA problem, no IDE, and you narrate everything. Amazon recruiters report that candidates frequently get the algorithm right and still lose the round because they went silent while thinking. Narrate. Every minute of silence is a minute of no signal, and "candidate was silent for extended periods" is something interviewers actually write in feedback.

What Amazon DSA Actually Looks Like

Two coding rounds, back to back in the loop. Each starts with 10 to 15 minutes of behavioral questions (yes, LP questions, right there in the coding round), then shifts to 30 to 35 minutes of algorithms.

Amazon's DSA difficulty is firmly in the medium range. This is not Google, where you might see a segment tree or bitmask DP problem. Amazon tests whether you can solve medium problems correctly, communicate clearly, and optimize incrementally. The difficulty spike comes from LP questions eating the first quarter of your round before you even see the algorithm.

Topics that appear frequently:

Trees and graphs. Lowest Common Ancestor, Number of Islands, BFS/DFS on a grid, cloning graphs. Tree traversal comes up often because Amazon knows mobile engineers work with view hierarchies.
Hashmaps and sliding window. Two Sum variants, minimum window substring, longest substring without repeating characters. These filter for O(n) thinking.
LRU Cache. The single most commonly cited Amazon DSA question across roles. If you have not implemented it from scratch (doubly linked list plus hashmap, O(1) everything), do it today. Before you finish this article.
Dynamic programming (light). Coin change, climbing stairs, word break. Not brutal DP, but you need to recognize the subproblem structure quickly.
Linked lists and strings. Reversal, cycle detection, palindrome checks. Fast-slow pointer problems appear regularly.

Practice on Amazon-tagged problems on LeetCode, filtered to the last six months. Amazon's tag quality is high. Get comfortable solving mediums while narrating your reasoning out loud.

The Round That Trips Up Backend Engineers

This is where the mobile interview actually diverges from a generic SWE loop. You are not designing a distributed backend. You are designing an application under constraints that backend engineers rarely think about. The OS will literally kill your process mid-task and not feel bad about it. Your users are on spotty 4G in a parking garage. Their phones are at 8% battery. Design accordingly.

The canonical prompt: describe the architecture of a feature or app given limited battery, unreliable networks, finite memory, and a hostile OS.

Common prompts:

Design an image loading and caching library (like Glide or Kingfisher)
Design the Amazon Shopping app's offline cart sync
Design a real-time notification system for a mobile client
Design a video streaming client (relevant for Prime Video teams)
Design an activity feed

What interviewers look for:

Layered architecture. Describe a UI layer (MVVM or MVI for Android, MVVM or Clean Architecture for iOS), a networking layer with retry logic and token refresh, a local cache (Room/SQLite for Android, CoreData or SQLite for iOS), and a sync engine for conflict resolution. Naming these components without being prompted signals experience.

Mobile-specific constraints. Battery drain, app lifecycle, background fetch limits on iOS, Doze mode on Android. If your sync system hammers the server every 30 seconds with no backoff, you have already failed.

Trade-offs stated explicitly. Push vs. pull for notifications: push is lower latency but requires maintaining a persistent connection or relying on APNs/FCM; pull is simpler to implement but drains battery on short intervals. Say the trade-off out loud.

Four-layer mobile app architecture: UI, Network, Cache, and Sync Engine, with mobile constraints annotated

For Android roles, expect questions about Jetpack libraries, Coroutines and Flow, WorkManager, and Hilt. For iOS: URLSession vs. third-party networking, Combine or async/await, CoreData vs. Realm trade-offs.

Leadership Principles: The Interview-Within-Every-Interview

Amazon relies on behavioral assessment more heavily than any other Big Tech company, and most candidates realize this one round too late. Your LP scores across all rounds are aggregated in the debrief. The coding round interviewer is not just grading your algorithm. They are logging your LP answers and feeding those into the final packet.

Amazon's 16 Leadership Principles include Customer Obsession, Ownership, Invent and Simplify, Bias for Action, Deliver Results, and others. Prepare concrete STAR stories mapped to the principles most commonly probed in engineering loops:

Customer Obsession. "Tell me about a time you made a technical decision based on user impact, even when it cost engineering resources."
Ownership. "Tell me about a time you saw a problem outside your scope and fixed it anyway."
Invent and Simplify. "Tell me about a time you eliminated complexity in a system."
Bias for Action. "Tell me about a time you made a decision with incomplete information."
Deliver Results. "Tell me about a time you were behind schedule and how you recovered."

Work Chronicles comic: interviewer asks 'Tell me about a time you resolved a conflict', candidate describes gaslighting a coworker until they quit, interviewer says 'Problem solved. You'll thrive here.'

Every round has a version of this question. Have an answer that is, ideally, more defensible than this one.

For mobile engineers, the best LP stories come from shipping. A crash rate spike you diagnosed at 2am. A memory leak caught before it hit production. An app review you nearly failed because a background task was burning CPU. These specifics land because they show technical depth alongside the ownership Amazon is actually scoring.

Prepare six to eight STAR stories. Each should map to two or three different principles. Do not recycle the same story across rounds since interviewers often know what you told other interviewers.

The Bar Raiser Is in the Room

Every Amazon loop includes one Bar Raiser with explicit veto power over the hiring decision. You will not be told which interviewer holds that role.

Bar Raisers are certified interviewers from anywhere in Amazon, often from a completely different team than the one hiring you. Their job is to ensure every hire lands at or above the 50th percentile of current Amazonians at that level. They can block a hire even if every other interviewer voted yes.

The veto is rarely used. One veteran Bar Raiser wrote publicly about conducting over 700 interviews and never exercising it. But their presence in the debrief shapes the outcome: they push the panel toward honest assessment and are specifically empowered to challenge "hire" votes that lack evidence in the write-up.

Treat every interviewer like the Bar Raiser. One of them is.

Why Solid Engineers Still Get No-Hired

Starting with platform-specific code before the algorithm. Jumping immediately to Kotlin coroutines or Swift async/await before laying out the approach signals familiarity, not thinking. Amazon wants to see problem-solving ability, not that you remember the API.

Underweighting LP prep. Mobile engineers often treat behavioral questions as the soft part of the interview. They are not. Vague stories ("we improved performance significantly") score low. Specific metrics ("we reduced app startup time from 3.2 seconds to 1.1 seconds by lazy-loading the recommendation engine, which correlated with a 4% lift in session starts") score high. The delta between vague and specific is often the difference between a hire and a strong no-hire.

Designing for servers in the system design round. If your answer does not mention app lifecycle, offline state, or network reliability in the first five minutes, you are already behind. Backend-centric designs signal you are not thinking about the platform.

Going silent during the technical phone screen. The highest-frequency failure mode. Silence is not neutral. It is a negative signal. Narrate what you are thinking even when you are unsure, because a partial approach out loud scores better than a complete approach in your head.

Six Weeks, Five Systems, Eight Stories

Six weeks out (ten to twelve if you are starting from a gap):

Weeks one and two: DSA foundation. Work through 40 to 50 LeetCode mediums on trees, graphs, hashmaps, and sliding window. Use Amazon's tagged problem set. Narrate out loud under time pressure. LRU Cache is mandatory.

Weeks three and four: Mobile system design. Design five systems from scratch: image caching library, offline-first sync, push notification client, video streaming client, activity feed. For each, write the component diagram, data flow, and at least two explicit trade-offs. Practice explaining it in 35 to 40 minutes.

Weeks five and six: LP stories and mock interviews. Write eight STAR stories and map each to three or four principles. Practice delivering them in under three minutes. This is where voice-based practice pays off. Working through stories with follow-up questions is how you find the vague answers before Amazon finds them for you. SpaceComplexity runs AI-powered mock interviews that simulate the back-and-forth a Bar Raiser actually puts you through, on demand, so you can get ten reps in where human scheduling would give you two.

Key Takeaways

Five to six rounds: online assessment, phone screen, two coding rounds, mobile system design, Bar Raiser LP.
DSA difficulty is medium. LRU cache, trees, graphs, sliding window, and light DP dominate.
Every coding round includes LP questions. Budget the time for that.
The system design round requires mobile framing (app lifecycle, offline state, battery, APNs/FCM) within the first five minutes.
Treat every interviewer like the Bar Raiser. One of them is.

If you have a loop coming up soon, check out the one-week pre-interview audit and the night-before guide. For a head-to-head comparison between Amazon and other FAANG loops, the Amazon vs Meta breakdown is worth a read.