Amazon SDE Interview: Online Assessment, Loop and Leadership Principle Questions

The email lands on a Tuesday. A HackerRank link, a seven-day window, and a note that the 90-minute timer keeps running once it starts, even if you close the tab.

That’s how a lot of Amazon SDE interviews begin. No friendly call first. Just you, two coding problems, and a compiler that has to accept your code before a human ever reads it.

This guide covers the Amazon SDE interview end to end: online assessment, phone interviews, the loop, coding, system design and the Bar Raiser. I stick to what Amazon publishes on amazon.jobs and flag what comes from candidate reports. Leadership Principles get a shorter treatment here, since our guide to Amazon behavioral interview questions already maps questions to every principle. You’ll still get ten LP questions, because they show up in every round.

OfferBull is not affiliated with Amazon. Process details come from Amazon’s public career pages as of October 2026 and can vary by role, level and country.

The process Amazon describes: OA, phone interviews, loop

Amazon’s SDE II interview prep page lists four steps: application, online assessment, interview loop, outcome. Pass the OA and a recruiter contacts you to set up the loop. Amazon’s interview FAQ adds that the process may include one or two phone interviews before the loop, depending on the role. So some candidates go straight from OA to loop and some get a phone round first. Your recruiter will tell you which.

The online assessment. For SDE II, Amazon’s OA prep material describes three sections: a timed 90-minute coding challenge with two questions, a system design work simulation where you rate possible actions in workplace scenarios (no diagrams), and a work style survey tied to the Leadership Principles. Amazon suggests reserving two hours, gives you seven days to finish, and says your code must compile for every question to move forward. Efficient solutions score better than brute force.

New grads and interns take a different version. Amazon’s student SDE online assessment page lists a coding assessment, a Workstyles assessment and, for full-time roles in many countries, a Work Simulation. Public documentation is allowed during coding, browser usage is logged, and Amazon asks you to avoid copy and paste.

My honest take: people underprepare for the OA because it feels like a filter. It is a filter. A strict one. If timed assessments are new to you, read our guide to online coding assessments in tech hiring and practice with a clock running.

Phone interviews. Candidates usually describe a coding problem in a shared editor plus a behavioral question or two. Treat it like a short loop round.

The loop. Amazon’s SDE II page describes four 55-minute interviews covering technical skills and Leadership Principles, with different interviewers assigned to evaluate different areas. Amazon’s general interview loop page says you’ll likely meet two to seven people, possibly including a Bar Raiser, and should hear back within five business days. The FAQ puts the whole process at three to six weeks on average.

Coding rounds: real code, and LP questions every time

Amazon’s prep page is blunt about the coding bar: syntactically correct code, no pseudocode. The main criteria are code that scales, handles bad input and is well tested. SDE II candidates are told to expect three separate interviews looking at logical and maintainable code, problem solving, and data structures and algorithms, and to give time and space complexity in almost every question.

Here’s what surprises people. Amazon says each interviewer will typically ask two or three behavioral questions. So your “coding round” may open with a Leadership Principle question that eats ten or fifteen minutes. Long stories shrink your coding time.

Worked approach: a problem-solving question

Amazon describes its problem-solving questions as deliberately ambiguous and suggests splitting your time three ways: uncover requirements, build a first pass that covers them, then enhance it. An illustrative prompt:

“We have scan events from delivery stations. Return the k stations with the most failed scans in the last hour.”

Don’t type yet. Ask: sliding window or fixed batch? How many stations? How are ties broken? Say the answer is a batch, a few thousand stations, millions of events, ties by station ID.

First pass: one loop over the events, count failures per station in a hash map, then a min-heap of size k over the counts. O(n + m log k) time, where m is the number of stations, and O(m) space. Say that before you write it. Then write a small countFailures function and a separate topK. Amazon asks for readable code split into methods with clear jobs, so one giant function costs you.

Then enhance: “If this becomes a live stream, I’d keep per-minute buckets so old data expires cheaply.” No need to code it. Test an empty list, k larger than the station count, and a tie before you say you’re done.

What SDE I candidates often see

Amazon’s software development topics page lists object-oriented design, and many new grads report an OOD question in the loop, like a parking lot or a vending machine. Don’t jump straight into classes. Start with use cases, then nouns, then which object owns which behavior. One interface you can defend beats five abstract classes you can’t.

System design for SDE II

Amazon’s SDE II page says to expect at least one systems design question. It asks you to treat the interviewer as a customer, write down your assumptions, and think about what twice or ten times the growth would do to your design.

Illustrative prompt: “Design a service that tells customers when their order status changes.”

Spend the first five minutes on scope. Which statuses and channels? Is a duplicate notification worse than a late one? Nobody wants two “Delivered” pushes, so I’d propose at-least-once processing with deduplication on an event ID.

Then sketch it. Order systems publish status events to a queue. A notification service consumes them, checks preferences, and records each send by event ID so retries don’t double-send. Per-channel queues mean a slow SMS provider can’t back up push.

Then the deep dive, usually on failure. Email provider down for an hour? Retries with backoff, a dead-letter queue, an alarm. Amazon also says you can steer away from an unfamiliar topic toward one you know. Use that. Bluffing about consensus protocols goes badly. For more prompts, see our list of top FAANG system design questions.

The Bar Raiser and the SDE I vs SDE II bar

Amazon describes the Bar Raiser as someone from another team focused on hiring quality. Its write-up on the program says Bar Raisers are trained on the Leadership Principles, act as objective third parties, and make the final hiring decision with the hiring manager. You usually won’t know who it is, so treat every round like it counts.

