Amazon Online Assessment (OA) Guide: Coding, Work Style and Debugging Sections

For most candidates, the Amazon online assessment is the real gate. Amazon receives far more applications than it can interview, so the OA filters the pool down before a recruiter schedules anything. Clear it and you're in the interview loop; fail it and you'll usually wait months to try again.

This guide breaks down each section of the OA as it is commonly reported for SDE roles in India, solves three Amazon-style problems end to end in C++ and Python with dry runs, explains the debugging and work style sections, and closes with a two-week plan and what happens after you submit. For the full interview loop that follows, see our Amazon India SDE interview guide.

Amazon OA Structure: Sections and Timing

Amazon has changed its OA format several times, and it differs between internship, new-grad and experienced SDE roles. Here is the structure most commonly reported by candidates in recent cycles. Use your invite email as the source of truth; it lists the sections and time limits.

The Coding Section: Difficulty, Topics and Scoring

The two coding problems are usually LeetCode medium in difficulty, with an occasional easy or hard. They're typically framed as Amazon scenarios: packages and delivery trucks, warehouse grids, server logs, product recommendations, Prime Video watch history. Underneath the story, they map to standard patterns.

How scoring works

Your code runs against a set of hidden test cases, some small and some at the maximum constraints. Each passed case earns credit. Amazon doesn't publish a pass mark. Candidates commonly report moving forward after passing all or nearly all cases on both problems, and being rejected with weak results on one. Practically, that means:

• An efficient, correct solution on both problems is the target.
• If you're stuck on the optimal approach, submitting a correct brute force earns the small-input cases. Partial credit beats zero.
• Edge cases (empty input, single element, all equal, maximum values causing overflow) are where many hidden cases live.

Below are three original Amazon-style problems that cover the most common patterns. Each has a story, constraints, the insight, code in C++ and Python, a dry run and complexity.

Problem 1: Minimum Delivery Trips (Greedy + Two Pointers)

Problem. A delivery van can carry at most two packages per trip, and their combined weight must not exceed limit. Given n package weights (each ≤ limit), return the minimum number of trips to deliver all of them. Constraints: 1 ≤ n ≤ 10⁵, 1 ≤ weight ≤ limit ≤ 10⁹.

Insight

Sort the weights. The heaviest package must go on some trip. The best partner for it is the lightest remaining package: if even the lightest can't fit with it, nothing can, so the heaviest goes alone. If the lightest does fit, pairing them never hurts, because any other partner would be heavier and leave a worse set behind (a standard exchange argument). Two pointers, one at each end, implement this.

int minTrips(vector<int> w, int limit) {
    sort(w.begin(), w.end());
    int i = 0, j = (int)w.size() - 1, trips = 0;
    while (i <= j) {
        if (i < j && w[i] + w[j] <= limit) i++;  // lightest rides with heaviest
        j--;                                    // heaviest always leaves
        trips++;
    }
    return trips;
}

def min_trips(weights, limit):
    w = sorted(weights)
    i, j, trips = 0, len(w) - 1, 0
    while i <= j:
        if i < j and w[i] + w[j] <= limit:
            i += 1
        j -= 1
        trips += 1
    return trips

Dry run

Input: weights = [70, 50, 80, 50], limit = 100. Sorted: [50, 50, 70, 80].

Loop ends (i = 1 > j = 0). Answer: 3.

Complexity: O(n log n) time for sorting, O(1) extra space beyond the sort (O(n) in Python because sorted copies). The i < j check matters: without it, when one package remains, the code would compare it with itself.

Problem 2: Minimum Cost to Merge Files (Min-Heap)

Problem. An Amazon service must merge n log files into one. Merging two files of sizes a and b costs a + b and produces a file of size a + b. Return the minimum total cost. Constraints: 1 ≤ n ≤ 10⁵, 1 ≤ size ≤ 10⁹.

Insight

Every file's size is added to the total once for each merge it participates in, so large files should be merged as few times as possible, i.e. as late as possible. Repeatedly merging the two smallest files is optimal (the same argument as Huffman coding). A min-heap gives the two smallest in O(log n) each.

Watch the numbers: with n = 10⁵ files of size 10⁹, the total cost far exceeds 2³¹. Use long long in C++ (or long in Java). Overflow here is one of the most common reasons for failing hidden test cases.

