Amazon SDE Interview Questions

It commonly includes two algorithmic coding problems around 70 minutes total, at roughly medium LeetCode difficulty covering arrays, strings, graphs, and dynamic programming, plus a separate work style survey aligned with the Leadership Principles.

A personality-style questionnaire presenting workplace scenarios, used to gauge alignment with the Leadership Principles before a human reviews your application further. Consistency in your answers matters more than trying to guess a desired profile.

A roughly 60-minute call split evenly between technical and behavioral, usually one medium-difficulty coding problem in the first half requiring working code and complexity analysis, and two or three Leadership Principle behavioral questions in the second half.

Usually four to five rounds of 45 to 60 minutes each, generally two coding-focused rounds, one round with a stronger behavioral emphasis, and a bar raiser round that touches multiple principles.

Generally no, system design is not a formal requirement at SDE1, and interviews focus on coding fundamentals and Leadership Principle behavioral questions instead.

Arrays, strings, hash maps, basic trees, and simple graph traversal are the most common topics, usually at a difficulty comparable to LeetCode medium problems solved with working, testable code.

Nearly every round blends both, since Amazon pairs coding with a couple of Leadership Principle questions even in technical rounds, so entry-level candidates should prepare both dimensions with equal seriousness.

A bar raiser is a specially trained interviewer, often from another team, whose job is to protect hiring quality across the company. In an SDE loop they typically run one round touching multiple principles and hold real influence over the final hiring decision.

Practice medium-difficulty problems across core data structures while narrating your reasoning out loud, since Amazon interviewers weigh your problem-solving process, beyond just whether the final code compiles and passes tests.

Amazon generally allows any mainstream language you're comfortable with, such as Java, Python, C++, or JavaScript, and interviewers are trained to evaluate logic and correctness rather than penalize your language choice.

Very important, interviewers expect you to state the complexity of your solution and discuss whether a more efficient approach exists, even at entry level, since this reflects fundamental engineering judgment.

Jumping into code before clarifying the problem or discussing an approach, which makes it hard for the interviewer to follow your reasoning if the solution goes off track partway through.

Proactively mention and test edge cases like empty input, duplicates, or boundary values without waiting to be prompted, since interviewers weigh this kind of proactive thoroughness as a real signal of engineering maturity.

Common pairings include Dive Deep, Customer Obsession, and Ownership, often phrased as a quick 'tell me about a time' question tacked onto the end of a technical round rather than a fully separate segment.

Some loops include a round that presents existing code with a bug for you to find and fix, testing your ability to read and reason about someone else's code, though this varies by team and isn't universal.

In line with Amazon's general three to six week guidance, though it can run a bit faster or slower depending on OA and loop scheduling availability for the specific team hiring.

It's typically taken independently on your own schedule within a set window, without a live interviewer watching, so treat it as seriously as a live round since a weak OA score can end your candidacy before a human review even happens.

Prepare five to seven concrete stories from school projects, internships, or personal projects, mapped loosely to a few common principles, so you can respond quickly rather than searching your memory live.

Most candidates benefit from working through 100 to 150 problems across core topics, with a strong emphasis on clearly explaining solutions out loud rather than purely maximizing problem count.

Yes, interviewers are trained to offer hints and want to see how you respond to being unstuck, so staying vocal about your thinking rather than going silent gives them something to work with.

Beyond correctness, interviewers look at clear variable naming, reasonable structure, and whether the code would be readable to a teammate, even under the time pressure of a live interview.

The OA is typically unproctored and taken independently, while the phone screen is a live conversation where communication and real-time reasoning matter as much as the final answer.

Yes, and it's expected, since jumping straight into code without confirming input constraints or expected behavior is read as a weaker signal than a candidate who scopes the problem first.

Interviewers sometimes ask you to simplify or optimize a working but inefficient solution after you've solved the basic version, testing whether you naturally look for cleaner approaches.

Walk through at least one or two test cases by hand after writing the solution, including an edge case, since interviewers want to see verification as a deliberate step rather than an afterthought.

All interviewers, including the bar raiser, submit written feedback and then meet for a debrief to reach a hiring decision together, rather than any single interviewer deciding independently.

Treat it like any other behavioral-heavy round, but expect slightly more probing follow-up questions, since the bar raiser is specifically trained to test whether your answers hold up under deeper scrutiny.

Assess your current comfort with core data structures honestly, then build a study plan mixing daily coding practice with a handful of well-developed behavioral stories, rather than focusing entirely on one dimension.

Somewhat, since specific technical stacks and problem style can differ by team, but the overall structure and difficulty band stays fairly standardized given Amazon's centralized interview training and calibration process.

Break it down methodically, starting with a brute-force approach if needed, then look for ways to optimize, since interviewers value a structured problem-solving process over instant pattern recognition.

Communication matters heavily, since Amazon interviewers are trained to assess your reasoning process as much as your typing speed, and a candidate who explains clearly while solving methodically often scores better than a silently fast one.

