I've done this interview twice (different teams, different years) and also sat on the other side a few times as an interviewer at a previous job with a similar format. Here's the honest picture for the Amazon senior L5 system design round specifically.
What they give you Usually a prompt like: design a URL shortener, design a notification service, design a ride-matching system. Not novel problems. They're classics because the point is NOT to test if you've memorized the answer. The point is to watch how you work.
The first 5 minutes matter disproportionately Clarify scope. Ask about scale. Ask whether this is read-heavy or write-heavy. Ask about SLAs. Interviewers at Amazon have told me they start forming their vote in the first 10 minutes based on whether you're asking the right questions or just drawing boxes.
What they're actually scoring Amazon system design at L5 isn't just technical. They're also listening for ownership and dive deep LP signals. When you explain a trade-off, they want to see that you'd actually defend a choice if someone pushed back, not waver immediately. "It depends" is fine as a setup. "It depends" as a conclusion is a red flag.
Typical failure modes I've seen: Jumping into implementation without establishing scale requirements No discussion of failure modes, retries, or idempotency Treating the data model as an afterthought Being unable to articulate why you chose SQL vs. NoSQL for THIS specific use case
On depth vs. breadth They'll interrupt you and go deep on one component. That's intentional. Pick a component (usually the core write path or the most failure-prone piece) and be prepared to go three levels deep on it. Caching strategy, eviction policy, consistency tradeoffs.
For L5 you don't have to get everything perfect. You need to show senior-level judgment. That means knowing what's important enough to spend time on and what's okay to handwave.