Amazon SDE OA

This is our company-specific playbook for the Amazon SDE Online Assessment, written from the official Amazon invite email. The OA is not just DSA — it’s a 3-section test, and one of the two coding problems is in an AI-assisted code repo environment, which surprises a lot of candidates.

Read this end-to-end the night before, and again 30 minutes before the OA starts.

A. Format & Expectations

From the official Amazon invite email:

• Total recommended time: set aside ~2.5 hours in a quiet location
• Deadline: complete within 1 week of receiving the invite
• Sections: 3 total

Hard rules from the email

• Latest Chrome or Edge. Stable internet.
• Single monitor required for the coding challenge — disconnect any external monitors before starting.
• Full-screen IDE. All compilers, libraries, and tools are provided in the platform. No personal IDEs. No outside resources.
• The coding-challenge timer cannot be paused once started. Complete it in one sitting.
• Don’t repeatedly refresh the page. If there’s a real technical issue, log out and log back in.

B. Section 1 — Coding Challenge (100 min, 2 problems)

The biggest format surprise: Problem 1 and Problem 2 are completely different. Problem 1 is a classic LeetCode-style question. Problem 2 is in a code repository with an AI coding assistant available.

Suggested pacing: ~45 min on Problem 1, ~50 min on Problem 2, ~5 min buffer. If we crush Problem 1 fast, bank the time for Problem 2 — the repo question almost always eats more time than expected.

B1. Problem 1 — Traditional code question (~45 min)

A standard “given this input, return this output” problem. ~15 test cases (2 public + 13 private). Partial credit counts — every passing case is points.

Language choice: Amazon allows C, C++, C++14, C#, Go, Java 7/8, JavaScript (Node.js), Kotlin, Objective-C, PyPy, PyPy3, Python 2, Python 3, Ruby, Scala, Swift.

In simple language: pick JavaScript (Node.js) or Python 3 — whichever we’re fastest in. Both have rich standard libraries (Map, Set, heapq/PriorityQueue, etc.) that save time vs writing it from scratch in Java/C++.

What Amazon loves to ask

Recent reports show the same patterns dressed in different stories (delivery routes, warehouse layout, package sorting). The story is decoration — underneath, it’s almost always one of these patterns.

If we can recognize the pattern in the first 60 seconds, we’re already halfway done.

Topic priority — what to revise tonight

Tier 1 — Must revise (highest Amazon OA frequency)

• Hash Maps and Sets — frequency counting, Two Sum family, dedup
• Prefix Sum and Difference Arrays — subarray sum, range queries
• Sliding Window — fixed + dynamic window, “at most K distinct”
• Two Pointers — paired with sliding window, sorted-array problems
• BFS and DFS — grid traversal, connected components, level order
• Graph Representations — adjacency list, building graph from edges
• Intervals — merge, insert, meeting rooms, non-overlapping
• Greedy Algorithms — interval scheduling, exchange argument

Tier 2 — Strongly recommended

• Priority Queues and Heaps — Kth largest, Top-K frequent, merge-K
• Binary Search — clean template, lower/upper bound
• Binary Search on Answer — Amazon disguises this as “minimum feasible X”
• DP Fundamentals — memoization → tabulation mental model
• 1D DP Patterns — House Robber, Coin Change, LIS, max subarray

Tier 3 — Skim only (if time permits)

• Arrays and Operations — quick refresher on in-place tricks
• Monotonic Stack — next greater element, one classic problem
• Binary Trees — DFS recursion, level-order BFS
• Topological Sort — Kahn’s algorithm in one read
• Bit Manipulation — XOR tricks, single number
• Common Interview Patterns — read this last, as the final pattern-recall recap

Skip tonight (low ROI for one night): advanced graphs (Bellman-Ford, Floyd-Warshall), Union-Find, 2D DP, knapsack, interval DP, DP on trees, tries, backtracking, sorting algorithm internals, string matching (KMP/Rabin-Karp).

Tonight’s revision plan (~6 hours)

