One link, three very different tests. The coding section gives you two problems and roughly 70 minutes on a single shared clock in a HackerRank-style editor, graded by a machine running your code against hidden test cases. The Work Simulation drops you into a fictional Amazon inbox for about an hour and scores which option you pick, not what you write. The Work Style survey is ten to twenty minutes of forced-choice statements that build a fit profile. Only the first one has a right answer in the usual sense.
The three parts, side by side
Amazon rotates modules by role, level, region and year, so treat this as the common shape rather than a guarantee. The invite email lists your exact modules and each time limit, and that list overrides everything below.
| Part | Typical budget | What you actually do | What produces the score |
|---|---|---|---|
| Coding assessment | About 70 minutes for two problems, one shared clock | Editor with a function stub, visible sample tests, custom input runs | Hidden test cases passed, and whether your solution finishes inside the time limit on the biggest inputs |
| Work Simulation | Around an hour, some screens individually timed | Triage an inbox, choose between drafted replies, read a metrics dashboard, rank proposed responses | The options you select, mapped to Leadership Principles |
| Work Style survey | Ten to twenty minutes | Pairs of statements: which is more like you, or a slider between two positions | A fit profile, plus consistency across items that repeat in near-identical wording |
Two structural facts change how you plan the evening. The parts do not all have to be finished in one sitting on every invite, and some candidates get a debugging module or a short multiple-choice technical block bolted on alongside the standard two problems. Check the module list before you open anything, because opening a module usually starts its clock.
Part one: two problems, one 70 minute clock
The single most useful thing to internalise is that the budget is shared. It is not 35 minutes each. If problem A takes you 20 minutes you have 50 left for B, and if A is going badly at minute 30 you are allowed to abandon it. Candidates who mentally allocate half the clock to each problem are the ones who submit nothing on the second.
The problems sit in familiar territory: arrays and strings, hash maps, sorting, heaps, two pointers, prefix sums, binary search including binary search on the answer, and sometimes a grid or graph traversal. Amazon draws from a rotating pool, so two people sitting the assessment in the same week routinely see different questions. Hunting for a leaked question list is a poor use of the days you have left.
Grading is automatic. You see a handful of sample tests, then hidden tests decide the outcome, and platforms of this type normally award credit per test case rather than pass or fail on the whole problem. That has a direct consequence: a brute force that is correct but slow will clear the small hidden cases and score above a blank editor. Amazon publishes no threshold, so nobody outside can honestly tell you what number gets you an interview.
Read the constraints line as if it were the specification, because it is. When the bound says n can reach 100,000, a nested loop is not a slow solution, it is a wrong one: the large hidden cases will time out no matter how correct the logic is. Reading the bound first tells you the target complexity before you have written a line, which is a faster route to the right idea than staring at the prose.
A few environment details, so they do not eat your clock. You pick a language and get a stub with the signature and the input parsing already wired up, so do not rewrite the I/O. You can usually run against custom input, which is the quickest way to check an edge case. And you generally cannot return to a section once you submit it or its timer expires.
How to spend the 70 minutes
Minutes 0 to 4: read both problems, write nothing
Note the n bound on each and whether the output is a count, an index, a list or a boolean. You are deciding order, not solving yet.
Minute 4: start with the one whose data structure you can name
Not the one that looks shorter. If you can say "sort then two pointers" or "hash map of counts" out loud, that is the one you open.
Minutes 4 to 28: solve it, then run the samples
Write the brute force in a comment first if you are stuck, then attack the target complexity the bound already told you about. Submit as soon as the samples pass.
Minute 30: hard checkpoint, no exceptions
If the first problem is still not passing its samples, submit whatever compiles and move to the second. This checkpoint is the whole discipline. Ignoring it is the standard way to score on one problem instead of two.
Minutes 30 to 60: second problem, same routine
Bound first, data structure second, samples third. If the optimal approach has not appeared by minute 50, write the obvious brute force and submit that.
Minutes 60 to 70: edge cases on whichever is stronger
Empty input, single element, all elements identical, the maximum n, negative values if the constraints allow them, and integer overflow. Use a 64-bit type for sums. Re-check the inclusive or exclusive end of any binary search.
When you are stuck at minute 45, the decision is usually one of these four.
| Where you are | Do this | Reason |
|---|---|---|
| Optimal approach unclear, brute force obvious | Write the brute force and submit it | Per-test-case credit means the small hidden cases still count, and a blank submission counts for nothing |
| Samples pass, you suspect timeouts on the big inputs | Find the nested loop and replace it with a hash map, a sort, or a prefix sum | At n around 100,000 the quadratic version loses the large cases whatever else is true |
| One sample fails, the rest pass | Dry run that single case by hand on paper | A lone sample failure is almost always an index, an empty-input or an off-by-one bug, not a wrong algorithm |
| Both problems half-working | Pick the closer one and make it airtight | A judgement call rather than a published rule, but one clean solve reads better than two broken ones to whoever reviews the transcript |
Part two: the Work Simulation is an inbox test
You are given a fictional Amazon role and a queue of messages: a manager, a peer on another team, a customer with a complaint, sometimes a vendor. The modules vary, but the recurring ones are ordering that queue by what you would handle first, choosing between several drafted replies, ranking proposed responses from most to least effective, and interpreting a small dashboard or metrics table to say which explanation the numbers actually support.
It is selection-based, so there is no essay to talk your way out of and no clever framing to hide behind. The choices map onto Leadership Principles, and a few patterns recur. Options that go to the data before offering an opinion score better than confident guesses. Options that tell the customer the bad news early beat options that protect an internal date. Options where you handle the thing yourself beat options where you forward it upward for a decision you could have made. And the safe, agreeable middle option, the one that offends nobody and commits to nothing, tends to evidence nothing either.
Practical notes: some screens carry their own timer and cannot be paused mid-module, the reading volume is real, and answering as an idealised employee who never says no produces a flat profile. Consistency with the character you are playing matters more than picking the most eager-sounding answer every time.
Part three: the Work Style survey
Ten to twenty minutes of paired statements. Which is more like you, or a slider between two working styles. There are no test cases and no model answer, and Amazon does not publish the scoring, so any guide quoting a pass mark for this section is inventing it.
What is observable is the design. Items reappear in near-identical wording later in the survey, which is a standard technique for detecting inconsistent responding. The common failure is not answering "wrong", it is switching voices: half the answers from the real you, half from the Amazon employee you are picturing. Pick one and hold it for the full survey. Sliding everything to the neutral middle is also a choice, and it is the one that produces the least usable profile.
Where this page stops helping, and where our tool is the wrong one
The coding assessment is auto-graded and, for most software engineer flows, taken at home without a webcam. Amazon can add proctoring for particular roles and regions, and your invite tells you which version you have. Either way the section is a filter rather than a verdict: interviewers regularly open a later round by pulling up the approach you submitted and asking you to walk through it. A partial solution you can explain in your own words is worth more across the whole loop than a complete one you cannot.
That is the honest boundary for a tool like OfferPilot AI's Code Copilot. It exists to make practice fast, screenshot a problem, get an optimal solution with the intuition behind it, a dry run and the Big-O, and to sit alongside you in a live interview where you are talking through code with a person. It is not built to sit an assessment on your behalf, and what the OA measures is your unaided recall under a clock. Two further limits worth stating plainly: it runs on Windows 10 and 11 only, with no macOS, Linux, mobile or browser version, and although the overlay is excluded from screen capture at the operating system level so it does not appear in Zoom, Teams, Meet or a recording, that does nothing about a webcam, a lockdown browser, a person watching you, or a phone propped up beside your desk. On the Work Simulation and the Work Style survey there is nothing useful for any tool to contribute anyway, because both are asking about your judgement rather than about a fact.
The prep that genuinely moves the coding score is unglamorous: timed pairs of problems, 70 minutes, no pausing, no editor autocomplete you will not have on the day. Do four or five of those and the minute-30 checkpoint stops feeling like giving up and starts feeling like scheduling. For the two behavioural parts, the useful work is knowing the Leadership Principles well enough to recognise which one a screen is aiming at before you pick.
Related guides
- Technical Phone Screen: What to Expect in a 30-Minute Call
- Pair Programming Interview Tips: What to Expect in a Real Repo
- HireVue Interview Format: What to Expect, Question by Question
- Amazon Bar Raiser Round: What That Interviewer Is Actually Doing
- How Long Should a Take-Home Coding Assignment Take? Time-Box It