Foundations

How an online assessment usually works

An online assessment is a timed screen that some candidates receive before a phone call or an on-site loop. People use the shorthand "OA" for it. This page describes the shape of that screen the way candidates talk about it in public posts. It is not Amazon's specification, and it is not a list of tasks that will show up in your invitation.

The only description that applies to you is the one in the message you were sent. Role, level, location, and hiring season all change the packet. A new graduate applying for an SDE internship and an experienced engineer applying for a different job title should not assume they will see the same sections, the same timer, or the same number of problems. If those details are in the email, follow the email. If they are not, practice the skills below and do not fill the gap with rumors.

What public write-ups tend to mention

Read a handful of public experience posts and a pattern shows up, with plenty of exceptions. Many SDE candidates describe a coding portion made of short algorithmic problems, solved in a browser editor, with tests they can run. Some describe a second section that feels more like a work sample: a bug to find, a small change inside an existing function, or a written scenario. Some describe a work-style questionnaire, a set of agree-or-disagree statements that the employer uses as a signal about how someone likes to work.

Those are categories, not a checklist you can demand. A given invitation might include one of them, several of them, or something that does not fit the categories cleanly. The useful part of the pattern is what it tells you to practice: writing correct code under a clock, reading code you did not write, and answering behavioral prompts with specific stories. The four-week plan spreads that practice out. The time management page is about the clock itself.

Public posts are also a biased sample. People who thought an experience was interesting are more likely to write it up. Posts go stale. A thread from two years ago can describe a tool, a timer, or a section that your invitation does not use. Treat every post as one person's memory of one day. If two posts disagree, that is normal. It is not a puzzle you have to solve by picking a side.

What the coding portion is usually for

When a coding section exists, it is there to see whether you can turn a plain-language task into a working program, and whether you notice the cases that make the happy path wrong. The problems people describe are often in the same family as ordinary practice: arrays, hash maps, strings, trees, graphs, and an occasional dynamic programming or greedy choice. That is why the pattern pages on this site exist. They are gym exercises, not a reconstruction of anyone's assessment.

A few habits matter more than the particular topic. You need to read the prompt until you can restate the input and the output. You need a couple of examples, including an empty input or a single element if those are allowed. You need a first approach that you can actually finish, even if a faster one exists, and you need enough time left to run it on those examples. Candidates who fail these screens in public write-ups often describe running out of time halfway through a clever idea, or shipping a solution that works on the sample and fails on a duplicate, a negative number, or an off-by-one boundary. The common mistakes page is a catalog of those failures.

Complexity still matters when the prompt gives you a size. If the input can be large, an n-squared scan may be too slow even though it is correct on the sample. Say the complexity out loud or in a comment before you decide the approach is done. If you cannot, you do not yet know what you wrote.

Work-style questions, when they appear

A work-style section, when a candidate reports one, is not a coding problem and it is not a trivia quiz about a company's slogans. It asks how you tend to act: whether you would rather decide with partial information or wait, whether you raise a disagreement, whether you take a task that is not in your job description. There is no benefit to trying to game a questionnaire you have not seen. Inconsistent answers are a worse signal than a honest preference the employer might not love.

Prepare for this kind of section by knowing your own stories, not by memorizing adjectives. The Leadership Principles and STAR page shows how to tell one story so a listener can see the situation, the action, and the result. That skill is useful in a written screen and in a later conversation. It does not require you to pretend you have worked at Amazon.

Debugging and work samples

Some candidates describe a section where the code already exists and is wrong. The skill is different from writing a function from a blank editor. You have to read, form a hypothesis, and change as little as possible. Rewriting the whole function feels productive and often burns the timer. The debugging guide walks through a small original bug and a way to talk about a work sample without inventing details you were not given.

If your invitation does not mention a debugging section, still do one or two of these reps. Reading someone else's code is part of the job the interview is a proxy for. It is cheap practice.

What this page will not do

This site does not host assessment prompts, solutions to current or past assessments, or screenshots of an employer portal. It will not rank "recent questions" as if frequency in a forum were the same thing as probability on your screen. When the homepage links to a public discussion, that discussion stays on the site that published it. Use it as a data point about what people felt comfortable sharing, then go practice the underlying skill on problems you are allowed to use.

If someone offers you "the exact OA" in a private document, assume you should not touch it. Using confidential material is a serious line to cross, and it is also bad preparation: you train recall of a leaked prompt instead of the ability to solve a new one. The guides here are written so you can practice without that shortcut.

How to use the rest of the library

Start with the format you were actually assigned, if you know it. If you do not, spend the first week on arrays, hash maps, two pointers, and sliding windows, because those patterns show up constantly in ordinary practice and in public interview write-ups. Add trees, graphs, heaps, binary search, greedy choices, and a small amount of dynamic programming in the following weeks. Keep two short behavioral stories ready by the end of week two, and rehearse them out loud. The plan page turns that into a calendar.

On the day itself, read every rule on the screen before you start the timer if the interface lets you. Note whether you can go back, whether the editor saves, and whether a section is separately timed. Then do the boring version of the plan: restate the task, write down an example, pick an approach you can finish, test the edges, and only then polish names. That sequence is the whole point of the time management notes.

Afterward, write down what the sections actually were, in your own words, for your own notes. Do not post prompts or solutions. A private postmortem is how the next attempt gets calmer. The public list on the homepage is optional reading, not a requirement, and it will never be more accurate than the invitation in your inbox.