How to revise each note (this is the key)

Don’t re-read end-to-end. Instead, for each note:

1. Read the pattern signature — when do we apply this technique?
2. Re-derive the template code from memory, then check against the note.
3. Recall 2–3 canonical problems and the mental trigger that maps each to this pattern.

This is what trains pattern-recall under OA time pressure. The bottleneck isn’t algorithm knowledge — it’s recognizing the pattern fast under stress.

Day-of tactics for Problem 1

• Brute force first. Write it, state the complexity, then optimize. Don’t freeze trying to find the optimal solution upfront.
• Restate the problem in our own words before writing any code. Catches misread story-wrapped questions.
• Edge-case checklist: empty input, single element, all duplicates, negative numbers, integer overflow.
• 8-minute stuck rule: if stuck >8 minutes on optimization, submit the brute force and move on. Partial points matter.

B2. Problem 2 — Code repository with AI assistant (~50 min)

This is the section most candidates underestimate. It’s not a second LeetCode-style problem.

What it actually is

In simple language: imagine we’re opening an existing repo in a HackerRank IDE. There are multiple files. There’s a README that tells us what to do. There’s an AI coding assistant in a sidebar panel that we can chat with for help.

The task is usually one of:

• Complete a function inside an existing class.
• Fix a failing test.
• Add a new method to a service.
• Implement a small algorithm given the function signature and a stub.

We’re not writing a solution from scratch — we’re working inside someone else’s code.

Locked in: pick the language carefully

The language is locked once Problem 2 starts. We can’t change it mid-problem. The list is also a subset — fewer languages than Problem 1.

Recommendation: JavaScript (Node.js) or Python 3, unless the task screen obviously hints at a Java-only stub (e.g., the repo uses Spring or Maven).

How to use the AI assistant well

Amazon is explicitly testing how we work with AI, not whether we can avoid it. Using it badly is worse than not using it.

1. Use it as a pair-programmer, not a replacement. Ask narrow questions: “explain what this function does”, “is there an off-by-one error here?”, “what’s the time complexity of this loop?”. Don’t ask “solve this problem for me.”
2. Read every line the AI gives us. AI suggestions can compile but be wrong on edge cases. Trace through the test cases by hand before accepting.
3. Don’t paste large code chunks back-and-forth — it wastes our 50 minutes. Use the AI for targeted help: “is there a built-in for X in Python?”, “what’s the idiomatic way to deep-clone in JS?”.
4. Show our thinking. If we ask the AI to verify our approach (“does this handle the empty-array case?”), that’s better than asking it to write the approach.

How to approach the repo

1. Read the README/instructions first. They tell us where to make changes and what’s already done. Don’t skip this.
2. Run the existing tests once before changing anything. Confirms the baseline — we know what’s passing vs failing.
3. Trace through one passing test by hand to understand the data flow before touching anything.
4. Make the smallest change that passes the failing test. Amazon scores correctness, not creativity.
5. Don’t refactor. Don’t rename. Don’t “clean up.” Just complete the task.
6. If we get stuck on file structure, ask the AI: “what does the file X.js do in this project?” — it can read the repo and answer.

Common traps

• Editing the wrong file. The repo has multiple files — only one usually needs changes. The README tells us which.
• Over-engineering. The expected solution is small. If we find ourselves writing 100 lines, we’re probably off-path.
• Trusting the AI’s first answer. Always check edge cases ourselves.
• Spending too long understanding the codebase. 5 minutes max for orientation, then start coding.

C. Section 2 — Work Simulation (~15 min)

This is a short section about “software development decisions faced by SDEs at Amazon” — likely multiple-choice scenario questions about everyday engineering judgment calls.

What it actually is

15 minutes is tight, which suggests short scenarios with 3–5 options each. Examples of likely questions:

