Amazon software development engineer interview guide

Use Amazon's official SDE II process without overgeneralizing it

The public SDE II page is precise, but its scope matters.

Amazon describes the SDE II path as application, online assessment, interview loop, and result. The online assessment includes 90 minutes for two technical questions, followed by about 20 minutes of system design scenarios and an 8-minute multiple-choice work-style survey connected to the Leadership Principles. The interview loop includes four conversations of 55 minutes each.

Those details are confirmed for the public SDE II preparation page. University, internship, specialist, senior, and country-specific processes can differ. Compare your invitation with this baseline and ask the recruiter which parts apply. Do not quietly assume that a candidate report for another level describes your loop.

Make a one-page stage map. For each stage, record the official format, the skill being evaluated, your strongest evidence, and the failure mode you want to avoid. The result should tell you whether the next practice hour belongs to coding, design, Leadership Principles, or interview logistics.

• Confirm whether your assessment matches the public SDE II format.
• Ask which coding environment and programming languages will be available.
• Confirm whether low-level design, high-level design, or both are expected for your level.
• Use recruiter instructions as the final authority when the public page and invitation differ.

Prepare for the online assessment as three different signals

The coding questions, design scenarios, and work-style survey test different kinds of judgment.

For coding, practice completing two problems in one 90-minute session. Budget time to understand the task, implement a correct solution, test it, and revisit complexity. Amazon's guidance emphasizes scalable, robust, well-tested code and warns candidates to check edge cases and bad inputs. A solution that passes the happy path but has no validation or explanation is incomplete preparation.

For system design scenarios, rehearse decisions rather than diagrams. Clarify the goal, identify the most important constraint, compare plausible choices, and state the operational consequence. For the work-style survey, answer consistently and honestly. Study the Leadership Principles to understand Amazon's language, but do not try to reverse-engineer a fake personality.

• Run timed practice in the same language you intend to use.
• Write explicit tests for empty, minimal, duplicate, large, and malformed inputs.
• Review runtime and space costs after correctness, then identify a practical optimization.
• Read all current Leadership Principles and attach each to real work evidence rather than slogans.

Write code Amazon can evaluate as production-minded

Amazon explicitly says to expect syntactically correct code, not pseudocode.

Start by clarifying the contract: input shape, ordering, duplicates, mutability, expected scale, and error behavior. Describe a straightforward solution and its cost. Optimize only after you can explain why the first approach will not meet a stated constraint. During implementation, use names and structure that make correctness visible.

Testing is part of the interview answer. Walk through the code with a normal case, then attack its assumptions. Check boundaries, invalid inputs, overflow or resource risk where relevant, and behavior under repeated calls. If the prompt changes, identify the smallest part of the design that must change rather than rewriting everything without a plan.

Candidate reports often focus on which algorithm appeared. The more durable signal in Amazon's own guidance is code quality under follow-up: logical structure, maintainability, testing, complexity, and the ability to improve a working solution. Practice those behaviors across several problem families instead of memorizing company-tagged answers.

Design for the objectives Amazon names

Amazon tells SDE II candidates to expect at least one software system design question.

Its public objectives are practicality, accuracy, efficiency, reliability, optimization, and scalability. Use those as a review checklist after you establish requirements. A design is not practical if it ignores the team that must operate it. It is not accurate if the data contract is vague. It is not reliable if failure detection and recovery are absent.

Start with the customer-facing or business outcome. Define core requests and data ownership, estimate load, and draw the simplest end-to-end path. Go deeper where the constraints demand it: consistency, hot partitions, queues, retry storms, regional failure, security, cost, or migration. Explain how the service is monitored and how it degrades when a dependency fails.

Expect the interviewer to challenge the design. Ask questions that validate it, as Amazon's guide recommends. When a new constraint arrives, revisit the affected decision and name the tradeoff. Defending every original choice is weaker than improving the system with clear reasoning.

• Customer and use cases before components.
• Data model, API contract, and ownership before technology brands.
• Capacity and bottlenecks before generic horizontal scaling.
• Failure, security, observability, and rollout before declaring the design complete.

Build Leadership Principle stories with evidence and tension

Amazon says a significant portion of the conversation focuses on past behavior and that each interviewer typically asks two or three behavioral questions.

Create an evidence bank of eight to ten stories. Cover customer impact, ownership beyond your assigned task, a decision made with incomplete information, a difficult disagreement, a failure, a high standard that required rework, a simplification, mentoring, and a result delivered under constraint. One strong story can support several principles, but the angle and evidence should change with the question.

Use STAR to make the chronology clear, then add the details Amazon's follow-ups tend to expose: what you personally decided, which data you used, what another person believed, what risk you accepted, and what measurable result followed. Include a real lesson. A failure story that ends with no changed behavior is only an incident summary.

Do not force every sentence to quote a principle. The interviewer needs credible behavior, not brand recitation. State the customer or operational stakes, keep team context concise, spend most of the answer on your actions, and be ready to distinguish your contribution from the group's.

Use a focused Amazon SDE preparation week

Give coding, design, and behavioral evidence separate practice time because the official process evaluates all three.

• Day 1: confirm your level-specific process and map the job description to technical and Leadership Principle signals.
• Day 2: complete a 90-minute two-question coding simulation with runnable code and full tests.
• Day 3: review the failed cases, redo one solution cleanly, and practice complexity plus optimization follow-ups.
• Day 4: run a system design interview using Amazon's six named objectives as the final critique.
• Day 5: draft eight STAR stories with numbers, decisions, disagreement, failure, and lessons.
• Day 6: complete four shorter mock conversations that alternate technical and behavioral questions.
• Day 7: rehearse openings and follow-ups, test the setup, review concise notes, and rest.