long long minMergeCost(const vector<int>& files) {
    priority_queue<long long, vector<long long>, greater<long long>> pq(files.begin(), files.end());
    long long cost = 0;
    while (pq.size() > 1) {
        long long a = pq.top(); pq.pop();
        long long b = pq.top(); pq.pop();
        cost += a + b;
        pq.push(a + b);
    }
    return cost;
}

import heapq

def min_merge_cost(files):
    heap = list(files)
    heapq.heapify(heap)          # O(n)
    cost = 0
    while len(heap) > 1:
        a = heapq.heappop(heap)
        b = heapq.heappop(heap)
        cost += a + b
        heapq.heappush(heap, a + b)
    return cost

Dry run

Input: [8, 4, 6, 12].

Answer: 58. Compare a naive left-to-right order (8+4=12, 12+6=18, 18+12=30, total 60) to see why order matters.

Complexity: O(n log n) time, O(n) space. With n = 1, the loop never runs and the cost is 0, which is correct.

Problem 3: Warehouse Robot Shortest Path (Grid BFS)

Problem. A robot starts at the top-left cell of an R × C warehouse grid. Cells are 1 (free), 0 (blocked shelf) or 9 (the target shelf, reachable). The robot moves up, down, left or right. Return the minimum number of moves to reach the target, or -1 if it can't. Constraints: 1 ≤ R, C ≤ 1000.

Insight

Every move costs 1, so breadth-first search finds the shortest path: BFS visits cells in order of distance from the start. Mark cells visited when you push them, not when you pop them; otherwise the same cell can be queued many times and a 10⁶-cell grid can time out or run out of memory.

int shortestPath(const vector<vector<int>>& g) {
    int R = g.size(), C = g[0].size();
    if (g[0][0] == 0) return -1;
    vector<vector<int>> dist(R, vector<int>(C, -1));
    queue<pair<int,int>> q;
    q.push({0, 0});
    dist[0][0] = 0;
    int dr[] = {1, -1, 0, 0}, dc[] = {0, 0, 1, -1};
    while (!q.empty()) {
        int r = q.front().first, c = q.front().second; q.pop();
        if (g[r][c] == 9) return dist[r][c];
        for (int k = 0; k < 4; k++) {
            int nr = r + dr[k], nc = c + dc[k];
            if (nr < 0 || nc < 0 || nr >= R || nc >= C) continue;
            if (g[nr][nc] == 0 || dist[nr][nc] != -1) continue;
            dist[nr][nc] = dist[r][c] + 1;   // mark on push
            q.push({nr, nc});
        }
    }
    return -1;
}

from collections import deque

def shortest_path(grid):
    rows, cols = len(grid), len(grid[0])
    if grid[0][0] == 0:
        return -1
    dist = [[-1] * cols for _ in range(rows)]
    dist[0][0] = 0
    q = deque([(0, 0)])
    while q:
        r, c = q.popleft()
        if grid[r][c] == 9:
            return dist[r][c]
        for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)):
            nr, nc = r + dr, c + dc
            if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] != 0 and dist[nr][nc] == -1:
                dist[nr][nc] = dist[r][c] + 1
                q.append((nr, nc))
    return -1

Dry run

BFS expands distance 0 → (0,0); distance 1 → (0,1); distance 2 → (0,2), (1,1); distance 3 → (0,3), (2,1); distance 4 → (1,3), (2,0); distance 5 → (2,3), which is the target 9. Answer: 5. If the target were walled off, the queue would empty and we'd return -1.

Complexity: O(R × C) time and space; each cell is pushed at most once and checks four neighbours. Use deque in Python, never list.pop(0), which is O(n) per pop.

The Debugging Section: How to Approach It

Where it appears, the debugging section gives you short functions (often in C, C++ or Java) that contain one bug each, usually a logic or boundary error rather than a syntax error. You get a fixed time for several snippets, so speed matters. Typical bug types:

• Off-by-one in loop bounds (<= vs <, starting at 1 instead of 0).
• Wrong comparison operator (> instead of < in a sort or max/min).
• Wrong variable used (i instead of j), or a variable not reset inside a loop.
• Integer division or overflow issues.
• Wrong return value (returning a counter instead of the result).

Example

The function should count pairs (i, j) with i < j and a[i] + a[j] == target:

