Amazon SDE 1 Interview Guide 2026: Coding, System Design, Leadership Principles, and Loop

An Amazon SDE 1 design answer becomes much easier to assess when the candidate stops naming patterns and shows a working object. Who owns the quantity? When is the price captured? What happens if a discount fails? Can a caller change a quote after checkout starts? Those questions expose engineering judgment in a small, manageable problem.

Prepare coding, object design and Leadership Principles together, while keeping your invitation's scope clear. This guide adds a complete cart exercise and an annotated behavioral example. Both are original teaching material, not leaked questions or Amazon's private scoring rubric.

Try Design an Object-Oriented Shopping Cart before reading the implementation. The Amazon-tagged practice record covers exact money, pricing rules, stable summaries and concurrency follow-ups. The smaller version below deliberately implements only the single-process core.

What is official, and what depends on your invitation?

Amazon's student and graduate SDE page describes application, an online assessment if recruiting proceeds, possible virtual interviews and an offer/result. It says that route's interview result arrives within five business days. This does not specify every early-career requisition's session count, duration or design depth.

Its general software-development topics page includes coding, data structures, algorithms, object-oriented design and systems fundamentals. It recommends confirming relevant subjects with the recruiter and practicing without an IDE. Its interview-loop page describes individual conversations assessing different aspects of skills and experience. Treat those as preparation guidance, rather than a universal SDE 1 diagram.

Candidate accounts can suggest useful mock scenarios, but unverified reports should not establish a four-round promise, a guaranteed question difficulty or a mandatory senior-scale design round. The current invitation controls. Before the loop, ask about the hiring channel, technical medium, competencies, language, libraries and permitted assistance. Do not assume access to AI tools during an assessment.

Evidence to prepare	What it demonstrates	Scope question to confirm
Executable coding solution	Contract, invariant and boundary handling	Shared editor, whiteboard or assessment platform?
Small object design	Responsibilities, state and one extension	OOD/LLD, service design, or neither as a dedicated session?
True project stories	Personal decisions and follow-through	Which experiences are relevant to the team?
Invitation checklist	Accurate logistics and expectations	Who owns the next update and when?

Coding: produce a complete answer before adding machinery

Practice a repeatable sequence: clarify input and output, state a simple correct approach, explain its invariant, implement, then test. For a frequency problem, decide what happens with tied counts and whether output ordering matters before choosing a heap. For a stream, distinguish a running aggregate from recomputation over the entire history.

Dry-run a normal input, an empty input and an adversarial case. Explain what each catches. If you choose a faster approach, name the additional state that makes it correct. A memorized complexity label does not explain why removing an item from a heap or advancing a pointer preserves the answer.

Save a short mistake log after each timed attempt: the contract you missed, the failing input, the corrected invariant and the follow-up that changes the design. Repeating the same mistake across ten new questions is less useful than fixing it and demonstrating the corrected behavior in two different settings.

Original OOD exercise: a cart with a stable price quote

The prompt is deliberately bounded. A cart captures a catalog's prices at construction, supports replacing a quantity and removing an item, and seals into an immutable quote. Prices are integer cents in one currency. Zero quantity removes a line; an empty cart cannot seal. One discount applies to the whole subtotal. Percentage discounts round half up once at the subtotal level.

Sealing is a local state transition from open to sealed. Repeating it returns the original quote, even if the caller supplies another rule. Mutating a sealed cart fails. A rule exception or invalid result leaves the cart open. This contract makes behavior inspectable without introducing payment or a database.

Object	Owned responsibility	Deliberately excluded
Cart	Captured prices, quantities, open/sealed state	Inventory availability and persistence
Discount interface	Return a discount in cents	Mutating cart lines or charging a card
Percent / Fixed	One deterministic pricing policy	Promotion stacking and tax rules
Quote	Immutable lines and auditable totals	An order, reservation or receipt

This is a price snapshot for the entire catalog at cart creation. A real product could snapshot each line at addition or reprice at checkout instead. Choose explicitly; changing the external catalog does not silently change this example's quote.

from dataclasses import dataclass
from typing import Protocol

def nonnegative_int(value):
    if type(value) is not int or value < 0:
        raise ValueError("expected nonnegative integer")
    return value

class Discount(Protocol):
    def cents(self, subtotal: int) -> int: ...

@dataclass(frozen=True)
class Percent:
    basis_points: int
    def __post_init__(self):
        if not 0 <= nonnegative_int(self.basis_points) <= 10000:
            raise ValueError("invalid percentage")
    def cents(self, subtotal):
        return (subtotal * self.basis_points + 5000) // 10000

