Amazon SWE Interview: Coding Interview Guide

Estimated read time: 7-9 minutes

Summary: The Amazon SWE coding interview is part of the live interview loop after the OA and recruiter stages. For SDE II, the research describes four 55-minute interviews with Amazon software-development interviewers. Coding is evaluated alongside system design and Leadership Principle evidence, so your solution process needs to show correctness, scalability, and ownership of tradeoffs.

TL;DR + FAQ (read this first)

At-a-glance takeaways

• Amazon's official SDE II loop is described as four 55-minute interviews.
• Coding is expected across intern, new-grad, SDE I, SDE II, and SDE III paths, with Principal SDE+ possible or role-dependent.
• Amazon's official technical topics include data structures, algorithms, object-oriented design, databases, distributed computing, operating systems, internet topics, and ML/AI.
• Interviewers are not only checking code. They are also looking for scalable reasoning and Leadership Principle evidence.
• Strong candidates explain assumptions, write maintainable code, test edge cases, and connect decisions to customer or system impact when relevant.

Quick FAQ

How long is the Amazon coding interview?
For SDE II, the official research says the loop has four 55-minute interviews. Coding may be one or more of those interviews depending on loop design.

Who conducts it?
Amazon software-development interviewers. A Bar Raiser may also be part of the broader loop.

Is it only algorithms?
No. Algorithms matter, but the official topic list also includes object-oriented design, databases, distributed computing, operating systems, and internet fundamentals.

Does seniority change the bar?
Yes. SDE III and Principal SDE+ candidates should expect deeper tradeoffs, broader ownership, and stronger design judgment.

---

1) What the coding interview checks

Amazon's coding interview focuses on turning a problem into maintainable, scalable code while explaining your decisions. The research emphasizes coding, data structures, algorithms, object-oriented design, and broader software-development topics.

In Amazon's loop, technical work does not live in a vacuum. You may still be judged on ownership, customer impact, and whether you dive deep into constraints. A strong answer usually sounds like an engineer making a production-minded decision, not someone racing through a memorized problem.

Takeaway: solve the problem, but make the reasoning legible. Amazon needs to see how you think, not just the final code.

---

2) Questions you may face

These are representative Amazon-style coding tasks grounded in the research topics and question examples. They are written as interview tasks rather than commentary.

• Implement an LRU cache with get and put operations. What changes if capacity is one?
• Given a list of intervals, merge all overlapping intervals and return the result sorted by start time.
• Given a graph with weighted edges, find the shortest path between two nodes and explain what happens if an edge weight is negative.
• Given a partially working function, identify the bug, fix it, and walk through the failing case.
• Design the object model for a parking lot with vehicles, spots, pricing, and entry or exit operations.
• Design the object model for an elevator system with multiple elevators and pending requests.
• Given a stream of events, group or aggregate them efficiently under memory constraints.
• Given a service that times out under load, identify whether the issue is algorithmic, database-related, or distributed-system related.

---

3) Level-specific expectations

Relevant levels: Intern, SDE I/New Grad, SDE II, SDE III, Principal SDE+ where role-dependent.

Intern and new-grad candidates should show fundamentals, clean implementation, and coachable communication. SDE I and SDE II candidates need reliable coding, edge-case handling, and maintainability. SDE III and Principal SDE+ candidates should expect the interviewer to care more about scalability, operational tradeoffs, and how the code would behave inside a larger system.

If you are interviewing above SDE II, do not treat coding as a junior-only filter. The source research still includes coding and software-development fundamentals across the loop.

---

4) Evaluation signals

Positive signals include correct code, clear structure, scalable complexity, thoughtful edge-case handling, and the ability to explain tradeoffs. Amazon also values maintainability, so names, interfaces, and decomposition matter.

Weak signals include jumping into code without clarifying constraints, producing a brittle solution, skipping tests, or failing to explain why an approach scales. Another weak pattern is solving technically while giving no Leadership Principle signal at all.

Do this now: after each practice problem, write one sentence about correctness, one about complexity, and one about the tradeoff you chose.

---

5) Common failure modes

Treating coding and Leadership Principles as separate. Amazon's loop blends technical and behavioral evidence. Ownership can show up while you debug.

Ignoring maintainability. Code that works but is hard to read is a weaker Amazon signal.

Stopping at the first correct-looking answer. Follow-ups often ask about scale, edge cases, or a more production-like variant.

Underpreparing object-oriented design. Amazon's official topic list includes object-oriented design alongside algorithms.

Not testing aloud. If the interviewer cannot see how you validate correctness, they have to guess.

---

6) How to prepare

• Practice data structures, algorithms, debugging, and object-oriented design together.
• For every solution, include edge cases and complexity before moving to follow-ups.
• Practice explaining how code would behave under higher traffic, larger inputs, or partial failure.
• Prepare to discuss databases, distributed computing, operating systems, and internet fundamentals at the level your role requires.
• Attach a Leadership Principle angle to technical stories, especially ownership, dive deep, and deliver results.

The coding interview is not just a solve. It is a chance to show Amazon how you engineer under constraints.

---