I bombed my first Amazon system design round in 2021. Not because I didn't know distributed systems — I'd been building them for six years. I bombed it because I spent the first 20 minutes designing the perfect architecture in my head before saying a word. The interviewer finally interrupted me with "so what are you thinking?" and I'd lost the thread completely.
That experience taught me something no blog post had: these interviews aren't a knowledge test. They're a collaboration simulation. Amazon is checking whether you can be the person in the room who moves ambiguous problems forward without freezing up or steamrolling everyone else.
Here's what the 45 minutes actually look like, and what's really being graded.
The Clock Breakdown (How Interviewers Actually Run It)
Amazon SDEs and senior engineers I've talked to describe roughly the same flow, even if they'd never write it down this explicitly.
Minutes 0–5: Requirements gathering. The prompt is intentionally vague. "Design a notification system for Amazon" tells you almost nothing. How many users? Push or email or both? Reliability guarantees? You're expected to ask. The trap here is asking too many questions and stalling, or asking too few and charging ahead into the wrong design. Aim for 3–5 targeted clarifying questions, then summarize what you've decided to build. Something like: "I'm going to focus on a push notification system handling 10 million daily active users, prioritizing delivery reliability over strict ordering. Sound right?"
Minutes 5–15: High-level design. Sketch the components. User hits an API gateway, goes through a notification service, something queues the work, workers dispatch to Firebase or APNs, you need some kind of fan-out logic for large subscriber lists. Don't go deep yet. Just establish the skeleton. This is where a lot of people over-architect — trying to solve every problem before they've even committed to a shape.
Minutes 15–35: Deep dives. The interviewer picks what interests them. Maybe it's the fan-out problem for a celebrity with 50 million followers. Maybe it's failure handling when APNs is down. Maybe it's exactly-once delivery semantics. You don't get to control which thread they pull. This is the real interview. Everything before was setup.
Minutes 35–45: Wrap-up and questions. There's usually a brief discussion of what you'd do differently, what you'd prioritize if you had another week, and your questions for them. Don't skip this part — it signals engineering maturity.
What the Interviewer Is Actually Writing Down
Amazon uses a structured feedback form tied to their Leadership Principles, and the system design rubric maps onto a few specific things. I've seen enough interview loops from both sides to say with some confidence what matters.
Ownership and scope judgment. Did you immediately try to build a globally distributed, multi-region, CRDT-synchronized masterpiece? Or did you scope the problem pragmatically, call out what you'd defer to V2, and justify the tradeoffs? Amazon interviewers — probably more than Google or Meta — respond well to engineers who think about what actually needs to be built versus what could theoretically be built.
Communication while thinking. This is underrated. When you're working through whether to use Kafka or SQS, they want to hear the reasoning out loud, including the wrong turns. "I was thinking Kafka here, but actually our throughput requirement is low enough that SQS would reduce operational overhead significantly" is a good answer. Staring at the whiteboard for 90 seconds and then saying "SQS" is not.
Handling pushback. Interviewers will challenge your choices. Sometimes it's genuine — they see a real flaw. Sometimes it's probing to see if you'll collapse or defend defensibly. The goal isn't to always be right. It's to engage with "have you thought about X?" like a real engineering conversation rather than either capitulating immediately or getting defensive.
Concrete numbers. Rough capacity estimation, back-of-envelope math for storage or bandwidth, latency requirements for different tiers — these signal that you've shipped real systems. You don't need exact answers, but "around 100MB per user per year for message metadata, so at 10M users that's roughly 1TB, easily fits in a managed RDS instance for now" is miles better than "we'd need some storage layer."
The Topics Amazon Consistently Goes Deeper On
Based on patterns I've seen and what I've heard from people who've been through the loop recently:
Fan-out at scale keeps showing up in any feed, notification, or messaging design. The naive approach (loop through all followers, send each a message) breaks around 10K followers and shatters at celebrity scale. You need to know the hybrid fan-out pattern — pre-compute for regular users, pull on read for high-follower accounts.
Exactly-once vs at-least-once delivery and why true exactly-once is expensive. Most real systems accept at-least-once and build idempotency keys into the consumer side.
Database choice reasoning. Not just "I'd use DynamoDB because it scales" — that's a non-answer. Why DynamoDB versus Aurora versus a combination? What access patterns drive the choice?
Failure modes. What happens when your notification worker dies mid-batch? When the downstream provider (APNs, Firebase) is degraded? Interviewers at Amazon specifically probe resilience because AWS services power so much infrastructure that an engineer who hasn't thought through failure modes is a liability.
Getting Stuck: What to Actually Do
Everyone gets stuck. The difference is what you do with it.
The worst thing you can do is go silent and stare. The second worst is pretend you're not stuck and start talking in circles. I've done both.
Name the problem explicitly. "I'm not immediately sure how to handle the case where a user's device token has rotated but we haven't refreshed it in our database yet — let me think through this." That sentence buys you 30 seconds and signals self-awareness. Interviewers almost universally respond better to transparency than to watching someone spiral.
Fall back to first principles. If you're stuck on a specific mechanism, step back to the requirement. "What we actually need here is a way to know that a message was received — so either we need acknowledgment from the client, or we accept that we won't know and handle retries differently." Sometimes just re-stating the goal unsticks you.
Ask a pointed question. Not a desperate one. Something like "In your system, does the product requirement allow for eventual delivery with a retry window, or does it need near-real-time guarantees?" shows you're trying to scope rather than flounder. Interviewers can distinguish between genuine clarification and stalling, but pointed questions are usually welcome.
Offer a partial answer and flag it. "I can handle the happy path here — messages delivered to online users — but I'd need to think more carefully about the durable offline queue mechanism. Want me to proceed with the online case and come back?" That's a reasonable engineering conversation, not a failure.
The Prep That Actually Helps vs. The Prep That Doesn't
Watching YouTube videos of people designing Twitter or URL shorteners is fine for getting vocabulary. It's not sufficient for the parts that actually matter.
What helps more is practicing out loud with someone who will interrupt you. Pramp does this for free, though the peer feedback quality varies wildly depending on who you're matched with. Interviewing.io is better for senior-level practice because the interviewers are actual engineers who'll push back with real follow-up questions. Interview Kickstart has structured curriculum that's good if you're starting from scratch but it's expensive and paced slowly for experienced engineers.
I've also used AceRound AI for solo practice runs when I couldn't schedule a human session — it's useful specifically for talking through your reasoning without judgment, which is a different kind of practice than getting challenged. Not a substitute for real pushback, but good for building the habit of narrating your thinking.
Final Round AI is popular but I find the coaching feel of it a bit rigid for system design specifically — it's better suited to behavioral prep.
The single most valuable thing I did before my re-attempt at Amazon was run 8 mock system designs in three weeks, recording audio each time. Listening back, I could hear exactly where I went quiet, where I repeated myself, where I jumped to solutions before establishing requirements. That feedback loop is hard to get any other way.
The Part Nobody Talks About: Amazon Specifically
Google and Meta system design interviews share DNA with Amazon's, but Amazon has some quirks worth knowing.
The Leadership Principles bleed into technical rounds. An interviewer might explicitly ask "how would you handle the case where product changes the requirements halfway through?" — that's partly a system design question and partly an Ownership / Bias for Action question. You need to engage with both layers.
Amazon also has a stronger operational culture than, say, Google. Questions about monitoring, alarming, rollout strategy, and "how would you know if this thing is broken in production" come up more at Amazon than anywhere else I've seen. If you design a beautiful system and say nothing about observability, that's a gap.
And the bar for written communication (design docs, PRFAQs) is real — some interviewers will ask you to sketch a brief narrative of the system's goals and non-goals as part of the exercise. It's not a writing test, but structured thinking about problem framing matters.
The honest summary is that Amazon's system design interviews reward engineers who can think out loud, make scoped decisions under ambiguity, and engage with failure like it's a normal part of the problem space — not a threat. The 45 minutes is tight enough that if you get lost in the weeds or lose momentum early, you won't recover. But if you know the rhythm going in, it's a much more manageable conversation.
Want real-time interview assistance? AceRound AI works live during Zoom/Meet interviews.
Top comments (0)