Level matters too. Amazon describes an SDE II as someone who delivers features across their life cycle, trades off feature work against operational work, documents how the software runs, and mentors others. At SDE I, the bar is clean, correct code and stories showing you learn fast. Internship stories are fine. Invented leadership is not. At SDE II, interviewers expect operational weight: an incident you drove, a trade-off you defended. Vague “we built it” answers get pulled apart.

10 Leadership Principle questions engineers get

Amazon publishes 16 Leadership Principles and says all candidates are evaluated through them. If STAR is new to you, start with STAR method interview questions and examples. Here are ten questions that come up a lot in SDE loops, with what I’d put in each outline.

1. Tell me about a decision you made without all the data you wanted. (Are Right, A Lot) What you knew, what you assumed, how you limited the damage.
2. Describe a bug you tracked to its root cause. (Dive Deep) Logs, hypotheses you ruled out, the actual cause.
3. Tell me about a time you disagreed with a technical decision. (Have Backbone; Disagree and Commit) Include how you committed after losing.
4. When did you take on work nobody else would? (Ownership)
5. Tell me about something complicated you simplified. (Invent and Simplify) Steps removed, a pager that went quiet.
6. Describe a deadline you missed, or nearly did. (Deliver Results) What you cut, who you told, and when.
7. When did you raise the quality bar on your team? (Insist on the Highest Standards)
8. When did you learn a new technology fast to get something done? (Learn and Be Curious)
9. Tell me about a time customer feedback changed your design. (Customer Obsession) An internal team calling your API counts.
10. Tell me about a mistake you made in production. (Earn Trust) How fast you said it out loud matters.

The samples below are illustrative and fictional, in different voices on purpose. Borrow the shape, not the story.

Sample 1: New grad, Dive Deep (flowing speech)

“This was my internship. People said our weekly internal report was ‘sometimes wrong,’ which, not very helpful. Nobody had time for it, so my mentor gave it to me. I collected every report anyone had flagged. There were six, and every one was a week that crossed a daylight saving change. Took me a day to notice, honestly, because I read the SQL first. The job bucketed events by local midnight but the server ran in UTC, so an hour of data slid into the wrong day twice a year. I fixed the bucketing, added tests for both DST weekends, and wrote it up on the wiki. Nobody flagged a report after that. What I’d keep: collect the failures first, then read the code.”

Sample 2: Mid-level backend engineer, Disagree and Commit (labeled STAR)

Situation: “We were splitting a monolith, and my manager wanted the new inventory service to keep the old shared database for its first release.”

Task: “I owned the service, and I thought sharing the database would tie us to the old schema.”

Action: “I wrote a one-page doc comparing that with a separate store fed by change events, with rough effort and risk for each. She agreed with the concern, but a partner team had fixed the date and my option added about three weeks. I said I still disagreed, then committed. I asked for one thing: every query goes through a data-access layer, so moving later wouldn’t mean a rewrite.”

Result: “We shipped on the partner’s date. When we moved to our own store two quarters later, the change stayed mostly inside that layer. I still think my plan was cleaner. Her call was right for that quarter.”

Sample 3: Switching stacks, Learn and Be Curious (flowing speech)

“I’d done React for years, then moved to a team running Java services. First month, I got a ticket for an endpoint timing out for big customers. I didn’t know the profiler, didn’t really know the framework. So I spent two evenings on the profiler docs, then asked the engineer who wrote the endpoint to explain the code, not fix it. Once I could read the profile it was obvious: a loop calling the database once per line item. N plus one, same as I’d seen with API calls on the front end, just in a different costume. I batched it into one query, added a test with a two-thousand-item order, and the timeouts stopped. The stack was new. The bug wasn’t.”

What about AI tools?

You already saw that Amazon logs browser activity during the student OA. For the phone screens and the loop, read whatever your recruiter sends about permitted tools, and follow it. Those instructions are the final word.

So the line is simple. AI tools are for practice, before the interview. In the interview, it’s you.

How I’d prepare in three weeks

Week one is the OA: two timed problems per sitting in a plain browser editor, 90 minutes, no autocomplete. Compile everything. Losing a good solution to a compile error is a painful way to go out.

Week two is loop coding plus stories. One medium problem a day, spoken aloud. STAR notes for eight stories, each tagged with two or three principles. Add two OOD drills for SDE I, or two system designs for SDE II.

Week three is full mock loops, each round opening with a behavioral question. Then fix what fell apart. Usually it’s the follow-ups.

Interviewing at more than one company? Our guides to the Google software engineer interview and the Meta software engineer interview cover how those loops differ.

Practicing with OfferBull

OfferBull is an AI mock interview app for iOS and Android. A voice interviewer asks questions aloud and you answer by speaking. Paste an Amazon SDE job description or upload your resume for tailored questions, and it follows up based on your answers and resume, which is where Amazon stories tend to crack. While you practice, it can show answer suggestions and STAR structures. You can practice in English or Chinese.

It’s for the weeks before your loop. On interview day, you answer on your own.

Start an AI mock interview

FAQ

How long is the Amazon SDE online assessment? For SDE II, the coding section is a timed 90 minutes for two questions, and Amazon recommends reserving about two hours in total. The university OA differs, so check your OA email.

How many rounds are in the Amazon SDE loop? Amazon’s SDE II prep page describes four 55-minute interviews. Other levels and roles can differ, so confirm with your recruiter.

Is there a phone screen before the loop? Sometimes. Amazon’s FAQ says the process may include one or two phone interviews, while the SDE II page goes from OA straight to loop. Your recruiter will confirm.

---

Practice This Out Loud

Solve two problems in 90 minutes, compiling as you go. Then answer one Leadership Principle question out loud in two minutes and have someone ask “what exactly did you do?” twice. When that feels steady, run it as a voice mock interview. → Practice Now