Amazon hub
Amazon Online Assessment
Overview
Amazon online assessment (OA) is the first hard filter for most fresher, campus, and off-campus SDE-style drives. This page covers the Amazon OA format, what happens after you clear it, sample Amazon OA questions with approaches, an 8-week prep plan, and mistakes that sink otherwise-strong candidates.
Patterns below are from student reports for 2025-2026. Platforms and section names can change by drive. Always confirm the college placement email for your window.
Amazon hiring flow after the OA
| Stage | What candidates report | What you must show |
|---|---|---|
| 1. Online assessment | Often 70-120 min: 2 coding problems + work simulation / debugging + LP-style behavioral MCQs | Correctness + reasonable complexity under time |
| 2. Technical interviews | Multiple DSA rounds; every round mixes coding with Leadership Principles | Explain approach, edge cases, complexity |
| 3. Later rounds | Bar Raiser is mandatory on many loops; system design depth scales with level | Depth beyond the OA pattern |
| 4. HR / offer | Role, location, CTC discussion | Consistency with resume |
Amazon Online Assessment format
Test structure
| Component | From student reports details |
|---|---|
| Platform | HackerRank or Amazon OA platform |
| Duration | About 70-120 minutes depending on invite |
| Question mix | 2 coding (DSA) + work simulation / scenario tasks + behavioral MCQs |
| Languages | Java, C++, Python, C# (pick one you can debug fast) |
| Scoring | Automated tests on coding; simulation and MCQs scored separately; partial credit varies |
| Advance rate | Roughly 15-25% of applicants clear OA in many campus-style reports |
What makes Amazon OA feel distinct
- Coding alone is not enough: work simulation and Leadership Principles signals appear early
- Problems often need clean edge-case handling more than exotic algorithms
- Amazon-tagged LeetCode patterns (graphs, sliding window, heaps) show up frequently in candidate reports
- Time pressure is real: leaving one coding problem unsubmitted usually ends the OA
Question types you should expect
Core DSA
- Arrays, strings, hashing, sliding window
- Graphs and trees (BFS/DFS, topological ideas)
- Heaps / priority queues, intervals
- Dynamic programming and greedy when constraints allow
- Occasional bit manipulation or design-lite coding
Secondary / role-dependent
- Work-simulation style judgment (emails, debugging a small system, prioritizing tasks)
- Behavioral MCQs mapped to Leadership Principles
- Debugging snippets where the bug is logical, not just syntax
What usually does not appear in the OA
- Full system design interviews (those come later)
- Long aptitude batteries like service-company NQT papers
- HR salary negotiation (offer stage)
Sample Amazon Online Assessment questions
Question 1: maximum profit with one transaction
Q: Prices of a product over n days are given. Buy once and sell once later. Maximum profit?
Track the minimum price so far and the best price - minSoFar. O(n) time, O(1) space. Edge cases: empty array, strictly decreasing prices (profit 0).
This is the classic Best Time to Buy and Sell Stock pattern frequently reported in Amazon-style screens.
Question 2: top-k frequent order ids
Q: Given a stream of product IDs, return the k most frequent IDs.
Count with a hash map, then a heap of size k (or bucket sort by frequency). Average O(n log k) with a heap.
Watch ties: clarify whether any valid top-k is accepted.
Question 3: number of islands / warehouse zones
Q: Grid of 1/0 cells. Count connected components of 1s (4-directional).
DFS/BFS flood fill. Mark visited in-place if allowed. O(rows * cols).
Amazon reports often include grid/graph connectivity variants.
Question 4: merge overlapping delivery windows
Q: Merge overlapping intervals [start, end].
Sort by start. If the next interval starts at or before the current end, extend the end; else push current and move on.
O(n log n) from sorting.
Question 5: debug a failing rate limiter
Q: A hit-counter should return hits in the last 300 seconds but returns stale counts.
Typical bug: forgetting to evict timestamps outside the window before counting. Fix with a queue of timestamps and pop while the front is older than the window.
Question 6: Leadership Principles judgment
Q: A teammate wants to ship a feature with known data-quality risk to hit a date. What do you do?
Amazon-style answers favor Customer Obsession and Dive Deep: surface the risk, propose a measured mitigation, and avoid silent ship. Practice STAR stories for Bias for Action vs Insistence on Highest Standards trade-offs.
How to prepare for Amazon OA (8-week plan)
| Weeks | Focus | Exit criteria |
|---|---|---|
| 1-2 | Arrays, hashing, two pointers, sliding window | 40+ easy/medium solved cleanly |
| 3-4 | Trees, graphs (BFS/DFS), heaps | Can code BFS/DFS without notes |
| 5-6 | DP + greedy patterns (plus Amazon LP story outlines in parallel) | 25+ medium DP/greedy with recursion to bottom-up |
| 7 | Timed full mocks matching About 70-120 minutes depending on invite | Finish both coding problems with solid tests with passing tests |
| 8 | Weak-topic repair + complexity review | Re-solve every miss within 48 hours |
Daily loop
- One timed medium problem (45-60 min hard cap)
- Write complexity and 3 edge cases before coding
- If stuck past 20 minutes, peek pattern name only, then re-solve tomorrow cold
- Log misses by topic on a simple sheet
Company pages on this site
- Amazon coding questions
- Amazon aptitude / mock quiz
- Amazon interview experience
- Amazon preparation guide
- Practice PDF: Amazon Placement Papers PDF (2026)
Common mistakes on Amazon OA
- Spending 50 minutes on problem 1 and submitting nothing for problem 2
- Ignoring constraints and shipping O(n^2) when n is clearly large
- Skipping work simulation / MCQs because “coding matters more” (it all counts)
- No Leadership Principles stories ready even though OA/interviews expect them
- Copy-paste templates you cannot explain in the next interview
Day-of checklist
- Stable internet, charged laptop, quiet room
- Confirm language template compiles on the platform before starting hard problems
- Skim all problems for 3-4 minutes, order by familiarity
- Submit a correct brute force early if constraints allow, then optimize
- Leave 8-10 minutes for edge-case tests you invent yourself