• “A teammate’s PR is blocking ours and they’re OOO until Monday — what do we do?”
• “The staging build is red but a customer needs the fix shipped today — what’s the right call?”
• “A code review surfaces both a style nit and a real bug — which do we comment on first?”
• “Our oncall pager goes off during a feature deadline crunch — how do we handle it?”
• “A junior teammate’s design has a subtle flaw — how do we give feedback?”

How to score well

Don’t overthink. Read each scenario, pick the option that’s:

1. Most customer-centric — does it help the user? (Customer Obsession)
2. Most data-driven — does it use the metrics/logs available before guessing? (Are Right, A Lot)
3. Most action-oriented but not reckless — does it move things forward with a rollback plan? (Bias for Action)
4. Most professional toward teammates — peer-level resolution before escalation? (Earn Trust + Ownership)

If the scenario is longer than expected (some candidates have reported emails-and-attachments style scenarios that take more than 15 min), fall back to the principles in Section E — the Leadership Principles are the rubric for the whole section regardless of length.

D. Section 3 — Work Style Surveys (~10 min, 2 surveys)

Two short surveys, ~5 minutes each.

• Survey 1: how we approach software engineering work specifically.
• Survey 2: how we approach work in general.

What they’re measuring

Both surveys map to Amazon’s 16 Leadership Principles (section E below). They’re written as agree/disagree statements, forced-choice pairs, or “which is more like you?” questions.

Likely question patterns

Survey 1 (engineering):

• “I prefer to write tests before code.”
• “I review my own PRs before requesting a review.”
• “I escalate blockers immediately vs try to unblock myself first.”
• “I’d rather ship a smaller working version on time than a bigger version late.”

Survey 2 (general work):

• “I prefer detailed direction vs ambiguous goals.”
• “I’d rather work alone vs collaboratively.”
• “When I disagree with a decision, I push back vs commit and move on.”
• “I’m energized by tight deadlines vs steady pace.”

How to prep (15 min, tonight)

1. Read the LP cheat-sheet (section E) once carefully.
2. For each LP, think of one real example from past work:
   • Ownership — designed the Naukri automation cron without anyone asking.
   • Dive Deep — went into Roposo-BE schema decisions instead of accepting defaults.
   • Customer Obsession — built Cellscope because we needed a faster CSV preview ourselves.
   • Bias for Action — shipped brute-force versions first, optimized later.
3. We won’t write these stories during the OA — they just keep our answers consistent.

How to answer

• Don’t be extreme on every question. Picking “Strongly Agree” on 50 questions in a row looks gamed. A few neutrals are realistic.
• Be consistent. Both surveys ask similar ideas worded differently. Stay coherent across them.
• When two LPs conflict in a question (e.g., Bias for Action vs Are Right A Lot), lean Customer Obsession + Deliver Results — those are the highest-weight LPs at Amazon.
• Don’t pick “I avoid conflict” — Amazon explicitly rewards “Have Backbone; Disagree and Commit.”
• Don’t pick “I escalate immediately” — that conflicts with Ownership.

E. Amazon’s 16 Leadership Principles (plain English)

These are the actual yardstick for both the Work Simulation and the Work Style Surveys. Each LP below: what it means in simple language + when it shows up.

1. Customer Obsession

Start from the customer and work backwards. Earn and keep their trust.

Shows up when: a tradeoff pits user benefit against internal convenience — pick the user.

2. Ownership

Act like an owner. Think long-term. Never say “that’s not my job.”

Shows up when: we spot a problem outside our scope. Own it, or route it to someone who can — don’t ignore it.

3. Invent and Simplify

Look for simpler ways. Don’t accept “we’ve always done it this way.”

Shows up when: the obvious answer involves more process or more tooling. Propose less.

4. Are Right, A Lot

Use data and good judgment. Seek diverse perspectives. Update views when proven wrong.

Shows up when: gut vs data — pick data, unless data is clearly incomplete.

5. Learn and Be Curious

Always be learning. Explore new tech and ideas.

Shows up when: asked how we handle an unfamiliar tool or domain. The answer is “I dig in and learn it.”

6. Hire and Develop the Best

