Amazon Online Assessment: Format, What It Tests, and How to Prepare

The Amazon online assessment is the automated screen that stands between an application and a human interviewer for most software engineering roles, including internships and new-grad positions. It arrives as a link with a deadline, you take it alone in a browser, and it is graded before anyone reads your name.

This is a practical guide to what it contains, what the coding section really tests, how to prepare in two weeks, and an honest account of the parts nobody can tell you with certainty — because a guide that pretends to know Amazon's internal scoring is worse than one that says where the knowledge ends.

What the Amazon online assessment is, and what it is not#

It is an automated first filter. It is not a conversation, there is no interviewer to hint, and nothing you write gets credit for being interesting. Your code is run against test cases you cannot see, and the grade is whatever those tests say.

The important consequence: the skills that make you good at this are different from the skills that make you good at a live interview. In a live interview, narration, clarification and recovery carry real weight. In an assessment, nothing carries weight except a correct program submitted before the timer ends. Prepare for both, separately.

One caveat before any specifics. Amazon does not publish a spec for its assessments, formats vary by role, region and hiring pipeline, and they change. Everything below is drawn from what candidates consistently describe, and your invitation email is the authority whenever the two disagree.

The shape it usually takes#

Assessments in this family have consistently been described as having a coding part and a non-coding part:

The sections are usually taken in one sitting or across a short window, and the coding section is the one with a hard timer inside it.

What the coding section actually tests#

Three things, in this order.

Whether you can recognise a standard pattern quickly. The problems are not exotic. Across reports the recurring shapes are the ordinary ones: counting and grouping with a hash map, sorting followed by a greedy pass, top-k with a heap, BFS over a grid, binary search on the answer, and simple one-dimensional dynamic programming. If you can name the pattern from the constraints, you are most of the way there — which is exactly what the pattern map is for.

Whether your solution is fast enough. Hidden tests include large inputs. A correct O(n²) solution on an input of 10^5 elements fails on time, and it fails silently — no interviewer says "can we do better". Read the constraint, derive the budget, and write for that budget from the start.

Whether you handle the edge cases nobody reminds you about. This is where most points are lost. Empty input, a single element, all elements equal, k larger than the array, duplicates, disconnected graphs, negative numbers. In a live interview an interviewer often nudges you toward the case you missed. Here, the test case just fails.

Because grading is per test case, a correct but slow solution usually still collects the small cases. That gives a clear tactical rule: get something correct first, then optimise. A blank submission scores nothing; a brute force that passes half the tests is a meaningfully better outcome, and it also gives you a reference implementation to check the fast version against.

A two-week preparation plan#

Two weeks is enough if it is spent on the right shapes and under a clock.

Days 1–3: hashing, counting and two pointers. The base layer under everything else. Two Sum, Group Anagrams, 3Sum, Subarray Sum Equals K.

Days 4–5: sorting and greedy. Assessment problems love a sort followed by one pass, because it is easy to grade and easy to get subtly wrong. Merge Intervals, Meeting Rooms II, Non-overlapping Intervals.

Days 6–7: heaps and top-k. Kth Largest Element in an Array, K Closest Points to Origin, Top K Frequent Elements.

Days 8–9: BFS and grids. Grid problems are common because they are easy to state and hard to rush. Number of Islands, Rotting Oranges, Shortest Path in Binary Matrix.

Days 10–11: binary search on the answer, and windows. The "minimum capacity such that…" shape catches people who only know array binary search. Koko Eating Bananas, Split Array Largest Sum, Minimum Size Subarray Sum.

Days 12–13: one-dimensional dynamic programming. Keep it to the simple shapes; assessments rarely go past them. Climbing Stairs, House Robber, Coin Change.

Day 14: two full timed runs. Two unseen medium problems, ninety minutes, no editorial, no autocomplete beyond what the assessment editor gives you. The point is not the problems. It is finding out how you behave at minute sixty with one problem unfinished.

If you want a broader base and have longer than two weeks, work the Blind 75 instead — the six-week plan covers the same techniques with more repetition per pattern.

How to actually take it#

Read both problems before starting either. Time is shared. Knowing that the second one is a grid BFS changes how long you are willing to spend stuck on the first.

Write the brute force if the fast solution is not obvious within five minutes. Then optimise if time allows. Partial credit is real.

Test locally before submitting. Empty input, one element, the largest case you can construct. Most assessment editors let you run custom input; use it every single time.

Watch for the signature. You are implementing a function with a fixed name and parameter order. Returning the right answer in the wrong type — a list where an integer was asked for, an index where a value was asked for — scores zero on every test.

Do not leave a problem blank. A partially correct submission beats an empty editor, always.

Assume the platform records more than the timer. Assessment tools document what they log — copy and paste events, how often the test window loses focus, how many monitors are connected — and the employer chooses how much of it is switched on. What each one records, taken from their own documentation, is written up in the guides to HackerRank, CodeSignal and Codility.

The work simulation and work styles sections, honestly#

These are situational judgement instruments: you are shown workplace scenarios and asked to choose or rank responses, and given statements about how you prefer to work that you agree or disagree with. They are written around Amazon's published Leadership Principles.

Here is the honest part. Nobody outside Amazon knows how heavily these are weighted, or exactly how they are scored. Advice you will read confidently asserting either that they are decisive or that they are ignored is guesswork presented as fact. What is defensible:

• They are part of an assessment you were asked to complete, so complete them properly.
• Instruments of this kind normally include consistency checks — the same trait probed several ways — so an invented persona tends to produce a contradictory profile rather than an ideal one.
• Reading the Leadership Principles once, before you start, is worth doing. Not to game the answers, but so the vocabulary of the scenarios is familiar and you are not decoding intent under time pressure.
• Answer as yourself, and answer consistently. That is both the honest approach and, given consistency checks, the one most likely to produce a coherent result.

There is no useful way to "practise" these beyond seeing the format once. Spend your preparation time on the coding section, which is the part that responds to practice.

After the assessment#

Write down the problems you were given, immediately, while you still remember them. Then solve them properly — no timer, optimal solution, complexity stated. Two reasons: the techniques recur in the interviews that follow, and if you are asked about your assessment work you want to be able to reason about it rather than reconstruct it.

If you move forward, the next stages are live interviews with human interviewers: coding with someone watching, and behavioural questions structured around the Leadership Principles. That is a different skill, and the coding interview cheat sheet plus timed practice with another person is the way to build it. More practice problems, filterable by pattern and difficulty, are in the problem index.

For the live rounds specifically, Stealth Interview is a desktop app for macOS and Windows that reads the problem from a screenshot, walks through the approach, the code and the time and space complexity with you, and transcribes the interviewer's audio in real time — while staying invisible to screen sharing.