Amazon OA Interview Questions: What's Actually On The Test (And How Not To Choke)

The Amazon OA for SWE new grads is a 90 to 105 minute test with two coding problems, a "work simulation" section full of scenario judgment questions, and a Work Style survey built around Amazon's Leadership Principles. You already know that part. What most people don't know is how the timing actually breaks you, and reading a list of LeetCode tags the night before won't fix that.

What's actually in the Amazon OA?

There are usually four parts, though Amazon shuffles the order and sometimes drops one depending on the team. You'll see two coding questions (roughly 70 minutes total), a work simulation with 15 to 20 scenario based questions (about 20 minutes), a Work Style assessment where you rate agreement with statements tied to Leadership Principles (10 minutes), and sometimes a short debugging or SQL round if the role calls for it. The whole thing lives on HackerRank's platform and it's proctored, so no second monitor, no phone, no wandering off to think.

What do the two coding questions really test?

They're not trick questions. Most are LeetCode medium level: array and string manipulation, BFS/DFS on grids, sliding window, heaps, graph problems, sometimes a tree question. Amazon pulls heavily from a known pool, things like "number of islands" variants, "minimum number of operations to make an array palindrome," "k closest points," job scheduling with two heaps. The twist isn't the algorithm, it's the constraints. You'll get inputs up to 10^5 or 10^6 elements, which quietly tells you your O(n^2) solution is dead before you even submit it. If you're pattern matching but not reading the constraints, you'll write a solution that passes the sample test case and fails 8 of 15 hidden ones. That's the trap.

The scoring isn't pass/fail per problem either. HackerRank gives partial credit based on how many hidden test cases you pass, so a working brute force that handles 60% of cases beats an elegant unfinished attempt at the optimal solution. Know when to cut your losses and just get something running.

What is the work simulation section actually testing?

This is the part almost nobody prepares for and it's arguably harder to game than the coding. You get a fictional scenario, usually you're a new employee on a team dealing with a project issue, a difficult stakeholder, a missed deadline, or a customer complaint. Then you answer multiple choice questions like "what would you do first" or "rank these three responses from most to least effective."

There's no single correct answer key floating around online because Amazon varies the scenarios, but the scoring logic is consistent: they're checking whether your instinct is to escalate appropriately, take ownership, and act with customer obsession and bias for action rather than deflecting blame or waiting for permission. If your gut response in a scenario is "I would ask my manager what to do," that's usually the wrong pick. Amazon wants to see you diagnose the problem and act, then loop in others when it matters.

Does the Work Style survey actually matter?

Yes, more than people assume. You'll rate statements like "I prefer to dive deep into details rather than delegate" or "I get uncomfortable when plans change quickly" on a scale. It's mapped against the 16 Leadership Principles, and Amazon is checking for consistency, not just "good" answers. If you answer every question as the maximally agreeable, ownership obsessed, customer first version of yourself, the pattern looks fake and inconsistent responses can flag you. Answer honestly but keep the LPs in the back of your mind, especially Ownership, Bias for Action, and Customer Obsession, since those show up most in Amazon's actual behavioral interviews later.

How does the timing actually break people?

Here's the part that trips up strong coders. You get roughly 70 minutes for two problems, which sounds fine until you spend 25 minutes on problem one because you misread a constraint, then panic-code problem two with 20 minutes left and no time to debug. The proctoring adds pressure too. No pausing, no looking away for too long, a visible timer counting down in the corner of your screen the entire time. People who code fine untimed in a relaxed setting freeze up when the clock is loud and there's no one to talk through the approach with.

The work simulation section has its own time crunch: you get about a minute per scenario on average, and some of them have three or four paragraphs of context to read before you even get to the question. If you're a slow reader under pressure, this section eats more time than people expect.

How should you actually spend the 90 minutes?

Don't dive into code the second you read problem one. Spend 3 to 5 minutes confirming the constraints and picking your approach out loud (even if it's just in your head), because switching strategies halfway through problem one at minute 20 is how people run out of time on problem two entirely. A rough rule: cap yourself at 30 minutes on problem one no matter what. If you're stuck, get a brute force submitted for partial credit and move to problem two. A half working solution on both problems almost always beats a perfect solution on one and a blank screen on the other.

For the work simulation section, don't overthink it. These aren't puzzles with a hidden trick, they're testing gut instinct. Read fast, pick the answer that shows ownership and action, and move on. Spending five minutes debating between two similar-sounding options is worse than picking one and banking the time.

Why reading about this isn't the same as sitting it

You can read every article about the Amazon OA format, memorize the LP list, and still freeze when the timer actually starts and the constraints say n could be 10^6. The gap isn't knowledge, it's reps under real pressure with someone (or something) telling you honestly where you fell apart, not just whether your code compiled.

Hackcepted's AI mock panel runs you through Amazon-style coding pressure and pushes back the way a real proctor or interviewer would, then gives you a Crash Report showing exactly where your timing broke down and which answers would've cost you the offer. If your Amazon OA is coming up fast, running one full mock tonight will tell you more in 45 minutes than another hour of reading ever will.

FAQ

How many coding questions are on the Amazon OA?

Most SWE new grad OAs have two coding problems, usually medium difficulty and pulled from a known Amazon question pool. Occasionally you'll see a debugging or SQL section added depending on the specific team.

Is the Amazon OA work simulation section scored the same as coding?

It's scored separately and weighted alongside the Work Style survey to assess judgment and alignment with the Leadership Principles. A weak coding score can sometimes still be offset by a strong work simulation and interview performance, so don't ignore this section.

What happens if I don't finish both coding problems?

HackerRank gives partial credit based on hidden test cases passed, so a partially working solution on both problems usually scores better than a perfect solution on one and nothing on the other. Always submit something for problem two even if it's incomplete.

How long after the Amazon OA do you hear back?

Typically one to two weeks if you're moving forward to virtual onsite interviews, though it can vary by team and hiring season. No response after three weeks usually means you didn't clear the bar this round.