Amazon's SDE interview is one of the most structured in tech — every question maps to a Leadership Principle, and the Bar Raiser is specifically tasked with filtering out "acceptable" candidates. Here are 25 real questions across the four rounds, with answers that land.
Quick Facts
Questions25 real questions
Rounds5–7
ATS SystemAmazon custom
Updated2026
The Amazon SDE Interview Process
Amazon's software engineering loop is deliberately standardised so that every interviewer is evaluating a different Leadership Principle. There are four distinct phases:
Recruiter / phone screen (30 min): A talent acquisition partner confirms your background, level fit (SDE I, SDE II, senior), and compensation expectations. Some teams skip this and jump straight to the online assessment.
Online assessment — OA (70–90 min): Two LeetCode-style coding questions on HackerRank. You submit working code; the system runs hidden test cases. You typically have 7 days to complete once the link is sent.
Virtual onsite loop (4–5 rounds, same day or spread over 2 days): Each 55-minute round is run by a different interviewer. Most rounds include 1–2 behavioural questions plus a coding or system design exercise. Interviewers submit independent feedback before the debrief.
Bar Raiser debrief: The loop interviewers and the Bar Raiser meet to discuss each candidate against Amazon's standard, not just whether the candidate is better than average for the team. Unanimous strong recommendation is rare; the debrief is a genuine calibration session.
For SDE I and intern roles, the system design component is lighter or absent. SDE II and senior candidates should expect at least one full system design round in addition to two or more coding rounds.
What the Bar Raiser Actually Does
The Bar Raiser is one of the most misunderstood parts of Amazon's process. Here is what you need to know:
They are not your manager or skip-level. The Bar Raiser is a trained senior Amazonian from a completely different team — often a different org. They have no stake in filling your team's headcount.
They have effective veto power. A Bar Raiser can block a hire even if every other interviewer gives a strong recommendation. The reverse is also true: a Bar Raiser's strong endorsement can override a split loop.
They are evaluating whether you raise the bar of the team, not just whether you clear a pass/fail threshold. Amazon's stated principle is that every hire should raise the average quality of the team. A candidate who is "as good as the current team" is a no-hire by design.
You will not know who the Bar Raiser is. They look and act like any other interviewer. The only tell is that they may probe harder on specific LP stories or push back more on answers they find too polished.
The practical implication: prepare your STAR stories to withstand follow-up. Amazon interviewers are trained to ask "What would you have done differently?" and "Why did you make that choice instead of X?" If your story only works at the surface level, the Bar Raiser will find the seams.
SDE I vs. SDE II vs. Senior — How the Bar Differs
SDE I: Expected to solve well-defined problems with guidance. Behavioural stories can be from internships, academic projects, or early career. Technical bar is LeetCode Easy–Medium. SDE II: Expected to own a service or feature end-to-end. Stories should show independent impact and some degree of cross-team collaboration. Technical bar is LeetCode Medium–Hard plus basic system design. Senior SDE: Expected to influence beyond direct scope — setting technical direction, mentoring, and driving multi-team outcomes. System design is a full round; behavioural bar is significantly higher and your stories should involve ambiguity and trade-offs, not just execution.
The Online Assessment (OA)
Amazon's OA is delivered through HackerRank and is timed. The format for SDE roles is typically two algorithmic problems in 70 minutes, plus an optional work style survey (not scored as pass/fail). Key things to know:
Focus area is LeetCode Medium. Expect problems involving arrays, hash maps, trees, graphs, and dynamic programming. Hard-level problems do appear for senior roles.
All test cases must pass. Partial credit exists in some configurations, but the hiring signal is weighted toward full pass rates. Optimize after you have a working solution, not before.
Time management matters more than elegance. A brute-force O(n²) solution that passes all test cases is better than an incomplete O(n log n) solution.
The OA result is not the only factor. A borderline OA can still lead to a loop invite, especially if the recruiter has a strong read from the phone screen. Conversely, a perfect OA does not guarantee a loop.
Common OA topics: sliding window, two pointers, BFS/DFS, heap-based priority queues, and string manipulation. Review these categories specifically, not the full LeetCode catalogue.
Behavioural Questions — LP-Mapped
Every behavioural question at Amazon is designed to surface a specific Leadership Principle. Below are eight high-frequency questions with the LP they target, why Amazon asks them, and a realistic STAR answer. These are not model answers to copy verbatim — they are calibration points to help you build your own specific stories at the right level of detail.
LP: Customer Obsession
Tell me about a time you went significantly beyond what was expected to deliver for a customer or end user.
Why Amazon asks this: Customer Obsession is LP #1 for a reason. Amazon wants engineers who build for the customer's actual experience, not just the requirements document. They are testing whether you have a genuine customer instinct or just compliance with ticket specs.
STAR Answer
During a mobile checkout redesign at my previous company, user research showed our payment error rate was 8% — users were abandoning carts after entering card details. My task was to implement a new error-state UI. I noticed the underlying problem wasn't just UI: we were sending a generic "card declined" message when the real issue was an expired billing address on file. I proposed a targeted fix: detect the specific Stripe error code, surface a pre-filled address update form inline, and re-attempt automatically. I built a prototype in a weekend, demoed it to the PM, and got it fast-tracked. After release, cart abandonment at that step dropped from 8% to 2.1%. The customer never had to re-enter their card — they just confirmed their address in two taps.
LP: Ownership
Describe a time you took responsibility for a problem that was not strictly within your scope.
Why Amazon asks this: Amazon engineers are expected to act like owners of the whole system, not just their service boundary. The LP test here is whether you stepped up when it was inconvenient, not just when it was assigned to you.
STAR Answer
Our team's downstream partner had a flaky data pipeline that was causing intermittent failures in our recommendation engine. Officially, it was their bug to fix. But their team was under-resourced and the issue had been open for three weeks, causing silent data gaps in production. I pulled the pipeline logs myself, identified that the failures occurred on batch files over 500 MB due to a timeout misconfiguration, and wrote a patch for their ingestion script — even though I'd never touched their codebase. I opened a PR in their repo, wrote a clear description so their on-call could approve it without context, and paired with their lead for 20 minutes to walk through the fix. The pipeline stabilised within 24 hours. I didn't ask permission; I asked if the help was welcome, and it was.
LP: Invent and Simplify
Tell me about a time you found a simple solution to a problem others thought was complex.
Why Amazon asks this: Amazon penalises over-engineering. This LP question tests whether you default to clever complexity or whether you actively look for the path with fewer moving parts. The interviewer is watching for intellectual honesty about trade-offs.
STAR Answer
We had a scheduled job that generated PDF reports for clients. It was an elaborate microservice with a message queue, a dedicated worker fleet, and a retry manager — and it still failed about 3% of the time due to race conditions. The team's instinct was to add a distributed lock. I stepped back and looked at the actual load: 200 reports per day, average 4 seconds each. There was no concurrency problem — the worker fleet was oversized. I proposed replacing the entire pipeline with a single Lambda function triggered by S3 events, with dead-letter queue retry. Total infrastructure: one Lambda, one SQS queue, one S3 bucket. We decommissioned four EC2 instances, reduced infrastructure cost by roughly 60%, and the failure rate dropped to near zero. Simpler systems fail less often.
LP: Dive Deep
Tell me about a time you had to dig into data or technical details to understand a problem that wasn't obvious on the surface.
Why Amazon asks this: Amazon leaders are expected to be able to operate at all levels — strategy and implementation. For SDEs, this LP tests whether you are comfortable going below the abstraction layer when a problem demands it.
STAR Answer
We saw a sudden 15% latency increase in our search API three weeks after a dependency upgrade. No obvious code change corresponded to it. I started by pulling CloudWatch metrics and confirmed the latency was in our service, not upstream. I then added granular timers to each internal step and found the culprit: our serialization library was now calling reflection on every object field at request time, whereas before it had cached field metadata after the first call. The upgrade had changed the caching behaviour due to a subtle config flag that defaulted differently in the new version. I raised a targeted fix — passing an explicit cache configuration — rather than rolling back the entire dependency. Latency returned to baseline within one deployment, and I filed a bug report with the library maintainers documenting the behaviour change.
LP: Deliver Results
Tell me about a time you delivered a project under significant time or resource pressure.
Why Amazon asks this: Amazon moves fast and expects SDEs to ship even when conditions aren't ideal. This question distinguishes candidates who deliver from those who explain why delivery was blocked.
STAR Answer
Two weeks before a major product launch, our third-party payments vendor notified us they were deprecating the API version we used, effective the day of launch. Our integration team was already at capacity. I volunteered to own the migration. I audited every touchpoint in our codebase — 11 files across three services — and built a migration plan with two parallel tracks: a feature-flagged new integration in production, and a hard cutover script for launch day in case the gradual rollout revealed issues. I worked evenings for eight days, ran the integration in staging against live sandbox, and documented every edge case. We launched on time with the new API, with zero payment failures in the first 48 hours. The vendor's deprecation was a genuine threat and we treated it as one.
LP: Earn Trust
Tell me about a time you made a mistake and how you handled it.
Why Amazon asks this: This is a direct integrity test. Amazon wants to see that you surface mistakes quickly, take ownership without deflecting, and put a corrective process in place so it does not recur. Polished non-answers fail this question every time.
STAR Answer
I deployed a database migration script to production with a WHERE clause scoped incorrectly — I had tested it against a staging database whose seed data happened to match my condition perfectly. In production, the script updated 3,400 records it shouldn't have touched, corrupting a status field used in billing. I noticed the spike in incorrect billing events within 20 minutes via an alert I'd set. I immediately reverted using our point-in-time restore, notified my manager and the finance team before I had a full diagnosis, and spent the next hour writing a postmortem. I added a dry-run flag to all future migration scripts as a team standard, and set up a row-count assertion check that aborts if the affected rows exceed an expected threshold by more than 5%. That process has been used by the team on every migration since.
LP: Bias for Action
Describe a situation where you had to act quickly with incomplete information. What did you do, and what was the outcome?
Why Amazon asks this: Amazon operates in high-velocity environments. This LP question surfaces whether you know how to make a reversible decision quickly versus waiting for certainty that will never come.
STAR Answer
During an on-call shift, our API error rate jumped from 0.2% to 14% at 2 AM on a Saturday. I had partial telemetry — logs showed HTTP 500s from one specific service, but the root cause wasn't clear from the initial stack trace. Rather than waiting for the full picture, I made a calculated decision to roll back the last deployment, which had gone out six hours earlier. It was a reversible action with low risk. Error rate dropped to baseline within 90 seconds. I then spent the next two hours in a non-live environment reproducing the bug — a race condition in a new async handler under concurrent load. I wrote the fix, had it reviewed by another engineer the next morning, and deployed it with targeted load testing. The post-incident review confirmed the rollback was the right first move given what I knew at the time.
LP: Think Big
Tell me about a time you proposed or worked on something with a scope significantly larger than your immediate team or project.
Why Amazon asks this: Amazon wants engineers who think beyond their sprint backlog. This LP tests strategic vision — your ability to see where a system or product could go, not just where it is today.
STAR Answer
I was working on an internal developer tooling team and noticed that five different product squads had each built their own feature-flag system — all slightly different, none of them auditable, two of them with known security gaps. Instead of fixing our team's version in isolation, I wrote a one-page proposal for a shared feature-flagging platform with a centralised audit log, role-based access, and a gradual rollout SDK that all teams could adopt. I presented it to the VP of Engineering at a monthly all-hands. It was approved as a Q3 initiative. I led a working group of engineers from four squads, and we shipped a version used by all six product teams within five months. The consolidation also helped with SOC 2 compliance — a company-level requirement we were behind on.
Technical and System Design Questions
Amazon SDE interviews include coding questions in every round plus one dedicated system design round for SDE II and senior levels. Below are the five most common technical prompts, with framing on what Amazon is actually evaluating. Full solution walkthroughs and follow-up question banks are available through Interview Intel.
1. Design a URL Shortener
A classic system design starter. Amazon interviewers use this to probe your understanding of hashing, collision handling, database choice (SQL vs. NoSQL), and read-heavy scaling patterns. They will push toward questions like: how do you handle 100 million URLs? How do you ensure global low-latency redirect? What happens when the same long URL is submitted twice? Structure your answer with: requirements clarification, capacity estimation, API design, data model, then component-by-component deep dive.
2. Design a Rate Limiter
Rate limiters are core infrastructure at Amazon scale. This question tests your knowledge of token bucket vs. leaky bucket vs. sliding window algorithms, distributed state management, Redis use cases, and how to handle edge cases like clock skew in distributed systems. A strong answer discusses the trade-off between exactness (sliding window) and performance (fixed window), and how to handle multi-region deployments without introducing a central bottleneck.
3. Design a Distributed Caching Layer
Amazon runs systems at a scale where a cache miss has real cost. This question evaluates your understanding of cache eviction policies (LRU, LFU, TTL), cache invalidation strategies, write-through vs. write-behind patterns, and consistency trade-offs. Expect follow-ups: what happens during a cache partition? How do you avoid thundering herd on a cold start? How do you monitor hit rate in production?
4. LeetCode Coding: Trees and Graphs
Amazon's OA and coding rounds heavily feature tree traversal, BFS/DFS on graphs, and matrix problems. Common patterns: serialize/deserialize a binary tree, find the lowest common ancestor, detect a cycle in a directed graph, and word ladder shortest path. For each problem, state your approach before coding, walk through your time and space complexity, and mention edge cases before the interviewer prompts you.
5. Debugging a Production Issue (Live Debugging Round)
Some teams run a live debugging round where you are given a code snippet or a system description with a bug. This evaluates your ability to form hypotheses, isolate variables, and communicate your reasoning out loud. The answer matters less than the method. Amazon interviewers want to see systematic thinking: reproduce, isolate, hypothesize, verify, fix, prevent. Avoid jumping to conclusions before you have evidence.
Role-Specific Questions for SDEs
Beyond coding and system design, Amazon interviewers will ask questions that probe your day-to-day engineering judgment. Here are four common ones:
How do you approach a code review?
Amazon expects SDEs to be thorough reviewers. A strong answer covers: what you look for first (correctness, then edge cases, then style), how you give feedback that is specific and actionable rather than vague, how you handle disagreements with the author, and how you balance review quality against review speed. Mention that you look for both what the code does and what it assumes about the caller's behaviour.
How do you decide between two competing technical approaches?
Amazon's culture of "disagree and commit" means technical decisions are made explicitly, not by default. A strong answer names the dimensions of the trade-off (complexity, latency, cost, maintainability, reversibility), explains how you weight them for the specific context, and describes how you document the decision — a lightweight Architecture Decision Record (ADR) is a signal the interviewer will respond to well.
Tell me about a production incident you owned end to end.
This is essentially a combined Ownership + Dive Deep question applied to engineering practice. Structure your answer: detection (how did you know?), immediate mitigation (what did you do in the first 15 minutes?), root cause analysis (what did you find and how?), and prevention (what changed as a result?). The last part is what separates strong candidates — Amazon wants to see that you treated the incident as a system failure, not a one-off event.
How do you ensure code quality when the team is under delivery pressure?
This tests your technical leadership instincts. Amazon values speed but not at the cost of long-term system health. A strong answer acknowledges the real tension, describes how you triage quality practices (what can be deferred, what cannot), and gives a concrete example of a time you pushed back on a timeline or negotiated scope to preserve quality. Interviewers are watching for candidates who treat "cutting corners" as a technical debt decision with a named cost, not as a free shortcut.
Amazon SDE Compensation in Canada (2026)
Amazon compensation in Canada is structured as base salary plus Restricted Stock Units (RSUs) vesting over four years (front-loaded: 5% at 6 months, 15% at 18 months, then 40%/40% in years 3 and 4). Cash bonuses are not part of the standard SDE offer; the equity component is where total compensation diverges significantly from base.
SDE I (Vancouver/Toronto): Base $120,000–$160,000 CAD. RSU grant typically $80,000–$120,000 USD over four years.
SDE II: Base $160,000–$220,000 CAD. RSU grant typically $150,000–$250,000 USD over four years.
Senior SDE (L6): Base $220,000–$300,000 CAD. RSU grants vary widely based on performance history and negotiation; $300,000–$600,000 USD over four years is a reasonable range for strong hires.
These figures reflect market rates as of early 2026 and will vary by team, negotiation, and location. Vancouver-based roles (particularly AWS) tend to be at the higher end of the CAD base range. Always negotiate — Amazon's initial offers are rarely the ceiling, particularly on RSU grants.
Get questions tailored to your specific interview
Interview Intel generates 20–30 questions for your exact company and role — with STAR answers, the compensation playbook, and 7–10 questions to ask. Free preview in 60 seconds.
How long does the Amazon SDE interview process take end to end?
End to end, the process typically takes 4–8 weeks. The online assessment is usually scheduled within 1–2 weeks of the recruiter screen. The virtual onsite loop follows 1–3 weeks after that. Offer decisions are typically communicated within 5 business days of the loop completing. Intern timelines can be tighter — some move from OA to offer in under three weeks during campus recruiting season.
Is the Bar Raiser always included in Amazon SDE interviews?
Yes, for virtually all full-time hires. Amazon's Bar Raiser program is a company-wide standard, not a team-by-team option. The Bar Raiser round is embedded in your onsite loop — you will not know which interviewer holds that role. Intern conversions to full-time sometimes follow an abbreviated process, but direct SDE I through senior hires almost always include a Bar Raiser.
Which Leadership Principles come up most in Amazon SDE interviews?
For SDE roles, the most tested LPs are Customer Obsession, Ownership, Invent and Simplify, Dive Deep, and Deliver Results. Earn Trust and Bias for Action also appear regularly. You should prepare a strong STAR story for all 16 LPs, but if time is limited, prioritise these seven. The Bar Raiser will specifically probe whichever LP your other stories have been thinnest on — they read the loop feedback in real time.
Does Amazon hire junior software engineers (SDE I) in Canada?
Yes. Amazon hires SDE I engineers at its Vancouver and Toronto offices, as well as for remote roles supporting AWS and other business units. The intern-to-return-offer pipeline is active at Canadian universities including UBC, UofT, Waterloo, and McGill. SDE I candidates still go through the full loop including Bar Raiser, but the behavioural bar is calibrated to early-career scope — interviewers expect stories from internships, co-ops, or academic projects, not multi-year production ownership.