Raise the bar with every hire. Coach others. Take feedback seriously.

Shows up when: asked about teammates’ growth, mentoring, or giving feedback.

7. Insist on the Highest Standards

Don’t accept “good enough.” Fix root causes, not symptoms.

Shows up when: we’re tempted to ship a known-imperfect thing. Push back or fix it.

8. Think Big

Bold direction. Communicate a vision that inspires.

Shows up when: asked to choose between a safe small win and an ambitious bet. Show we can do both.

9. Bias for Action

Speed matters. Many decisions are reversible (two-way doors).

Shows up when: paralysis-by-analysis scenarios — pick action with a rollback plan.

10. Frugality

Do more with less. Constraints breed invention.

Shows up when: asked about resource tradeoffs. Find the lean path.

11. Earn Trust

Listen well, speak candidly, treat others with respect.

Shows up when: dealing with disagreement. Disagree respectfully — don’t ghost.

12. Dive Deep

Stay connected to the details. Audit data yourself. Nothing’s beneath us.

Shows up when: we’re tempted to trust a summary. Go look at the raw numbers.

13. Have Backbone; Disagree and Commit

Challenge decisions we disagree with. Once decided, commit fully.

Shows up when: asked about pushing back. Yes, we push back — but once the call is made, we commit.

14. Deliver Results

Focus on the key inputs. Deliver on time, with quality. Rise to the occasion.

Shows up when: asked about prioritization. Outcomes beat activity.

15. Strive to be Earth’s Best Employer

Make work safer, more diverse, more meaningful.

Shows up when: asked about culture, inclusion, wellbeing.

16. Success and Scale Bring Broad Responsibility

Be humble. Think about second-order effects on customers, partners, and the planet.

Shows up when: asked about ethics, sustainability, or impact at scale.

F. Day-of Tactics (whole assessment)

Before we click Start

• Take the Demo Test first. The invite email has the HackerRank demo link — same IDE, same format. 15–20 minutes there is worth far more than 15 extra minutes of LeetCode.
• Set aside 2.5 hours in a quiet location. Even though the actual test is ~2 hours, give ourselves buffer.
• Latest Chrome or Edge. Close other tabs. Test the internet connection.
• Single monitor only. Disconnect external monitors before starting the coding challenge.
• Bathroom break, water bottle, phone on silent. The coding-challenge timer cannot be paused.
• Resume + a paper notepad nearby. No external notes allowed inside the IDE, but having our resume open in a separate window helps for behavioral context recall.
• Start at peak alertness. Mid-morning, after coffee, before lunch. Not 11 PM.

During the assessment

• Read every section’s instructions in full before clicking into that section.
• Don’t refresh the browser. Don’t switch tabs unnecessarily — most OA platforms flag tab-switching as a signal.
• No personal IDE, no Stack Overflow, no notes. Everything is in the HackerRank platform.
• 30 seconds of deep breaths before each section. Beats panic-clicking.
• If a real technical issue happens, log out and log back in using the email link. Don’t refresh repeatedly. If it persists, contact the recruiter.

Section-specific reminders

• Problem 1 (45 min): brute force first, edge cases, partial credit counts.
• Problem 2 (50 min): read the README, run tests first, use AI as a pair-programmer not an oracle, don’t refactor.
• Work Simulation (15 min): customer-first, data-driven, action-oriented but not reckless, peer-resolution before escalation.
• Work Style Surveys (10 min): consistency over extremes, lean Customer Obsession + Deliver Results on ties.

G. Post-OA Notes (fill this in tomorrow)

After the OA, come back and fill this in. Every future Gyaan OA note for any company benefits from the real data we capture here.

What actually appeared

• Problem 1 (traditional coding): (fill in the problem pattern and its story)
• Problem 2 (code repo + AI): (repo structure, the failing test, the AI assistant UX, anything surprising)
• Work Simulation: (was it MCQ-style as expected, or longer/different? scenario themes)
• Work Style Surveys: (any surprising question types, anything inconsistent with the LP framing)

