Amazon SWE Interview Playbook

Amazon’s interview is a rubric-driven loop. That is the whole thing. If you understand what each of the 16 Leadership Principles is scoring and you can tell specific, metric-backed stories against them, you will do well. If you show up with clean code and vague behavioral answers, you will lose — even if you are the strongest coder in the loop.

The loop

Most L5/L6 SWE loops are 5–6 back-to-back rounds, roughly an hour each:

1. Coding ×2 — LeetCode medium, sometimes hard. Clean, working, complexity-aware. Tests and edge cases carry real weight; bar raisers read rejections as “did not validate their own code.”
2. System design — for L5+, usually a backend service at scale. Expect the interviewer to push you on cost, failure modes, and how you’d operate the thing at 3am.
3. Behavioral / LPs — 1–2 dedicated rounds, plus LP questions embedded in every other round. Every round scores LPs.
4. Bar raiser — a trained interviewer from a different org. Usually a blend of behavioral deep-dives and one technical probe. Their vote is weighted heavily in debrief.

The bar raiser is the round most people misunderstand. They are not trying to catch you lying. They are trying to calibrate whether you “raise the bar” on the team you’d join — meaning your performance, on the dimensions the LPs measure, is above the median of current Amazonians at that level.

What “data-driven” actually means in answers

Every LP prompt at Amazon expects specific numbers. “We improved performance” is a rejection. “We cut p99 latency from 820ms to 140ms on a 40-QPS service, which moved our conversion rate on the checkout flow by 2.3%” is a pass. If you cannot put numbers on the impact of your own work, you are not ready for this loop — go back to your old dashboards and write the numbers down before you apply.

The pattern that works: STAR with receipts. Situation in one sentence. Task in one sentence. Action in three to four sentences with specific technical choices and why. Result in one sentence with a metric. Then stop — let the interviewer probe.

System design: operational focus

Amazon’s system design round skews heavily operational. Yes, they want you to sketch the architecture. They also want to hear: what happens when this region goes down, what does the on-call runbook look like, what is the per-request cost at 10x scale, where do you shed load when you cannot keep up. If your design answer spends 45 minutes drawing boxes and zero minutes on operations, you are capped at L4 regardless of how elegant the architecture is.

The “scale 100x” follow-up is not a gotcha — it is the actual question. Your initial design should be sized for the stated load, and your extension should walk through what breaks first, what you fix, and what it costs.

Common rejection patterns

• Vague behavioral answers. “We worked together, I helped ship it.” Every round gets a “tell me more” until you fail to produce specifics. Prepare the specifics in advance.
• No metrics on your own work. If you cannot quantify the impact of a project you led, bar raiser scores Deliver Results as “no signal.”
• Over-indexing on LeetCode grind. Amazon’s coding bar is medium. Your weak spot is almost certainly the behavioral depth, not the algorithms.
• Ignoring ops in design. Drawing the boxes is 30% of the design rubric. The other 70% is how you’d run the thing.

Pair this playbook with a mock interview calibrated to Amazon’s LP-heavy rubric. Then compare against the Google and Meta playbooks to understand why the same answer lands differently across loops.