I just finished this Amazon SDE OA, and I had to write it down because it was completely different from every Amazon OA I've taken before. The first problem was the familiar algorithm question, but the second one took me by surprise—it dropped me into a fully working Django project and asked me to fix and extend existing functionality. Looks like Amazon has officially embraced the AI Coding interview trend.
The entire assessment lasted 90 minutes. I spent about 35 minutes on the first problem and devoted almost all of the remaining time to the second. My biggest takeaway is this: this new format is much less friendly for candidates who only grind LeetCode. If you've actually built projects before and are comfortable reading other people's code, this section can actually be easier than another hard algorithm question. Below is a complete breakdown of both questions.
What Is Amazon AI Coding?
I had never seen this format before, so it caught me off guard. Instead of writing a function from scratch, Amazon provides a complete runnable project with dozens of files. Your job is to understand the existing codebase, fix bugs, implement missing features, and pass all the provided pytest cases.
The biggest differences compared with the traditional OA are:
- Instead of an empty function, you work inside a real project repository.
- Your score depends entirely on passing the test suite rather than code style.
- The environment is a full IDE where you can edit multiple files and run tests during the assessment.
If you're interested in Amazon's official explanation of this new format, you can check their preparation materials for the SDE Online Assessment.
OA Structure
The assessment runs on Amazon's own platform. There are two sections (S1 and S2), each containing one problem. The timing felt generous. After finishing the first algorithm question, I still had nearly an hour left for the AI Coding section.
- Question 1: Traditional coding problem with hidden test cases.
- Question 2: Complete Django project with multiple files, file explorer, and built-in test runner.
Question 1 — Grid Distribution Centers
You are given a binary grid where every 1 represents an existing distribution center. Distance is measured using the Chebyshev distance:
max(|dx|, |dy|)
You may convert at most one 0 into a new distribution center. The objective is to minimize the maximum distance from every cell to its nearest distribution center. Return that minimum possible value.
My Solution
First, perform a multi-source BFS starting from every existing distribution center to compute the distance from each cell to its nearest center. Since Chebyshev distance allows movement in eight directions, the BFS expands in all eight neighboring cells. A two-pass dynamic programming solution also works.
The answer is monotonic.
If distance d is feasible, then every larger distance is also feasible, which naturally leads to binary search.
Inside the feasibility check, collect every cell whose current distance exceeds the candidate value.
Each of these cells must be covered by the newly added center.
Under Chebyshev distance, the coverage area becomes a square with side length 2 × mid + 1.
The problem therefore reduces to determining whether all these coverage squares share a common intersection containing at least one valid grid cell.
Maintaining the maximum and minimum x/y coordinates is sufficient to test whether the intersection exists.
The geometric property of Chebyshev distance makes this solution especially clean because every coverage region is a square rather than a circle.
Overall complexity is approximately O(nm log(max(n,m))).
Question 2 — Fixing Recurring Wallet Transfers
The second problem provided a complete Django wallet application. The recurring payment functionality was intentionally broken. The task was to repair it while supporting recurring transfers, request validation, and scheduled execution.
My Solution
Most of the work happened inside the serializer. I added several validation rules:
- The start date cannot be later than the end date.
- The transfer amount must be greater than zero.
- The sender and receiver cannot be the same wallet.
- Invalid requests immediately raise
ValidationError.
When executing a recurring payment, I checked:
- Whether the payment is still active.
- Whether the current date has reached the next scheduled payment time.
- Whether the sender has sufficient balance.
The easiest bug to miss was updating last_payment_date.
Without updating this field after a successful transfer, the same payment would execute repeatedly during the same cycle.
One of the hidden tests specifically checked this scenario, and I failed it on my first attempt.
I also wrapped the transfer inside a database transaction so that deducting the sender balance and crediting the receiver remain atomic.
Compared with the algorithm question, this task rewarded code-reading skills much more than coding speed. Instead of reading every file from top to bottom, I strongly recommend starting with the README and the failing test cases. Working backward from the tests dramatically reduces the amount of code you need to understand.
Final Thoughts
Overall, I'd rate the OA as moderate difficulty. The first problem becomes manageable once you identify the binary search plus intersection approach. The second problem is mostly about careful debugging and understanding an unfamiliar codebase.
One more preparation tip. Traditional LeetCode practice does not prepare you for this new AI Coding format. You'll need experience working inside real projects, reading existing code, and fixing failing tests.
I've been practicing with the Amazon AI Coding question bank on InterviewShow, which now includes project-based AI Coding exercises similar to the new OA. They also offer Amazon mock interviews before VO rounds, making it easier to adapt to the latest interview style. If you've recently received an Amazon OA invitation and aren't sure what to expect, it's worth checking out.
Good luck, and I hope everyone gets that green "All Tests Passed."
Top comments (0)