Amazon AI-assisted coding interviews: how to prepare and show your judgment

What Amazon has actually confirmed

Yes, AI-assisted Amazon coding assessments exist. Amazon describes a technical assessment experience in which candidates work with an interactive AI assistant on a coding platform. That is a candidate-facing development tool, separate from Amazon’s use of AI for interview transcription or matching applicants to roles. Amazon’s explanation of AI in hiring.

The announcement does not establish that every SDE candidate receives that experience, that every interview round permits AI, or that all candidates get the same assistant, time limit, or type of task. A report about another applicant’s assessment cannot settle those questions for your invitation.

This article concerns using AI while interviewing for software engineering roles. An interview for an applied scientist or machine learning position can require a different preparation plan. The worked exercise below is our own practice scenario; it is not an Amazon assessment question or a reconstruction of one.

Get the rules before choosing your tools

Read the assessment email and its linked preparation material first. Amazon’s university SDE page says the assessment structure can vary by country. It permits certain public online resources during the coding assessment, disallows private or login-required resources, and says the submitted code should be your own. That is not blanket permission to open an external chatbot. University SDE online assessment preparation.

Ask your recruiting contact to resolve anything the invitation leaves unclear. Keep permission specific to the round: an assistant provided in one assessment does not establish permission for a later live interview. Practicing with AI beforehand and using it during an assessment are different decisions.

• Does this round include an AI assistant, and must I use the provided one?

• Which documentation, websites, editor extensions, and other tools are allowed?

• Can I run tests and inspect a repository? Is there a practice environment?

• What should I do if the assistant, network, or coding environment stops working?

Prepare to work with AI and without it

Keep your coding fundamentals. Amazon’s published software development topics cover programming, data structures, algorithms, design, databases, and distributed systems, among other areas. It emphasizes applying knowledge and advises candidates to confirm likely topics with their recruiter. The separate SDE II assessment page describes coding, system design, and work styles. Software development interview topics, SDE II assessment preparation.

Split practice into two modes. In one, solve a modest problem without generation: explain the invariant, implement it, and check complexity. In the other, change an unfamiliar repository with an assistant. Read existing behavior, narrow the task, inspect the patch, and verify the result. Neither mode replaces the other.

For the AI session, measure what you understand after accepting a change. Can you explain why a condition exists? Can you remove a mistaken abstraction? Can you diagnose a failure without asking for a complete rewrite? Those questions make better practice targets than the number of prompts you send.

A worked exercise: make an inventory client resilient

Imagine a small commerce repository. An inventory client fetches availability from another service. A temporary outage currently becomes an immediate user-visible failure. Your task is to add bounded retries without changing existing callers. This is an original exercise for practicing engineering judgment with AI.

Begin with the customer consequence: stale availability is inconvenient, but accidentally repeating a purchase request could be worse. A helper that retries every failed HTTP call is therefore too broad. Read the call sites to find out whether the client also handles writes.

Write the contract before asking for code. For this exercise, only GET requests may retry. Retry transport failures and responses with status 429, 502, 503, or 504. Allow at most three total attempts, with waits of 100 and 200 milliseconds. Return other responses immediately. Preserve the final response or error when attempts run out. These are exercise requirements, not a universal HTTP policy.

Caller cancellation must stop further work, including a pending wait. Keep JSON parsing outside the retry loop: invalid response data should not silently trigger another network request. State that jitter and Retry-After support are outside this exercise, then explain when you would revisit them in a production design.

Use the assistant to locate evidence first

Run the existing tests before making changes. Then inspect the client, its exported API, two representative call sites, and the test utilities. Establish how the project injects dependencies and represents errors. An assistant can accelerate this search, but check the files behind its summary.

A repository map is useful only if it changes your next action. Suppose the assistant identifies a shared request helper used by both inventory reads and checkout writes. You now know that retry eligibility belongs at the method boundary, and that a regression test must protect writes.

If its answer is vague, ask for one request traced from the public method to the network call. If it proposes an unrelated refactor, bring it back to the contract. You are buying clarity before buying code.