@dataclass(frozen=True)
class Fixed:
    amount: int
    def __post_init__(self):
        nonnegative_int(self.amount)
    def cents(self, subtotal):
        return min(self.amount, subtotal)

@dataclass(frozen=True)
class Quote:
    lines: tuple
    subtotal: int
    discount: int
    total: int

class Cart:
    def __init__(self, catalog):
        self._prices = dict(catalog)
        for sku, price in self._prices.items():
            if type(sku) is not str or not sku:
                raise ValueError("invalid SKU")
            nonnegative_int(price)
        self._quantities, self._sealed = {}, None
    def set_quantity(self, sku, quantity):
        if self._sealed is not None:
            raise RuntimeError("cart is sealed")
        nonnegative_int(quantity)
        if sku not in self._prices:
            raise KeyError(sku)
        if quantity == 0:
            self._quantities.pop(sku, None)
        else:
            self._quantities[sku] = quantity
    def seal(self, rule: Discount):
        if self._sealed is not None:
            return self._sealed
        lines = tuple((s, self._quantities[s], self._prices[s])
                      for s in sorted(self._quantities))
        if not lines:
            raise ValueError("empty cart")
        subtotal = sum(q * p for _, q, p in lines)
        discount = nonnegative_int(rule.cents(subtotal))
        if discount > subtotal:
            raise ValueError("discount exceeds subtotal")
        quote = Quote(lines, subtotal, discount, subtotal - discount)
        self._sealed = quote
        return quote

The Discount protocol keeps pricing separate from mutation. Python's protocol is a typing contract, not a runtime sandbox: use trusted rule implementations. The cart still validates the returned integer and rejects a discount beyond the subtotal. Frozen dataclasses and tuple lines prevent ordinary callers from changing a returned quote.

Construction costs O(P) for P catalog entries. A quantity replacement is expected O(1). First sealing sorts the L selected SKUs in O(L log L), then computes O(L) totals. Later sealing returns the cached quote in O(1). Memory is O(P + L); retaining a large catalog is a conscious simplification.

Walk through the cents and the state

Use notebook at 1,299 cents and pen at 250 cents. Set notebook quantity to two and pen to one. The subtotal is 2 × 1,299 + 250 = 2,848 cents. A 12.5% rule is 1,250 basis points; its discount is exactly 356 cents, so the final total is 2,492 cents.

For a subtotal of 101 cents, the same rule produces 12.625 cents of discount and rounds to 13, yielding 88 cents. This makes the rounding policy visible. It is not a claim about Amazon checkout or a tax jurisdiction's rules.

After sealing, changing the pen quantity raises an error. Repeating seal(Fixed(9999)) returns the first quote rather than applying a second discount. A new cart is needed for a revised purchase in this exercise. That simple state policy avoids silently altering a quote another component has already read.

Test interactions, then extend one boundary

The implementation passed 3,039 local checks, including 1,000 seeded carts compared with an independent Decimal rounding calculation. These checks exercise price capture, replacement rather than accumulation, zero removal, empty sealing, unknown SKUs, invalid quantities, percentage endpoints, half-up rounding, fixed-discount capping and the sealed state. A failing or oversized discount is followed by a valid seal to confirm that failure did not poison the cart.

For example:

cart = Cart({"notebook": 1299, "pen": 250})
cart.set_quantity("notebook", 2)
cart.set_quantity("pen", 1)
quote = cart.seal(Percent(1250))
assert (quote.subtotal, quote.discount, quote.total) == (2848, 356, 2492)
assert cart.seal(Fixed(9999)) is quote

The fixed discount is the first complete extension: it adds a pricing object without another branch inside Cart. If the next requirement is shipping, create a separate shipping calculation with a destination and an explicit place in the total. Do not quietly include shipping in the existing discount base. Tax and multiple currencies likewise need a stated contract before code.

Concurrent updates from two devices are a different extension. Persist a cart version and reject a stale expected version rather than allowing last-write-wins to erase a newer quantity. For retry-safe commands, retain a command ID and its payload/result together. A command repeated with different input must be rejected. The code above implements neither mechanism.

Production checkout also needs authoritative inventory, payment failure states and a durable record of completed transitions. Returning the same in-memory quote does not make a distributed purchase idempotent, and a process restart loses this cart. Explain those boundaries if the interviewer expands the prompt; do not claim them because the design has a method called seal.

Leadership Principles: a finished example with ownership and failure

Amazon presents its Leadership Principles as guides for decisions. Prepare several true stories from internships, coursework, employment or other projects. A useful answer contains the concrete problem, your responsibility, the alternatives, the action, the result and what changed afterward. Principle names should follow the evidence rather than replace it.

