A round-by-round map of Amazon software engineer interview questions for the OA, technical loop, and Bar Raiser — plus what changes for SDE 1 and SDE 2, which L
Most candidates preparing for Amazon software engineer interviews spend the first two weeks grinding LeetCode as if the whole process is one long coding test. Then they walk into the Bar Raiser and realize, too late, that the interviewer isn't asking about binary search — they're asking why you pushed a decision through when your team disagreed. The mismatch isn't a knowledge gap. It's a structure gap. Amazon software engineer interview questions are fundamentally different depending on which round you're in, and the moment you stop treating all three rounds as the same problem, the prep actually becomes manageable.
The online assessment wants speed and pattern recognition. The technical loop wants clean reasoning under follow-up pressure. The Bar Raiser wants evidence that you own your decisions and can back them up with specific outcomes. Three different signals, three different kinds of weak answers, three different things to study. This guide maps the question types round by round so you can sequence your prep instead of grinding everything at once and hoping it sticks.
Why Amazon Software Engineer Interview Questions Change So Much by Round
Why the OA, Technical Loop, and Bar Raiser Are Three Different Games
Each round in Amazon's interview loop is designed to surface a different signal, which means each round punishes a different kind of underprepared candidate. The OA punishes slowness and pattern unfamiliarity — if you can solve the problem but need 45 minutes to do it, you've already lost. The technical loop punishes candidates who can code but can't explain their choices: an interviewer who asks "why not a heap here?" and gets silence has learned something damaging about how you think. The Bar Raiser punishes vagueness and borrowed narratives — answers that sound correct in the abstract but fall apart the moment the interviewer asks for the specific metric or the actual decision point.
The instinct to treat all three as "coding interviews" is understandable, but it's expensive. Candidates who over-index on DSA for the Bar Raiser spend hours that should have gone into behavioral story development. Candidates who over-index on leadership storytelling for the OA show up unprepared for a timed algorithmic test. The prep plan has to match the round, not just the company.
How SDE 1 and SDE 2 Get Judged on Different Floors, Not Different Planets
Amazon uses the same interview system across levels, but the bar shifts in three specific ways as you move from SDE 1 to SDE 2: independence, depth, and ambiguity tolerance. An SDE 1 candidate who gives a technically correct answer with some prompting is generally fine. An SDE 2 candidate who needs that much scaffolding is signaling a problem — the expectation is that you can decompose the problem, identify the tradeoffs, and defend your choices without the interviewer doing half the work.
This matters practically because it changes which parts of prep deserve the most time. SDE 1 candidates should front-load coding fluency and a handful of strong LP stories. SDE 2 candidates need all of that plus the ability to reason through system design decisions out loud, handle the follow-up without flinching, and demonstrate ownership at a level that's visible in the story — not just claimed in the framing. According to Amazon's publicly documented interview process, the loop is designed to evaluate candidates against the role level, not against each other, which means the same question can produce a pass at SDE 1 and a flag at SDE 2 depending on how much depth the answer shows.
Amazon Software Engineer Interview Questions in the Online Assessment
What the OA Is Really Measuring When the Timer Starts
The Amazon OA is not a deep technical evaluation. It's a filter. The goal is to identify candidates who can produce correct, efficient code under time pressure — typically two algorithmic problems in 90 minutes, sometimes with an additional work simulation or debugging section. What the OA is actually measuring is whether your pattern recognition is fast enough to classify the problem quickly, because the candidate who spends 20 minutes figuring out that a problem is a sliding window problem has already spent too long.
A beautiful solution submitted with two minutes left is a much worse signal than a clean, readable solution submitted with 20 minutes to spare. Speed is not incidental here — it's part of the signal. The OA is asking: can this candidate produce working code without extended deliberation? That's a prerequisite for the technical loop, not a replacement for it.
Which DSA Patterns Show Up First When Amazon Wants a Fast Signal
Based on publicly documented candidate reports compiled by prep communities like NeetCode and Blind, the OA skews heavily toward a small set of patterns: arrays and hash maps, two pointers, sliding window, basic tree traversal, and binary search. A representative OA-style prompt looks like this: given an array of integers and a target sum, return the indices of the two numbers that add up to the target. The optimal path is a single hash map pass — O(n) time, O(n) space. A candidate who reaches for nested loops is signaling they haven't internalized the pattern.
These patterns show up first because they're fast to write, fast to verify, and fast to evaluate. They're not trivial — getting the sliding window boundary conditions right under pressure is a real test — but they're also not the hardest problems Amazon ever asks. The OA is a speed and fluency check, not a creativity test.
What a Weak OA Answer Looks Like Even When It Passes Some Tests
Passing some test cases is not the same as solving the problem. A candidate who writes a brute-force O(n²) solution that passes 8 of 10 test cases has given Amazon a clear signal: they recognized the problem type but couldn't optimize it under pressure. The hidden test cases on most OA platforms are specifically designed to catch solutions that work for small inputs but break on large ones, edge cases like empty arrays, or inputs with duplicate values.
The other failure mode is a solution that's technically correct but unreadable — no variable names that mean anything, no obvious structure, logic buried in a single dense block. Amazon interviewers who see OA code before the loop sometimes use it as a starting point for follow-up questions. If the code doesn't communicate intent, that's a problem before the technical loop even starts.
Amazon Software Engineer Interview Questions in the Technical Loop
Why the Technical Loop Rewards Clean Thinking More Than Flashy Tricks
The technical loop is where the interview becomes a conversation, and that changes everything. An interviewer can watch you think, ask why you made a choice, and redirect you if the first approach isn't working. Candidates who've prepared only for isolated problem-solving often struggle here because they've never had to explain their reasoning out loud while also writing code. The skill being tested isn't just whether you can solve the problem — it's whether you can solve it while communicating clearly enough that someone else could follow your logic in real time.
The interviewers are also trained to probe. If you say "I'll use a hash map here," expect "why not a set?" or "what's the tradeoff?" The candidate who can answer that question fluently — not perfectly, but fluently — is demonstrating the kind of thinking Amazon actually wants on a team. The candidate who freezes or says "I just thought it would be faster" without being able to quantify it has exposed a gap.
Which Coding Patterns Matter Most Once the Interviewer Starts Pushing Back
The technical loop goes deeper than the OA, which means the patterns that survive follow-up pressure are the ones worth prioritizing: graphs (BFS/DFS), recursion and backtracking, trees (including binary search trees and tries), basic dynamic programming (memoization, common subproblems), and string manipulation. A concrete example of how escalation works: you're asked to find all paths in a graph from source to destination. You write a DFS solution. The interviewer asks: "What if the graph has cycles?" Now you need to explain visited tracking. "What if we want the shortest path?" Now you need to pivot to BFS and explain why. "What's the space complexity of your visited set?" The problem hasn't changed, but the depth required has tripled.
Candidates who know the pattern but haven't practiced explaining it under follow-up pressure tend to give technically correct answers that sound uncertain. That uncertainty is itself a signal — not a good one.
How Much System Design Depth Amazon Expects at SDE 1 Versus SDE 2
For SDE 1 candidates, system design is typically a minor component or absent entirely. What's expected is basic fluency: you should be able to explain what a REST API is, describe a simple client-server architecture, and reason about why you'd use a database versus a cache. You don't need to design a distributed system from scratch. Spending hours on Kafka and consistent hashing when you're applying for an entry-level role is a bad trade.
For SDE 2 candidates, the bar is meaningfully higher. You should be able to design a system end-to-end — API design, data modeling, scaling considerations, failure modes — and discuss tradeoffs between choices without being led. The interviewer will push on your decisions: "Why SQL and not NoSQL here?" "How does this handle 10x traffic?" You need to have thought through those questions before you're asked them. Exponent's system design prep resources document this level split clearly and are worth reviewing for the SDE 2 track specifically.
Amazon Software Engineer Interview Questions in the Bar Raiser
Why the Bar Raiser Cares Less About Perfect Code and More About Judgment
The Bar Raiser is a structural check, not a technical evaluation. It's run by a trained interviewer from outside your hiring team whose explicit job is to ensure the hire raises the bar — not just meets it. This means the Bar Raiser is evaluating whether you demonstrate the kind of judgment, ownership, and reasoning that Amazon expects at your level, using the Leadership Principles as the evaluation framework.
Smart candidates still get tripped up here because they prepare for the Bar Raiser the same way they prepare for the technical loop: they think about what to say instead of what actually happened. The Bar Raiser is specifically designed to stress-test your answers. If your story is too polished, too clean, or too obviously constructed around a template, the follow-up questions will expose it. "What would you have done differently?" "What did your manager think of that decision?" "What was the actual impact six months later?" These questions are designed to find the edge of your real experience.
Which Leadership Principles Are Most Likely to Drive the Questions
Amazon has 16 Leadership Principles, but a handful drive the majority of Bar Raiser questions for software engineer candidates. Ownership is the most common — Amazon wants to see that you take responsibility for outcomes, not just tasks. Bias for Action shows up in questions about decisions made with incomplete information. Dive Deep surfaces in questions about technical investigations or debugging stories. Disagree and Commit is explicitly tested through conflict scenarios. Customer Obsession anchors questions about tradeoffs between technical elegance and user impact.
According to Amazon's public Leadership Principles documentation, these principles are meant to guide every decision, not just interview answers. The Bar Raiser is checking whether you actually operate that way — not whether you've memorized the list.
What STAR Answers Sound Strong at Amazon Instead of Generic
Take the prompt: "Tell me about a time you disagreed with your manager." A weak STAR answer describes the disagreement in general terms, explains that you "voiced your concern," and ends with "we reached a compromise." It sounds reasonable. It tells the interviewer almost nothing.
A strong Amazon answer names the specific decision — "my manager wanted to ship without load testing because the deadline was fixed" — describes the concrete risk you identified and how you quantified it, explains exactly how you raised it (a written doc, a meeting with data, a direct conversation), and ends with a measurable outcome: "We delayed by three days, ran the test, found a bottleneck that would have caused a 40% latency spike under peak load, and fixed it before launch." The difference isn't style. It's specificity. Amazon interviewers are trained to ask "what was the actual impact?" and a vague answer has nowhere to go when that question arrives.
Amazon Software Engineer Interview Questions You Should Expect by Level
What New Grads Should Prioritize When Time Is Tight
New grad candidates should front-load three things and skip everything else until those three are solid: core DSA patterns (arrays, hash maps, trees, two pointers, sliding window), basic coding fluency in their primary language, and three to five strong Leadership Principle stories. That's the realistic starter set. Trying to cover dynamic programming, system design, and graph theory simultaneously before the basics are fluent is how candidates walk into the OA and blank on a medium-difficulty array problem they've technically seen before.
The LP stories matter even for new grads. Amazon behavioral questions at SDE 1 are not easier — they're just asked with the understanding that your experience base is smaller. A strong story from a class project or internship that demonstrates ownership and measurable impact is worth more than a vague story from a full-time role.
What Mid-Level Candidates Need That New Grads Can Usually Ignore
SDE 2 candidates need everything on the new grad list plus three additional layers: cleaner tradeoff reasoning in technical discussions, stronger ownership stories with organizational impact, and enough system design depth to handle a full design session without hand-waving through the hard parts. The expectation isn't that you've designed every system — it's that you can reason about the ones you have designed with enough specificity that the interviewer can evaluate your judgment.
The other shift at SDE 2 is the behavioral bar for conflict and influence. "Tell me about a time you influenced without authority" is a much harder question when the interviewer expects you to describe cross-team dynamics, competing priorities, and a measurable outcome — not just a conversation where someone eventually agreed with you.
How Career Switchers Should Prepare Differently From Candidates With Big-Tech Experience
Career switchers face a specific asymmetry: they often have strong problem-solving instincts and domain knowledge but weaker coding fluency and less structured storytelling experience. The prep priority for a career switcher is consistency — demonstrating that the coding ability is real and repeatable, not a one-time performance. That means more timed practice, more mocks, and more deliberate focus on writing clean code under pressure rather than just solving the problem.
Experienced candidates from other big-tech companies face the opposite challenge: they have the fluency but often need to recalibrate their stories for Amazon's specific LP framing. A story that landed well at Google may not map cleanly to Amazon's Ownership or Dive Deep principles without deliberate restructuring. The prep work there is translation, not invention.
Amazon Software Engineer Interview Questions: How to Study Without Wasting Time
What to Study First if You Have 7 Days
Seven days is enough to be competitive if you spend them correctly. Days one through three should go entirely to OA patterns: arrays, hash maps, two pointers, sliding window, and basic tree traversal. Do timed problems — 45 minutes per problem, no hints, then review. Days four and five should go to behavioral stories: pick five LP stories from your actual experience, write them out in full STAR format, and practice saying them out loud until they sound natural, not recited. Days six and seven should go to one technical loop mock — either with a partner or using a platform that gives real-time feedback — and a light review of system design basics if you're targeting SDE 2.
What to skip: dynamic programming beyond memoization basics, graph algorithms beyond BFS/DFS, and any system design depth that's above your target level. Seven days is triage, not mastery.
What Changes if You Have 14 Days or 30 Days
Fourteen days allows you to add repetition and refinement on top of the seven-day foundation. The second week should go to harder coding problems in the same patterns (not new patterns), LP story refinement based on what felt weak in practice, and a second mock with more specific feedback. The goal isn't to cover more ground — it's to make the ground you've already covered more reliable under pressure.
Thirty days allows genuine depth: more complex graph and DP problems, full system design sessions, and multiple rounds of behavioral mock interviews with specific feedback on story structure and outcome specificity. At 30 days, you also have time to read actual candidate debriefs — posts on Blind, Leetcode discuss, or engineering blogs — to calibrate your expectations for what the real questions sound like.
The Questions You Should Skip Until the Basics Stop Wobbling
The low-return areas candidates consistently overstudy: advanced DP problems (segment trees, bitmasking, complex state machines), obscure edge-case trivia about language internals, and system design depth that's two levels above the target role. These areas feel productive because they're hard, but they're a bad trade when the OA is going to test whether you can write a clean sliding window solution in 30 minutes.
The test for whether a topic deserves time: can you solve a medium-difficulty problem in the core patterns reliably, under time pressure, and explain your choices out loud? If the answer is no, everything else can wait.
How Verve AI Can Help You Ace Your Software Engineer Coding Interview
The specific failure mode that kills Amazon technical loop performance isn't running out of knowledge — it's running out of time to think clearly while also explaining yourself out loud. That's a practiced skill, not a studied one, and the only way to build it is to do it repeatedly under conditions that feel real.
Verve AI Coding Copilot is built for exactly that gap. It reads your screen in real time during practice sessions — whether you're working on LeetCode, HackerRank, CodeSignal, or a live technical round — and surfaces contextual suggestions based on what you're actually writing, not a canned hint. The Secondary Copilot feature lets you stay locked on a single problem longer, working through follow-up complexity the way a real interviewer would escalate it, rather than jumping to the next problem the moment you hit friction. Verve AI Coding Copilot suggests approaches live without breaking your flow or requiring you to switch windows, which means the practice session stays as close to the real interview condition as possible. For Amazon prep specifically, that means you can drill the exact pattern — write the solution, explain the tradeoff, handle the follow-up — in a single continuous session rather than treating coding and communication as separate skills. The tool tracks your reasoning in context, which is the part of the technical loop most candidates never actually practice.
Stop Studying Amazon Like One Big Test
The candidates who walk out of Amazon loops feeling underprepared almost always have the same debrief: they knew the material but didn't know which material mattered when. The OA, the technical loop, and the Bar Raiser are three different evaluations running inside the same process, and each one rewards a different kind of preparation.
The next step isn't to study more. It's to study in the right order. Start with the OA patterns. Add the behavioral stories. Layer in system design only where your level actually demands it. Then mock the whole sequence — not just the coding problems, but the follow-ups, the LP questions, and the full loop — until the round transitions stop feeling like surprises. That's what round-by-round prep actually looks like, and it's a much shorter path to ready than grinding every Amazon software engineer interview question you can find and hoping the right ones show up.
Alex Chen
Interview Guidance