Find the inventory HTTP client, its callers, and its tests.
Trace one GET request and one write request through the code.
Report the relevant file paths, error behavior, and test command.
Identify how cancellation and timers are currently handled.
Do not edit files yet.

Request a small patch, then challenge it

Give the assistant the agreed contract and ask for the smallest implementation that fits existing conventions. Avoid requesting a new retry framework. A small patch makes it easier to compare intended behavior with actual control flow.

Read the loop yourself. Does three attempts mean one initial call plus two retries, or does the implementation accidentally allow four calls? Does it sleep after the final failure? Does its catch block swallow cancellation? Does it retry a successful response because parsing threw an exception?

Trace three concrete executions on paper: immediate success; two transient failures followed by success; and cancellation during the first wait. At each step, count requests, waits, and the value returned or thrown. This catches mistakes that fluent explanations can conceal.

One subtle failure is checking cancellation only before sleeping. If cancellation arrives during the wait, the code must end the wait without starting another request. Check the project’s existing abort utilities before accepting a fresh implementation with event listeners that may never be removed.

Build tests that can reject a plausible solution

Use a fake transport that returns a sequence of responses or errors. Use controlled timers or an injected wait function so the test can verify delays without spending real time asleep. Assert observable behavior: request count, timing sequence, result, and cancellation.

Write your test cases from the contract before reading generated tests. Otherwise the assistant may simply encode its own assumptions twice. Ask it to identify a buggy implementation that each test would reject. A test that asserts only “returns a response” is not protecting the retry policy.

• GET succeeds immediately: one call, no wait, original response preserved.

• GET returns 503, then 200: two calls and one 100-millisecond wait.

• GET fails three times: exactly three calls, waits of 100 and 200, final failure preserved.

• GET returns 400, or POST returns 503: one call and no retry.

• Caller cancels during a wait: cancellation propagates and no later request starts.

• A successful response contains invalid JSON: parsing fails without another HTTP request.

Make your decisions visible

In a live round that permits AI, narrate decisions rather than reading every prompt aloud. Explain what you are delegating, what evidence you checked, and what remains uncertain. In a self-paced assessment, use the available explanation or submission fields if requested; do not assume there is a particular scoring mechanism for your chat history.

A useful explanation sounds like this: “The proposed helper retries every method. That could repeat a write, so I restricted it to GET and added a POST regression test. I also moved parsing out of the retry boundary because malformed data is not a transient transport failure.”

Finish with evidence and limits: “The focused tests and existing suite pass. We cap work at three attempts and cancel pending waits. The exercise does not implement Retry-After or a total deadline; those would need explicit requirements.” If a check failed or did not run, say so. A confident summary should not erase uncertainty.

Connect Leadership Principles to concrete choices

Amazon publishes Leadership Principles including Customer Obsession, Ownership, Dive Deep, and Earn Trust. Read the official descriptions, then prepare specific examples of your own behavior. Amazon Leadership Principles.

In this practice exercise, customer impact gives the retry restriction a reason: avoid repeating a write. Ownership means explaining the generated code you accepted and repairing its flaws. Investigating an off-by-one attempt count demonstrates attention to detail. Reporting an untested cancellation path honestly makes your explanation more credible. These are our practice connections, not a published scoring rubric.

Prepare one real story about accepting an AI suggestion and later finding it wrong. Explain the context, your decision, the evidence that changed your mind, and the lasting fix. Keep the outcome factual. “We added a regression test that failed on the old implementation” is more useful than claiming that AI made the whole team dramatically faster without measurements.

A five-session preparation plan

Use five focused sessions to make the process repeatable. The schedule below is our recommendation, not an Amazon interview format. Keep a short log after each session: the assumption you missed, the change you rejected, and the test that found a real defect.

• Session 1: confirm the invitation’s rules, try its practice environment, and solve one coding problem without AI.

• Session 2: inspect an unfamiliar client or worker repository; explain the request or job lifecycle before editing.

• Session 3: implement the retry exercise with an assistant, then defend every changed branch and test.

• Session 4: repeat with idempotent webhook handling or job leases. Concentrate on duplicate work and failure recovery.

• Session 5: run a timed rehearsal with a reserved verification window. Give a two-minute handoff covering behavior, evidence, and limitations.