Why this matters more than it looks
Meta and Google put the AI-assisted round inside the onsite, where a human watches you think. Amazon put it in the online assessment, the stage every applicant passes through and the one with the most candidates in the industry. That changes what the round is for. It is not a conversation about judgment. It is a filter, scored by a test runner, and the thing it filters on is whether you can get into an unfamiliar codebase and out again with the tests green in an hour.
Amazon's own invitation, as one candidate pasted it, says the coding challenge "takes 100 minutes, work through two coding problems. One will be a traditional code-writing question, and in the other you will have access to an AI coding assistant in a code repository environment." That is the whole official description. Everything below comes from the people who sat it.
What the task actually is
Every report describes the same shape: a working repository, a README that states the API contract, a bundled test suite with about six failures, and a short ticket naming two to four broken behaviours. The bugs are shallow by design. Nobody reports an algorithmic problem inside the repo. They report the kind of defect you fix in your first week on a team:
- A handler that does not validate the request body, so a missing field becomes a 500 instead of a 400.
- A lookup with no existence check, so an unknown id is accepted instead of answered with a 404.
- A record that is modified in memory and never saved, so the response looks right and the next request shows nothing changed.
- An id compared against the wrong type, or an object compared against a list of ids, so a duplicate check never fires.
- A search that compares case-sensitively, forgets to exclude unpublished items, or sorts the wrong way.
- A route registered with the wrong path, so the test fails before any handler runs.
The domains rotate. The most reported one is a movie database with watch lists: add a movie, remove a movie, search the catalog, six tests. Others in the rotation: an issue tracker where creating an issue is broken, a car rental app whose "my cars" page shows other people's cars, a loan system, a password reset flow, a comment platform with 401 and 403 rules, and a C++ rules engine with syntax errors and unfinished functions. The candidates who did well on one would have done well on any of them, which is the point.
One more thing the reports agree on: the ticket does not list every bug. Candidates who fixed what the ticket said and then read the remaining failing test found a sixth defect nobody had mentioned. One digest of the reports calls it extra credit. We would call it the part of the task that tells Amazon whether you read tests or only tickets.
The assistant is not what you think
People hear "AI coding assistant" and picture Cursor. The thing in the OA is closer to a librarian. It will tell you which file handles the request, explain what a block does, and say what the test is checking. Ask it to fix the bug and it declines. Ask it to edit the file and it declines. One candidate summed it up as "the AI was basically useless", another as "it helps with syntax and lookups". On some harnesses it only sees the file you currently have selected, so it cannot even trace a call across the project for you.
Our read: that is deliberate, and it tells you what is being measured. If the assistant wrote fixes, the task would measure prompting. Since it only points, the task measures whether you can run the loop yourself: read the failing test, find the contract line, find the handler line, change it, rerun. The assistant shortens step two. Everything else is you.
The clock is the exam
Read the failure stories and a pattern jumps out. Nobody says the bugs were hard. They say: "not hard, just slow", "finished the first two of six, the rest I never looked at", "spent 45 minutes because I did not know Spring Boot", "zero passed, wasted a referral". Six tests, each with several sub-checks, in sixty minutes, in a browser IDE you have never used, in a framework you picked thirty seconds ago. The difficulty is throughput.
That has three consequences for how you should play it. Pick the stack you can debug blind, not the one on your resume. Bank the tests in order of cheapness, because partial credit is real and a 5 of 6 with ten minutes to spare beats a heroic attempt at the hard one. And leave five minutes at the end for the final run in the sandbox, because a fix that passes in your editor still has to pass in theirs, and several candidates lost work they had already done.
What is confirmed, and what is not
- Confirmed: the 100-minute, two-question structure with one repository task; the 60-minute budget; the VS Code-style browser IDE; stack selection up front; a README plus roughly six failing tests; an assistant that locates but does not fix; partial credit advancing candidates. Each of these appears in several independent reports.
- Reported once or twice: specific domains beyond the movie database and issue tracker; the assistant seeing only the open file; a required git push at the end on the C++ harness.
- Not known: the scoring rubric, the pass threshold, which model powers the assistant, and whether the task will reach every SDE packet. Amazon has published nothing beyond the invitation text.
How we would prepare
- Drill the loop on a repo you did not write. Clone a small open-source service in your stack, break three things on purpose in handlers (a missing check, a missing save, a wrong status), and fix them from the failing tests with a timer running. Ten minutes per bug is the pace you need.
- Read the README and the test names before the code.The README is the contract and the test names are the ticket you were not given. Candidates who started in the handler and worked outward ran out of time; the ones who started from the test and the contract did not.
- Learn the shape of a web handler cold. Validate the body, look things up and 404 when missing, check permissions, mutate, save, return the right status and shape. Every reported bug is a missing step in that sequence. If you can recite the sequence, you can spot the gap.
- Practice with an assistant that only points. Ask it where, not what. "Which function handles DELETE on this route" is a question it answers well. "Fix the failing test" is a question it refuses.
- Keep the algorithm practice. The other 40 minutes are a genuine medium-to-hard problem, and a weak score there is not rescued by a strong repository task.
Nyrion's Amazon section starts with Movie DB: Watch Lists and Search, built from the most reported variant. A small service with an API.md contract, four tickets, the bugs candidates describe (missing checks, a missing save, a wrong route, a string compared to an int, a case-sensitive search, a backwards sort) and one defect no ticket mentions. The assistant in our editor can write code for you, which Amazon's will not, so practice with it the way you will have to use theirs: ask it where, then fix it yourself.
How this round compares with other companies' versions, and what every version grades: the AI coding interview guide.
Frequently asked, briefly answered
Does every Amazon SDE candidate get the repository task?
Not yet. Reports from July to September 2026 come from SDE I, SDE II, new grad and intern packets, but some candidates in the same months still got two classic questions. Your invitation email says which you have: if it mentions an AI coding assistant in a code repository environment, this page applies to you.
Can I use my own AI tool during the OA?
No. The assistant is built into the assessment, and Amazon's university OA guidance warns that browser activity may be logged. The built-in assistant is also deliberately limited: in first-hand reports it finds the file and explains the code but does not write the fix (the forum's own summary of the round says some versions edit code, so read the instructions on the day), and on some harnesses it only sees the file you have open. Prepare for that assistant, not for Cursor.
Which stack should I pick?
The one you can debug without reading documentation. Candidates who picked Spring Boot without daily Spring experience lost most of the hour to framework friction and finished two of six tests. You choose up front and cannot switch. Reported options include Spring Boot, Django, Node and C++.
Do I need to pass every test?
Reports say no. Several candidates who passed four or five of six tests got the phone screen invitation. The reverse also holds: a candidate who passed zero on the repository task and did fine on the algorithm question was not called back. Treat each test as worth something and bank the easy ones first.
Is the algorithm question still there?
Yes, and it got harder, not easier. The repository task replaced one of the two classic questions, and candidates describe the remaining one as medium to hard: coordinate compression over segments, a grid problem solved with multi-source BFS plus binary search, a string merge DP. Forty minutes for it. The old advice about Amazon OAs being easy is out of date.
What else is in the assessment?
After the 100-minute coding challenge there is a work simulation (about 15 minutes of email-style scenarios where you rate possible responses) and two work style surveys (about 10 minutes). Both are untimed in practice and neither needs preparation beyond reading the Leadership Principles once.
Practice problems tagged for Amazon
Browse the catalog and open the Amazon section. No login required to look; sign in when you want to solve one.