← All posts
general

Amazon Online Assessment: Format, Timing and How to Pass

The Amazon online assessment is the first filter for most software development engineer roles, and the stage candidates under-prepare for most. It looks like two LeetCode problems and a personality quiz, so people with a loop date in mind save their energy for the interviews. Then the assessment ends the process before an interviewer has seen their name.

The assessment is not hard in the way the loop is hard. It is unforgiving in a different way: a hidden test suite instead of a human who gives hints, a clock that does not care that you had the right idea, and a work-style section that quietly grades you against the same leadership principles the loop will. This guide covers who gets one, what the parts are, how long they take, how the result is used, and a two-week plan. Amazon does not publish the format and changes it; where candidates consistently report something, the guide says so.

Who gets an OA

  • New graduate and intern SDE roles. Almost always. For these pipelines the assessment often replaces the phone screen, and a pass leads straight to a loop (sometimes called a "final round" in the invitation). Volume is the reason: far more applicants than interviewers.
  • Experienced SDE roles. Often, and increasingly so by candidates' accounts, though some teams go straight to a recruiter call and a phone screen. The recruiter will tell you; if you are not sent one, nothing is wrong.
  • Non-SDE roles. Different instruments. Product, program and operations candidates may get a work-style survey, a writing sample or a role simulation rather than coding. The Amazon interview process guide covers how the stages differ by role.

The invitation usually arrives by email with a deadline, commonly a few days to a week, and a link to a browser-based environment. You choose when to start within that window. Candidates report that the sections can sometimes be taken in separate sittings and sometimes must be completed in one; read the instructions on the landing page before you click start.

The parts

Amazon has rotated the assessment's components over the years, and new graduate, intern and experienced pipelines do not always get the same set. What candidates consistently report from recent cycles:

  • Coding problems. Typically two, timed together, solved in a browser editor in your choice of mainstream language. Each comes with a problem statement wrapped in an Amazon scenario (packages, warehouses, delivery routes, product catalogues), a few visible examples, and a hidden test suite that runs on submit. After each problem, some versions ask for a short written explanation of your approach and its complexity.
  • Work simulation. A scenario-based section in which you read messages from a fictional team and choose what you would do, or rank responses from most to least effective. The situations are built around the leadership principles: a customer issue nobody owns, a deadline at risk, a disagreement over a design.
  • Work style survey. Pairs or sets of statements ("I prefer to finish one thing before starting another" against "I like to keep several things moving"), and you pick the one that describes you better, or rate how much each applies. Many questions, little time each.
  • Occasionally, a knowledge or debugging section. Some intern and new graduate versions have included a short set of multiple-choice questions on data structures, complexity or basic systems concepts, or a debugging exercise where you fix a small failing function. Not every candidate gets this, and it has come and gone across years.

If your invitation describes a different set, trust the invitation.

Timing and the clock

Durations vary by version, so take these as what candidates report rather than a published schedule. The coding section usually runs somewhere between one and two hours for two problems, and the whole assessment, work sections included, takes two to three hours. The work style survey is fast per question and long overall; the simulation takes longer per item.

How to split the coding time:

  • First ten minutes on reading. Read both problems before you solve either. Pick the one you are surer of, and note the input limits on both; the limits tell you the complexity you need.
  • Solve the surer one fully. Working code, visible tests passing, your own edge cases added (empty input, one element, all equal, the maximum size) before you move on.
  • Leave the harder one a proportional share. If you have 70 minutes, do not spend 50 on the first.
  • Submit something. Hidden tests usually give partial credit per test case, so a correct brute-force solution that passes the small cases scores more than an elegant idea that does not compile. If you are stuck with ten minutes left, write the simple version, make it pass the examples, and submit.

The clock does not stop for anything, including a dropped connection, so sit somewhere with a wired or reliable signal, close everything else, and keep a glass of water in reach rather than in the kitchen.

What the coding part tests

The hidden test suite grades correctness first and complexity second: large hidden inputs will time out a quadratic solution where a linear or linearithmic one was expected. Readable code and the written explanation matter where a human reads them later, which some candidates report happens in the phone screen or the loop.

Problem families that come up repeatedly in candidate reports, with no claim that this is Amazon's list:

  • Arrays and strings. Prefix sums, in-place rearrangement, counting characters, parsing a log line.
  • Hash maps and counting. Frequencies, grouping, "find the pair that sums to", deduplication with order preserved.
  • Two pointers and sliding windows. Longest substring with a property, smallest window containing a set, merging sorted lists.
  • Sorting and intervals. Merge overlapping intervals, schedule meetings, minimum platforms.
  • Trees and graphs. BFS and DFS, shortest path on a grid, connected components, topological order for dependencies.
  • Heaps and greedy. Top-k items, merge k streams, choose the cheapest option repeatedly.
  • Simple dynamic programming. Counting ways, minimum cost paths, one-dimensional state.

Write the tests before the code, or at least before the submit button: the visible examples plus your own three edge cases in a scratch area. Most failed submissions candidates describe afterwards were off-by-one or empty-input errors on code that was otherwise right.