Most rounds now happen in a shared virtual coding environment rather than a physical whiteboard, though the expectation to reason out loud and write clear, syntactically correct code remains the same.

Set a strict 30-minute timer for one coding problem including explanation, then separately practice two or three behavioral questions in 30 minutes, mimicking the actual split structure of the real round.

Say so directly, explain what led you to realize it, and pivot to a better approach, since Amazon interviewers value the honesty and adaptability shown by course-correcting over stubbornly forcing a flawed solution to completion.

Practicing every problem with full verbal narration from the start, since this builds the specific communication skill Amazon interviewers evaluate most heavily, beyond pure algorithmic knowledge alone.

Designing a service with realistic requirements, covering data modeling, API design, basic scaling considerations, and trade-offs, with the interviewer expecting you to drive the conversation rather than wait for prompts on each area.

SDE2 problems are typically solved with less hand-holding and higher expectations around proactively discussing edge cases, alternative approaches, and complexity trade-offs without being asked directly.

SDE2 behavioral answers should show more independent ownership, such as driving a project decision without waiting for direction, rather than completing well-defined tasks handed down from someone else.

Usually four to five rounds similar in count to SDE1, but with one round now dedicated to system design and the remaining rounds carrying more technical depth per problem.

A story about investigating a production issue or metric discrepancy more thoroughly than your role technically required, uncovering a root cause others had missed or assumed was fine.

Ask clarifying questions to scope the problem, state assumptions explicitly, then design incrementally, starting with a simple version and adding complexity only as you justify the need for it.

The SDE2 answer typically reaches a working solution faster, proactively covers edge cases without prompting, and includes a clearer discussion of trade-offs between multiple viable approaches.

The format stays similar, but the bar raiser digs harder into whether the candidate's claimed scope and independence genuinely match SDE2 expectations, since inflated claims are more common and more scrutinized at this level.

Expect direct questions like choosing between a relational and NoSQL data store, or discussing consistency versus availability trade-offs, with a requirement to justify the choice against specific stated constraints.

Identify the actual bottleneck in your original design first, such as a single point of failure or a database that won't handle increased load, then propose a targeted fix rather than redesigning everything from scratch.

A story about pushing back on shipping code below the quality bar despite time pressure, and explaining the specific reasoning used to defend that standard to a manager or teammate.

SDE2 system design typically covers a single well-scoped service, while SDE3 expects a more complete design at scale involving multiple services, deeper failure handling, and broader trade-off analysis.

Jumping straight into a complex, fully scaled design without first proposing a simpler version and justifying each added layer of complexity, which makes it hard for the interviewer to follow your reasoning.

Proactively mention how you'd test the solution, including unit tests for edge cases and how you'd validate correctness at scale, rather than waiting for the interviewer to ask about testing directly.

Are Right, A Lot and Think Big often pair with system design, since interviewers want to hear the reasoning behind bold or non-obvious architectural choices, beyond a technically correct diagram.

Proactively name the design's weaknesses or trade-offs you'd revisit with more time, since self-critique shows the same judgment Amazon values in Insist on the Highest Standards and Are Right, A Lot.

A story about identifying and fixing a bug or inefficiency outside your assigned ticket because leaving it unaddressed would have hurt the system or the team, even though it wasn't formally your responsibility.

Split preparation time between coding fundamentals, system design basics like data modeling and API design, and behavioral stories that show independent, self-directed technical decisions.

Expect the interviewer to introduce a new constraint partway through, such as a much larger input size, and ask how your solution would need to change, testing flexibility and depth of understanding.

Cover the key endpoints, request and response structure, and how the API would handle errors or versioning, treating the API as a real contract other engineers would need to build against.

A story about making a reversible technical decision quickly under uncertainty rather than over-analyzing it, paired with an honest account of how that choice played out in practice.

Read through the code methodically, reason out loud about what it's supposed to do versus what it actually does, and narrow down the bug systematically rather than guessing randomly.

SDE2 shifts from demonstrating basic technical competence to demonstrating independent technical judgment, both in coding trade-offs and in a foundational system design conversation.

A complete design at scale, covering multiple services, failure handling, data consistency trade-offs, and monitoring, with the candidate expected to drive the conversation and proactively flag what they'd cut under time pressure.

SDE3 problems tend to be harder, often closer to LeetCode hard difficulty, with an expectation that the candidate reaches a working solution efficiently while discussing multiple viable approaches and their trade-offs.

A story about proposing an architectural direction that expanded beyond the original task scope, backed by a clear rationale for why the added investment or risk was justified given the broader system's needs.

The bar raiser scrutinizes whether the candidate's claimed technical scope and cross-team influence genuinely match SDE3 expectations, since title inflation becomes a bigger risk to guard against at this level.

