Skip to content
Hari KharelStudy

Amazon

Leadership Principles are half the interview. Every round, coding and design included, carries 2-3 behavioral questions, and a weak LP round is almost always a no-hire. The coding is medium-level, in a non-executing editor, judged on “scalable, robust, and well-tested code” with no pseudocode. Expect class-based, low-level design, and at SDE III, deeper system design.

The loop

Section titled “The loop”
Stage Format Evidence
Online assessment (SDE II) HackerRank: coding “90 minutes for 2 questions”; system design multiple-choice (about 15-20 min); work styles tied to the LPs (about 8-10 min). Due within 7 days official
Phone screen (SDE III) 60 min with a senior leader: half LPs, half coding and design official
Loop SDE II: “four 55-minute interviews”. SDE III: five, including high- and low-level design official
Debrief Written feedback mapped to LPs, then a debrief led by the Bar Raiser. Outcome “within 5 business days” official timing; reported mechanics
  • Editor: coding in Livecode official, which reportedly doesn’t run code reported. Design in a whiteboard tool.
  • Language: any. reported
  • AI: candidates acknowledge they won’t use “unauthorized tools, like GenAI”, and use can disqualify you. This is press-reported from internal guidelines (2025); the prep pages don’t say it. reported One 2026 source says every loop now includes a question about how you use AI at work. thin

What the coding rounds test

Section titled “What the coding rounds test”

Amazon’s own criteria official:

  • “Syntactically correct code, no pseudo code.”
  • “Scalable, robust, and well-tested code. These are the main evaluation criteria.”
  • “Check for edge cases and validate that no bad input can slip through.”
  • Objectives: efficiency, reliability, robustness, portability, maintainability, readability.
Topic area How well attested Study first
Graphs and trees (BFS/DFS) Most common reported BFS, DFS, Binary trees, Topological sort
Arrays, strings, sliding window reported Sliding window, Hash maps
Heaps, sorting, linked lists reported Heaps, Linked lists, Sorting
Class-based problems (file-system operations, booking, call routing): low-level design inside a coding round reported Class design, Extensibility, Input validation
DP Usually avoided, not banned reported 1-D DP

Design

Section titled “Design”
  • Official: “Expect at least one question on software systems design… ask questions to complete and validate your design.” Objectives: practicality, accuracy, efficiency, reliability, optimisation, scalability. SDE III wants “a system-wide, architectural view” plus low-level design. official
  • Reported: SDE III often has two design rounds. Bar Raisers probe cost, operability and observability. At L5 a weak design round can survive if you’re coachable; the L6 bar is comparable to Google and Meta. reported

Study Caching, Rate limiting, Event-driven design and State machines.

Leadership Principles and the Bar Raiser

Section titled “Leadership Principles and the Bar Raiser”
  • Official:
    • “A significant portion of the conversation will focus on how you’ve demonstrated our Leadership Principles.”
    • Each interviewer asks two or three behavioral questions, and the LPs are split between interviewers.
    • Use STAR with “metrics or data”, and have examples of risk, success, failure and growth.
    • There are 16 Leadership Principles.
  • Bar Raiser reported:
    • A trained interviewer from outside the hiring team, with a veto or near-veto.
    • The bar is described as “better than ~50% of current employees in the role.”
    • Don’t reuse a story with them.
  • Weighting reported: a weak LP round is almost always a no-hire. Strong LPs can rescue borderline coding; the reverse doesn’t happen.

Story bank: 8-12 STAR stories covering most of the 16 LPs. Each one needs numbers, an “I” (not “we”), and a trade-off you made. Expect probes: “What data did you have?” “What would you change?” At SDE III, include multi-team impact and mentoring, or risk being down-levelled to SDE II.

Why people fail

Section titled “Why people fail”
  1. Thin, repeated or “we” stories with no metrics. Weak Customer Obsession and Ownership stories are reportedly the most common veto trigger. thin
  2. Silent coding with no tests and no input validation.
  3. Design that ignores failure modes, operations or cost.
  4. Reusing the same story with the Bar Raiser.

Your plan

Section titled “Your plan”

Use the Sandbox’s Amazon filter. Write full, validated code (no pseudocode), trace it before you press Run, and spend at least as long on your story bank as on coding.

2 weeks 4 weeks
Week 1 Course Planner, Island Survey, Outbreak Simulator, Word Grid Search, LRU Cache. Write 8 LP stories Graphs and trees: Course Planner, Island Survey, Outbreak Simulator, Tree Queries. Write 6 LP stories
Week 2 Substring Variety, Merging Sorted Feeds, LFU Cache, Leaderboard, In-Memory File System (as low-level design; it’s outside the Amazon filter, under all problems). Two design sessions. Mock: one coding problem plus three LP questions in 55 minutes Word Grid Search, Substring Variety, Minimum Covering Window, Task Cooldowns. 6 more LP stories
Week 3 Class design: LRU Cache, LFU Cache, Leaderboard, In-Memory File System. Three design sessions with cost and monitoring
Week 4 Two full 55-minute mocks (coding plus LPs), a design mock, a Bar Raiser-style LP grilling with a friend

Ask your recruiter: Which LPs will each interviewer cover? (They sometimes say.) Is there an online assessment? How many design rounds, and is one low-level?

Sources

Section titled “Sources”