The work style section

The work style survey and the simulation are the part people either skip preparing for or try to game, and both approaches are wrong.

The statements map to the Amazon leadership principles: Bias for Action against careful analysis, Dive Deep against delegation, Customer Obsession against internal convenience, Earn Trust, Ownership, Deliver Results. There is no trick and no published key. What the survey does well is detect inconsistency: the same trait is asked about several ways, and a candidate who picks what they think Amazon wants on one item and what they actually do on another produces a profile that reads as unreliable.

The sensible strategy is to read the principles once, so you recognise what each item is asking about, then answer as you actually work. If you are honestly more deliberate than Amazon's culture of speed, say so; it is better to learn about that mismatch here than six months into the job. In the simulation, pick the response that addresses the customer or the problem first, takes ownership rather than escalating by default, and gets information before deciding when information is available, because that is how the principles describe good judgement.

How the OA is used

Amazon does not publish thresholds, and the weighting varies by pipeline, so this section is what candidates and recruiters describe rather than a rule.

  • Pass or fail to the next stage. A score above the team's bar moves you to a phone screen or, for new graduates, to the loop. Below it, you get a decline, usually without detail, and a waiting period before you can take the assessment again that candidates report as a few months to a year.
  • Visible to interviewers. Some candidates report a phone screen interviewer referring to their assessment code or asking them to explain the approach they wrote up. Treat the written explanation as something a person will read.
  • Partial credit counts. A solution that passes most hidden tests is not a zero, which is why submitting a working simpler solution matters.
  • Work style is not scored like code. By candidates' accounts it is used to flag mismatches rather than to rank; a strong coding score with an inconsistent survey can still end the process, and nobody will tell you which part did.

A two-week plan

A plan for someone with a job and evenings, around 90 minutes a day. Adjust the families to the ones you miss most.

  • Days 1 to 2. Baseline. Two timed problems in a plain browser editor, no autocomplete, 60 minutes. Note what cost you time: reading, the approach, or bugs. Pick your language and stay with it.
  • Days 3 to 6. One family a day: arrays and strings with hash maps; two pointers and sliding windows; sorting, intervals and heaps; trees and graphs with BFS and DFS. Three or four problems a day, each with your own edge-case tests written before the code, and the complexity stated in a sentence afterwards.
  • Day 7. Timed set: two unseen problems, the full window, no pauses. Review the same evening.
  • Days 8 to 10. Greedy and simple dynamic programming, a second pass on the family you missed most, and a habit: after every solved problem, write two sentences explaining the approach and its complexity as if an interviewer will read them.
  • Day 11. Work style. Read the sixteen principles once and write a line under each on how you actually work. The leadership principles examples show what each one looks like in a real story. This takes an hour and does more than a week of guessing.
  • Day 12. Full rehearsal: two problems, then a timed run through a set of work-style statements answered honestly, in one sitting.
  • Day 13. Weak-spot day. Whatever the rehearsal exposed.
  • Day 14. Nothing new. Confirm the environment: quiet room, charged laptop, wired or reliable connection, the browser the invitation specifies, ID if the instructions mention one. Sleep.

If you have four weeks, do this twice with harder problems the second time; if you have four days, do days 1, 3, 7 and 14.

Common mistakes

  • Starting the harder problem first and running out of time for the one you could have finished.
  • Not reading the input limits, and submitting a quadratic solution for an input of a hundred thousand elements.
  • Skipping your own edge-case tests because the visible examples passed.
  • Submitting nothing on a problem you did not finish, when a brute-force solution would have earned partial credit.
  • Treating the written explanation as optional.
  • Answering the work style survey as the Amazon of your imagination instead of as yourself, and producing an inconsistent profile.
  • Taking the assessment on a phone hotspot, late at night, on the last day of the window.
  • Reading the problem statement once; the scenario wrapping hides a constraint in the third paragraph more often than you would like.

After the OA

A pass leads to a phone screen for most experienced candidates, and often straight to a loop for new graduates: four to six interviews, each with coding or system design plus behavioural questions graded against the leadership principles, then a debrief you do not attend. The coding bar in the loop is higher than in the assessment because a person is probing your reasoning in real time, and the behavioural bar is where most loops are lost. Start on the story bank the day you submit, not the day the loop is scheduled.

The Amazon software engineer interview guide covers the loop by level from SDE I to Principal, and the Amazon interview process guide covers the stages and the timelines for every role.

Where coaching fits

The assessment itself rewards hours of timed practice more than coaching, and the free way to start is to do that practice honestly for two weeks. Where a coach helps is in what follows: a coach who has interviewed at Amazon can run timed problem sets with the follow-ups an interviewer actually asks, then move with you to the phone screen and the loop. Six of the 23 coaches on techinterview.coach (as of October 2026) have Amazon on their history; browse them by company and book a single session first. For the behavioural side, the free practice interview runs a round prefilled on the Amazon leadership principles and sends you a written recap of what worked and what to drill (free, sign in with LinkedIn).

Related guides