Expect deeper questions around distributed system trade-offs, such as handling partial failures, data partitioning strategies, or the cost implications of different architectural choices at real scale.

Explicitly name the tension, such as latency versus consistency, and explain which requirement you'd prioritize and why given the stated use case, rather than trying to satisfy every requirement equally.

A pattern-level example, such as building monitoring or auditing practices into how your team operates, rather than a single investigation, showing the habit of deep technical engagement is systemic.

Through behavioral questions about driving an architectural decision when you didn't have direct authority over the teams involved, with interviewers probing specifically how you built consensus.

The SDE3 answer covers more of the system end to end, including failure and recovery handling and monitoring, and proactively identifies what would break first as load increases rather than waiting to be asked.

A story about giving direct, sometimes uncomfortable code review feedback to a peer, or admitting a design mistake publicly in a way that ultimately strengthened the team's trust in your judgment.

Shift preparation toward deeper distributed systems concepts and toward stories showing technical influence beyond your immediate team, since raw coding speed alone stops being the main differentiator at this level.

Designing a platform or system meant to support multiple teams long-term, with deep attention to extensibility, migration paths from existing systems, and the organizational cost of maintaining the design over time.

Candidates should describe a technical process, tool, or standard they created that continued working without their constant involvement, reflecting durable, systemic engineering leadership rather than a one-time contribution.

A story about setting technical direction for a whole team or org, including how the candidate built the case and secured buy-in from stakeholders with genuinely competing technical priorities.

The bar raiser presses hard on whether the candidate's technical influence genuinely extended beyond their immediate team, asking specifics about who adopted their proposals and how the impact was actually measured.

A story where the candidate took responsibility for a technical outcome outside their formal scope because it mattered for the broader system's health, following through well past any immediate urgency.

Walk through the actual trade-off calculus involving business risk, migration cost, and team capacity, being honest about what was deprioritized and why, favoring pragmatic sequencing over an idealized full rewrite.

Evidence of building technical bench strength across a team, such as running a repeatable design review practice or mentoring multiple engineers toward promotion, rather than a single mentoring relationship.

Through open scenario questions asking how the candidate would prioritize among competing technical initiatives with limited resources, probing whether the reasoning holds up under real pushback.

Focus on what actually broke as the system scaled, how the bottleneck was diagnosed, and what durable architectural change was put in place, rather than just describing adding more infrastructure.

Interviewers expect enough hands-on technical credibility to make architectural trade-off calls, paired with breadth across systems sufficient to influence decisions beyond a single team's codebase.

Given Amazon's document-driven culture, principal candidates are often asked how they've used a written design document or narrative to drive a significant technical decision across teams.

The principal version typically shows the candidate operating with less oversight, setting the technical agenda proactively, and shaping how multiple teams build and maintain their systems going forward.

Take full ownership of the outcome, explain the systemic engineering gap that allowed it to happen, and describe the structural fix that followed, since durable systemic change is the expected signal at this level.

Designing or evaluating architecture meant to serve an entire org's technical strategy, with deep attention to long-term extensibility, migration from legacy systems at scale, and the true organizational cost of adoption.

Through detailed questions about setting direction for an entire technical org, including how the candidate allocated resources across competing technical priorities and communicated that vision to both engineers and business leadership.

At this level, candidates may be asked how they weighed a major technical decision's wider impact on customers, employees, or the broader business ecosystem, beyond narrow engineering metrics.

It typically involves additional senior technical stakeholders beyond a single bar raiser, given the scope of architectural influence and compensation involved at this level of engineering leadership.

Candidates are expected to show they've built structures, such as an organization-wide design review practice or a technical career ladder, that improved how a broad group of engineers work, beyond one protege.

Name the competing needs explicitly, explain the prioritization logic applied, and design a solution addressing the most critical needs first while being honest about the trade-offs made for the rest.

The senior principal version typically shows the candidate setting the technical agenda proactively across an entire org, rather than being pulled in reactively to resolve one specific cross-team disagreement.

Still very technical, since Amazon's most senior individual contributor track values deep technical credibility alongside organizational scope, expecting candidates to engage in real architectural detail, not abstraction alone.

One where the failure revealed a systemic gap in how the org approached a class of technical problems, followed by a structural change the candidate drove that prevented recurrence beyond just their immediate team.

Through open scenarios involving genuinely conflicting technical philosophies between teams or orgs, where the candidate must show how they'd navigate the disagreement productively toward a shared technical direction.

A clear framework for evaluating debt against business risk and organizational capacity, plus a real example of sequencing a large-scale migration or cleanup across a multi-team, multi-service codebase.

With a concrete example of respectfully challenging a technical direction using data or a well-reasoned proposal, and honesty about whether that changed the outcome or led to full commitment once decided.

Structured, written-narrative-driven reasoning that leads with the key technical insight or recommendation, reflecting Amazon's broader preference for clear documentation that can persuade a skeptical, senior audience.