int countPairs(int[] a, int target) {
    int count = 0;
    for (int i = 0; i < a.length; i++) {
        for (int j = 0; j < a.length; j++) {
            if (a[i] + a[j] == target) count++;
        }
    }
    return count;
}

The bug: the inner loop starts at 0, so it counts each pair twice and pairs an element with itself. The fix is one token: int j = i + 1. Debugging questions are usually like this, where the fix is small and the skill is spotting it fast.

Method: read the function's stated purpose, run a tiny example by hand (2–3 elements), and compare against expected output. Most bugs reveal themselves on a 3-element dry run within a minute.

The Work Style Survey and Work Simulation

Work style assessment

You'll see statements about how you work and choose how strongly you agree, or pick the statement from a pair that describes you better. The assessment maps to Amazon's Leadership Principles, such as Customer Obsession, Ownership, Bias for Action, Dive Deep, Deliver Results and Earn Trust.

Guidance that holds up:

• Read the Leadership Principles before the OA. Not to game the survey, but to understand what kinds of behaviour Amazon values. You'll need them for the interviews anyway.
• Answer honestly and consistently. Similar ideas are asked in different ways. Wildly inconsistent answers can look worse than honest moderate ones.
• Don't overthink. Go with your considered first instinct; the section is timed.

Work simulation

The work simulation puts you in a realistic scenario, for example a day on a software team, with messages from a manager or teammates, a customer-impacting issue, a deadline. You choose or rank responses. It tests judgment: do you prioritise customer impact, gather data before acting, communicate proactively, take ownership instead of escalating everything?

A useful lens for each scenario: What does the customer need? What's the fastest responsible action? Who needs to know? Options that ignore customer impact, hide problems or wait passively for instructions are usually the weaker choices. Options that act reasonably fast on available data while keeping stakeholders informed usually reflect Amazon's principles.

A Two-Week Amazon OA Preparation Plan

If you already know basic DSA and your OA link has just arrived (or is expected soon), this plan focuses on the patterns and conditions of the OA itself.

1. Days 1–3: Greedy, sorting, two pointers, hashing. 4–5 medium problems a day. For each, write the one-line insight and the complexity before coding.
2. Days 4–6: Heaps and intervals. Top-k, merge-k, scheduling with priority queues, interval merging. Practise writing heap comparators quickly in your language.
3. Days 7–9: Graphs and grids. BFS shortest path, connected components, multi-source BFS, topological sort. Write BFS from scratch each time until it takes under 3 minutes.
4. Days 10–11: Sliding window, prefix sums and basic DP. These appear often enough that you shouldn't skip them.
5. Days 12–13: Timed mocks. Two full simulations: two problems in about 70–90 minutes on a HackerRank-style editor, with no IDE autocomplete. Review every failed edge case.
6. Day 14: Leadership Principles and logistics. Read the principles; skim your mock mistakes; test your laptop, internet, and the platform's sample test if provided.

Our general guide to clearing online coding assessments covers the editor, I/O handling, partial-score strategy and proctoring rules in more depth.

During the OA: a time plan

What Happens After the Amazon OA

After you submit, outcomes typically fall into three buckets:

• Cleared: a recruiter emails to schedule interviews. For SDE-1 and new-grad roles in India, candidates commonly report a few rounds (often around three), sometimes as a single-day virtual loop. Each round mixes coding with Leadership Principles questions, and a bar raiser may be one of the interviewers.
• Not cleared: usually an automated email. Candidates commonly report a cooling-off period, often around six months, before reapplying for similar roles; confirm with the recruiter.
• Silence: timelines vary from days to several weeks depending on hiring volume. A polite follow-up to the recruiter after two to three weeks is fine.

Preparing for the interviews while you wait

Don't wait for the result to start interview prep. The loop typically includes coding problems similar to OA difficulty, plus behavioural questions where you're expected to answer with specific stories mapped to Leadership Principles. Prepare 8–10 STAR stories (ownership, disagreement, failure, tight deadline, customer impact, diving deep into a bug). Our guide to the STAR method shows how to structure them, and the Amazon interview preparation guide covers the loop round by round.

The Amazon OA is very passable with focused preparation. Know the core patterns cold, practise under real time pressure, guard against overflow and edge cases, understand the Leadership Principles, and treat the work style sections with the same seriousness as the code.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.