What I’d do differently

• (fill in after sitting the test)

New patterns to add to the Tier 1 list

• (if Amazon asked something we didn’t prep, add it here so the next attempt — ours or someone else’s — is sharper)

H. Template Prompt — Paste in a New Claude Session After the OA

A fresh Claude Code session won’t remember our prep conversation. To get section G updated after the OA, open Claude Code inside the gyaan/ directory and paste the prompt below. Fill in the bracketed placeholders with what we remember — leave any field blank or write “don’t remember” if needed.

A short context entry in MEMORY.md already points future sessions to this collection, so the new session will know what section G is without re-explaining.

Full template (recommended)

I just finished the Amazon SDE OA. Please update my Amazon prep note with what
actually appeared, so future attempts (mine or anyone reading) are sharper.

The note lives at: src/content/oa-practice/01-amazon.md
The section to update is: G. Post-OA Notes

Here's what I want you to do:
1. Read the existing note end-to-end first, especially section G.
2. Update section G with the data I give below — rewrite it as proper prose
   (not just dumping my bullets). Keep the same subsection structure:
   "What actually appeared", "What I'd do differently", "New patterns to add".
3. If anything I report contradicts the format described in sections A–F
   (timing, section count, AI assistant behavior, etc.), update those sections
   too — the official email is no longer the freshest source of truth, my
   real experience is.
4. If Amazon asked a DSA pattern that wasn't in Tier 1/2 of section B1, add it
   to Tier 1 and explain why.
5. Run `npm run build` from the gyaan/ directory at the end to confirm
   nothing breaks.

Here's what happened today:

==================== PROBLEM 1 (Traditional Coding, ~45 min) ====================
Pattern/story: [e.g., "A delivery routing problem — given an array of package weights and a max truck capacity, return the minimum number of trips"]
Pattern category: [e.g., greedy + sorting, sliding window, DP, etc.]
Test cases I passed: [e.g., 14/15]
What was hard: [time pressure / pattern recognition / edge cases / language choice / something else]
Language I used: [JS Node / Python 3 / etc.]

==================== PROBLEM 2 (Code Repo + AI Assistant, ~50 min) ====================
Repo structure: [how many files, what the codebase was about — e.g., "a small REST API with controllers and a service layer"]
The task: [what I had to complete/fix — e.g., "complete the cancelOrder() method so it handles already-cancelled orders correctly"]
What the AI assistant was like: [helpful / clunky / locked to certain queries / anything surprising]
How I used the AI: [for explanations / for code / barely used it / etc.]
Test cases I passed: [e.g., 12/15]
Language I used (locked at start): [JS / Python / Java / etc.]
What was hard: [understanding the repo / debugging / AI gave wrong code / time / etc.]

==================== WORK SIMULATION (~15 min) ====================
Was it actually 15 min and MCQ-style as expected? [yes / no — describe]
Themes of the scenarios: [e.g., "code review priorities, on-call tradeoffs, dealing with a slow teammate"]
Anything that felt like a trap: [e.g., "two options both sounded right but one subtly violated Earn Trust"]

==================== WORK STYLE SURVEYS (~10 min, 2 surveys) ====================
Survey 1 (engineering): [any surprising or memorable question types]
Survey 2 (general work): [any surprising or memorable question types]
Was it actually 2 surveys, or just one? [confirm format]

==================== OVERALL ====================
Total time I actually spent: [e.g., "1h 50min"]
What I'd do differently if I sat this again: [free-form]
What I wish I'd prepped harder for: [free-form — this drives Tier 1 updates]
Surprises / gotchas not in the current note: [anything else worth capturing]
==================== END ====================

After updating section G (and any other affected sections), give me a 3-line
summary of what changed in the note, and confirm the build passed.

Minimal version (if short on time)

I finished the Amazon OA. Update section G of src/content/oa-practice/01-amazon.md
with this experience: [paste raw notes here]. Read MEMORY.md first for context.