Most people who apply to Amazon for a software role never speak to an interviewer until they have cleared the Online Assessment. The OA is a self-serve, timed, automatically graded stage that arrives as a link in your inbox, usually with a deadline of a few days. It is a filter, and it is where a large share of applications stop.
This page is about the OA specifically, not the interview loop. If you have already cleared screening and want to know what an engineer will actually ask you on a live call, read our companion guide to Amazon coding interview questions instead. The two stages test overlapping material but reward very different behaviour: the OA rewards a fast, correct, self-contained submission, while the live round rewards visible reasoning and communication.
Where the OA sits in the Amazon process
The rough sequence for a software engineering application looks like this.
| Stage | Format | What it decides |
|---|---|---|
| Application / referral | Async | Whether you get an OA link at all |
| Online Assessment | Timed, self-serve | Whether you enter the interview pipeline |
| Phone / technical screen | 45-60 min live | Whether you reach the full loop |
| Interview loop | 4-6 rounds | The hire / no-hire decision |
| Bar raiser | Within the loop | Consistency of the bar across teams |
Note that some candidates — particularly experienced hires and referrals — skip the OA entirely and go straight to a phone screen. Others receive it in two parts, days apart. Neither pattern means anything about your chances.
The sections commonly reported
1. Two timed coding problems
The core of the assessment. You write code in a browser editor, in your choice of a supported language, and your submission is graded against hidden test cases. The problems are usually easy-to-medium in algorithmic difficulty but heavy in narrative — several paragraphs of retail, logistics or fulfilment framing wrapped around a fairly ordinary data-structures task. That framing is why so many people search for OA problems by pasting the first sentence of the story into Google.
The practical consequence: reading is part of the test. A meaningful number of failed submissions are correct algorithms applied to a misread problem. Restate the input, the output and the constraints in your own words before you write a line.
2. A code-debugging section
A set of short, pre-written functions with defects planted in them. You are asked to find and fix each one, typically under a much tighter per-question clock than the coding problems. The code is deliberately mundane — off-by-one errors, inverted conditions, wrong loop bounds, a variable updated in the wrong branch, a missing base case.
This section rewards a different skill from problem-solving: reading unfamiliar code quickly and spotting the smallest change that makes it correct. Resist the urge to rewrite. The graders are looking for a fix, not a refactor, and a rewrite burns clock you do not have.
3. A work simulation
Often described as a "day in the life" exercise. You are dropped into a simulated Amazon workday — inbox messages, dashboards, chat threads, a ticket queue — and asked how you would respond to realistic situations: an ambiguous customer complaint, a teammate whose data contradicts yours, a deadline that cannot be met as scoped.
There is rarely a single right answer, but there is a clear house style. Answers that start from the customer, insist on data, escalate honestly rather than quietly absorbing risk, and take ownership of the outcome map onto how Amazon describes good judgement. This is the section where knowing the 16 Leadership Principles genuinely pays off — not so you can name them, but so you recognise the trade-off each scenario is really testing.
4. A work-style survey
A long series of paired or scaled statements about how you prefer to work. It is not timed in any meaningful sense and it has no algorithmic content. It maps your self-description against the Leadership Principles.
Answer it honestly and consistently. The instrument repeats similar ideas in different wording, so an invented persona tends to contradict itself — and a persona you would have to sustain through four live interviews is not worth building. If you want to understand what the principles look like in practice rather than in the abstract, our Leadership Principles examples guide walks through concrete situations.
5. Logical reasoning (sometimes)
Some roles and regions — more often non-SDE technical roles, university programmes and certain international pipelines — include a short aptitude block: pattern completion, numerical series, basic logic. If your invitation mentions it, a couple of practice sets is enough; if it does not, do not spend time on it.
How the OA is scored, at a high level
Nobody outside Amazon knows the thresholds, and anyone publishing exact cut-offs is guessing. What is reasonable to say:
- The coding sections are graded on hidden tests, which typically include large inputs. A brute-force solution that is logically correct can still fail on time limits, so complexity matters even though no one is watching you reason about it.
- Partial credit generally exists. Passing most test cases on both problems is usually better than acing one and submitting nothing for the other. Always submit something that compiles.
- The behavioural sections are not decorative. They feed into the same overall picture, and candidates do report being screened out on them despite clean code.
- The bar moves. It varies with role, level, region and the volume of applicants in that cycle. Treat "what score do I need" as unanswerable and aim for a clean, complete submission instead.
The DS&A topics that come up most
Treat this as a coverage map for your prep, not a prediction of your specific paper.
- Hash maps and sets. Counting, grouping, deduplication, frequency tables. Probably the single most useful structure for OA-style problems.
- Sorting plus two pointers. Pairing, matching, interval merging, and "minimise/maximise after arranging" problems.
- Heaps and priority queues. Top-k, scheduling, repeatedly taking the smallest or largest remaining item.
- BFS and DFS. Grid traversal, connected components, shortest hops in an unweighted graph. Warehouse and delivery framing makes grids very common.
- Prefix sums and sliding windows. Subarray sums, running totals, fixed- and variable-width windows.
- Binary search. Both on sorted arrays and on the answer space — "smallest capacity such that this is feasible" is a recurring shape.
- Light greedy and DP. Simple interval greedy, and one-dimensional DP such as house-robber or climbing-stairs variants. Deep DP is rarer here than in live rounds.
If you want these organised as reusable templates rather than a list of topics, our 15 LeetCode patterns guide covers nearly all of the above.
Realistic timing and logistics
Candidates commonly report a full session in the region of one and a half to three-plus hours, sometimes split across two links. Plan as if it will run long. A few practical points that cost people offers every cycle:
- Do not open the link to "have a look." On many versions the clock starts the moment you open it.
- Sit down with the whole block free, on a wired or reliable connection, with your phone away and one browser window.
- Know your language's standard library cold — sorting with a custom comparator, a hash map, a heap. Fumbling syntax is a pure waste of clock.
- Some versions are proctored. Webcam or screen monitoring may be required, and the rules stated in your invitation are the ones that apply to you. Follow them.
- Submit early, then improve. Get a working solution in, then optimise, rather than polishing an unsubmitted one until the timer ends.
A two-week prep plan
- Days 1-3: rebuild the core structures. Hash maps, sorting with comparators, heaps, and BFS/DFS on a grid. Write each from scratch once in your chosen language so the syntax is muscle memory.
- Days 4-7: drill easy-to-medium problems under a timer. Twenty to twenty-five minutes each, no hints, and always finish with a stated time and space complexity. Volume matters less than finishing every attempt.
- Days 8-9: practise debugging. Take working solutions you wrote earlier, deliberately break them, leave them for a day, then fix them cold. It is an unusual drill and it maps directly onto the debugging section.
- Day 10: practise reading. Take long, wordy problem statements and spend two minutes reducing each to inputs, outputs and constraints before solving. This is the highest-leverage OA-specific skill.
- Days 11-12: work on judgement. Read the Leadership Principles and prepare four or five real stories in STAR form. Our guide to passing the Amazon behavioural interview shows the structure that carries through from the OA into the loop.
- Days 13-14: full simulation. One unbroken sitting: two timed problems, a debugging block, and a written response to a work-simulation scenario. Then rest before the real thing.
If you clear the OA, shift immediately — the loop tests different muscles. Start with Amazon coding interview questions for the technical rounds and Amazon interview help for role-specific support.
Prep sharper, perform calmer with live AI support
CoPilot Interview surfaces structured solutions with Big-O in about 4 seconds during real Zoom, Teams, and Meet calls. Free tier for Windows and macOS, with a private desktop window.
Try it freeFAQ
What is the Amazon Online Assessment?
The Amazon Online Assessment, usually shortened to OA, is a timed screening stage you complete on your own before any live interview. It is commonly reported to combine coding problems with a code-debugging section, a work-simulation exercise, and a work-style survey tied to Amazon's Leadership Principles. It comes before the interview loop, not during it.
How is the Amazon OA different from the Amazon coding interview?
The OA is asynchronous and automatically graded: you write code against hidden test cases with no interviewer watching. The coding interview is a live conversation where an engineer evaluates your reasoning, communication, and trade-offs as much as your final answer. Strong OA performance gets you into the loop; the loop is where the hiring decision is made.
What topics should I study for the Amazon Online Assessment?
Arrays and strings, hash maps and sets, sorting with two pointers or binary search, heaps and priority queues, BFS and DFS on grids and graphs, prefix sums and sliding windows, and simple greedy or dynamic-programming problems. Most reported OA problems sit at the easy-to-medium level but are wrapped in a long business-flavored story you have to parse first.
How long does the Amazon Online Assessment take?
Candidates commonly report a session lasting between one and a half and three-plus hours, sometimes split across separate links completed on different days. Amazon varies the timing by role, region and year, so treat the time budget stated in your invitation email as the only authoritative figure and block out more time than you think you need.
Can CoPilot Interview help me prepare for the Amazon OA?
Yes, as a study and rehearsal aid. It returns structured solutions with complexity analysis in about four seconds, so you can drill the data-structure patterns the OA leans on and check your reasoning against a clean reference. Always follow the rules stated in your Amazon assessment invitation.