The following is an explicitly fictional practice answer. All people, work and measurements are invented teaching inputs. Read its structure; never present its events or numbers as your own experience.

Situation and task: “On a four-person student team building a club preorder tool, we found 27 duplicate reservations among 900 submitted requests during a pilot. I owned the request handler and replay tests, while another teammate owned inventory reconciliation. We had one week before the next event, so I needed to prevent duplicate reservations without rewriting the whole application.”

Action and setback: “My first patch disabled the submit button and remembered the last request in browser storage. A teammate showed that a second laptop still created duplicates. I had treated the visible click as the boundary instead of the server operation. I wrote a replay that lost the first response, then retried the same command. We agreed to put the command identity and reservation result in one database transaction. I implemented that handler and conflict checks; my teammate reconciled old duplicates. We paused the affected flow during rollout and kept manual reservations available.”

Result and reflection: “In the next observed window we recorded two duplicate reservations among 1,200 requests. Both came from an older client that generated a new command ID on retry, so I added version checks and a documented retry contract before calling the work complete. The observed duplicate rate moved from 3% to about 0.17%. These were different event windows, so I would not claim a controlled causal estimate. I learned to test lost responses and alternate clients before shipping a UI-only fix.”

The answer gives ownership a boundary and includes a failed idea. It connects customer impact to a specific technical decision rather than asserting that the candidate “showed all the principles.” The sample's 94.4% relative rate reduction is arithmetic from fictional windows, not evidence of a real business outcome.

Follow-ups that expose a weak story

Probe	Evidence the sample can provide	Gap to address in your own story
What did you personally do?	Handler, replay, conflict checks and retry contract	Separate your contribution from teammates' work
Why not keep the button fix?	Another client bypassed it; lost-response replay reproduced the defect	Give a concrete rejected alternative
Who was affected?	Duplicate reservations and manual fallback	Name user impact without inventing revenue
What does the metric mean?	27/900 versus 2/1,200; different windows	Retain denominator, duration and measurement limits
What remained wrong?	Old client created new IDs	Explain residual failure and the follow-up owner

This evidence can support discussion of Ownership, Dive Deep, Earn Trust and quality. It does not prove which principles a particular interviewer will assign or how Amazon will score the answer. If your own project has no numerical measure, use an observable result, such as a reproduced failure no longer occurring, and describe the limits honestly.

Five sessions with reviewable outputs

Session	Work	Output to keep
1	Solve two coding prompts aloud and review failures	Contract, invariant, code and three boundary tests
2	Implement the cart before looking back at the sample	Object sketch, state trace, passing checks and one extension
3	Write six true stories and probe ownership	Evidence cards with action, alternatives, result and limits
4	Run a mixed coding/design/behavioral mock	Notes on every assumption or rescue the reviewer supplied
5	Repeat the weakest task and check invitation details	Corrected solution and recruiter-specific logistics checklist

A weak round is a reason to identify a specific gap, not infer a hidden verdict. Keep the next conversation focused on its stated task. After the loop, record completed sessions and the recruiter's promised update; ask about the next operational step if that date passes.

Frequently asked questions

How many rounds are in an Amazon SDE 1 loop?

The public student route names an online assessment and possible virtual interviews, without one universal SDE 1 round count. Confirm your hiring channel, sessions and competencies with the recruiter.

Does every SDE 1 interview include system design?

The official preparation topics include object-oriented design and distributed computing, but the page does not establish the same dedicated design round for every SDE 1 invitation. Prepare a small coherent design and confirm expected depth.

How should I prepare Leadership Principles examples?

Build several true stories from projects, internships, coursework or other work. Keep personal action, alternatives, evidence, failure and reflection separate; never adopt the fictional story in this guide as your own.

Does the cart example implement production checkout?

No. It implements a single-threaded, in-memory cart and an immutable price quote. Inventory, payment, persistence, concurrent commands and distributed idempotency remain separate extensions.

When should I expect an interview result?

The official student and graduate SDE page says the team will provide the result within five business days after the interview. That is guidance for that route; use the written recruiter update for your own requisition.

Sources and scope

• Amazon student and graduate SDE roles: published university route and result timing.
• Amazon software-development interview topics: relevant fundamentals and recruiter-specific preparation.
• Amazon interview loop: individual interviews and differing competency assessments.
• Amazon Leadership Principles: official descriptions underlying behavioral preparation.

Checked October 8, 2026. The cart and behavioral story are original illustrative material. Local execution verifies the single-process cart's stated behavior; it does not exercise a database, concurrent devices, inventory or payment. The current invitation controls actual assessment format and tools.