Most "FAANG prep" advice treats Amazon, Google, and Microsoft as one blob. That's a mistake — and for Amazon specifically, it's an expensive one, because Amazon is the most pattern-predictable of the big-tech loops and the most generous to anyone who prepares for it rather than for an average of three companies. If you have an Amazon SDE-1 process lined up, this is the deep version: its real DSA lean, the parts of the Online Assessment that nothing else tests, and the behavioural weight that sinks more freshers than any graph problem.

Amazon doesn't reward exotic algorithms. It rewards clean grid/graph/tree code, the ability to debug unfamiliar code under a clock, and STAR stories that map to its Leadership Principles. Prepare those three and you've prepared for Amazon.

The Amazon SDE-1 loop, end to end

Before the patterns, know the shape of what you're walking into. For freshers (campus and off-campus), an Amazon SDE-1 process usually runs roughly like this — the exact stages vary by year and geography, so treat this as directional, not a contract:

• Online Assessment (OA) — typically two coding problems, plus a code-debugging section and a work-style / behavioural survey. This is the first real filter and the one most candidates under-prepare.
• Interview loop — multiple rounds mixing DSA and behavioural questions. Even the "coding" rounds open or close with Leadership Principle questions.
• The bar-raiser — one interviewer in the loop is there to hold the hiring bar and weights Leadership Principles especially heavily. You usually won't know which one it is.

The thing to internalise: at Amazon, behavioural is not a formality bolted onto the coding. It's woven through the entire loop, including for SDE-1. We'll come back to this — it's where prepared candidates with mediocre DSA beat unprepared candidates with great DSA.

The DSA lean: grids, graphs, trees

Amazon's technical questions cluster, and the cluster is consistent enough to plan around. Problems are frequently dressed up in warehouse, delivery, package-routing, or org-chart stories — which is a tell, because those narratives almost always reduce to a grid or a graph. Drill these until you recognise the shape in under two minutes:

• Matrix / grid traversal — number-of-islands style flood fill, flood-from-the-edges, shortest path in a grid (BFS), "rotting oranges" multi-source BFS, surrounded regions. This is the single most Amazon-flavoured bucket. A 2D grid is a graph; treat it like one.
• Graphs — BFS/DFS, connected components, topological sort (course-schedule / build-order framing), and basic shortest-path. Topological sort shows up disproportionately because Amazon loves dependency and ordering stories.
• Trees — traversals (level-order especially), lowest common ancestor, diameter, path-sum variants, and "serialize / deserialize" at the harder end. Binary-tree recursion is foundational here.
• Heaps / top-K — "K closest points," "top K frequent," merge-K-lists. These pair naturally with Amazon's ranking and logistics framing.
• Arrays, strings, hash maps, two pointers, sliding window — the universal base. Every loop has at least one. You don't get to skip these by being good at graphs.

What's lighter at Amazon than people fear: heavy dynamic programming and exotic data structures. You'll see the occasional grid-DP (minimum path sum, unique paths) and easy/medium 1D DP, but the segment-tree / advanced-DP grind is lower ROI here than it would be for a hardcore competitive-programming round. Get grids and graphs to autopilot before you touch hard DP.

The OA debug section — the part nothing else tests

This is the most under-prepared piece of the whole process. Amazon's OA frequently includes a code-debugging / code-completion segment: you're handed broken or partial code and asked to fix it so it passes the tests — often under a tight per-question timer, sometimes in a language you don't primarily use.

This tests a genuinely different muscle from solving problems on a blank page. You have to read unfamiliar code fast, build a mental model of what it's supposed to do, and spot the off-by-one, the wrong boundary condition, the inverted comparison, the missing null check. Most candidates spend 100% of their prep writing code from scratch and 0% reading and fixing someone else's — then lose easy points here.

How to prepare for it specifically:

• Practise reading, not just writing. Pull solved problems and deliberately introduce a bug, then find it cold. Or read other people's submissions in the LeetCode discuss tab and predict where they'd break.
• Drill the classic bug families — loop bounds (< vs <=), off-by-one in array indexing, integer overflow, uninitialised accumulators, base-case mistakes in recursion, mutating a collection while iterating.
• Get comfortable in a second language's syntax enough to read it. The debug snippet may not be in your primary language.

The good news: it's learnable fast, and almost nobody trains for it, so a few focused hours is disproportionate edge.

Leadership Principles count — even for SDE-1

If you take one thing from this post, take this: Amazon weights its Leadership Principles heavily for freshers, not just senior hires. The work-style survey in the OA, the behavioural questions threaded through every interview round, and the bar-raiser all draw on the same 16-ish principles — Customer Obsession, Ownership, Dive Deep, Bias for Action, Deliver Results, Learn and Be Curious, and the rest.

Candidates lose Amazon offers here in a predictable way: they nail the coding, then give vague, un-structured behavioural answers and get dinged by the bar-raiser. Don't let your DSA prep crowd this out. Concretely:

• Prepare STAR stories — Situation, Task, Action, Result — from real projects, internships, hackathons, or coursework. Quantify the result wherever you honestly can.
• Map each story to 2–3 principles. One strong project can answer "tell me about a time you took ownership" and "a time you dove deep into a problem." Aim for a bank of 6–8 flexible stories.
• Lead with "I," not "we." Amazon wants your specific contribution, not the team's. Vague collective answers read as a red flag.
• Have a real failure story. "I have no weaknesses" fails Self-Criticism. Pick a genuine miss and what you changed afterward.

The Amazon prep map at a glance

Area	Priority	What to actually drill
Grids / matrix	Core	Flood fill, multi-source BFS, shortest path in grid
Graphs	Core	BFS/DFS, connected components, topological sort
Trees	Core	Traversals, LCA, diameter, path sums
Arrays / strings / hashing	Core	Two pointers, sliding window, frequency maps
Heaps / top-K	Relevant	K-closest, top-K-frequent, merge-K
Grid / easy DP	Relevant	Min path sum, unique paths, basic 1D DP
OA debug section	Don't skip	Reading + fixing broken code under a timer
Leadership Principles	Don't skip	6–8 STAR stories, mapped to principles, "I" not "we"
Hard DP / segment trees	Low	After everything above is solid

A realistic 4–6 week plan

This assumes you already have the universal base (arrays, strings, hashing) at a workable level. If you don't, build that first — see the foundation note below.

1. Weeks 1–2 — graphs and grids to reflex. This is your highest-yield investment for Amazon. Drill flood fill, multi-source BFS, connected components, and topological sort until you can name the approach before reading the full prompt. Mix in tree traversals.
2. Week 3 — trees, heaps, top-K. LCA, diameter, level-order, then the heap/top-K family. Add easy grid-DP at the end of the week.
3. Week 4 — the OA-specific drills. Two or three timed mock OAs. Crucially, spend dedicated sessions on the debug format — introduce bugs into solved problems and hunt them cold. Run the work-style survey expectations through your head honestly.
4. Weeks 5–6 — Leadership Principles + mocks. Write and rehearse your STAR bank out loud. Run mixed mock loops where one problem is followed immediately by "tell me about a time you…". Simulate the real interleaving.

If your timeline is tighter than this, compress weeks 1–3 and protect weeks 4–6 — the OA debug practice and the STAR stories are where the marginal hour pays off most for Amazon specifically, because nobody else prepares them.

The mistakes that cost Amazon offers

• Grinding hard DP while weak at graphs. You've inverted Amazon's lean. Graphs and grids first, always.
• Zero debug-format practice. You can write code but can't read-and-fix it fast, and you bleed easy OA points.
• Treating behavioural as filler. The bar-raiser is real. Vague "we" answers fail people with strong code.
• Silent solving. Even at Amazon, narrate your approach, edge cases, and complexity. A clear brute-force-to-optimal beats a silent jump to the answer.

Where this fits in the bigger picture

If you're comparing Amazon against the other big-tech loops — Google's interval/greedy/communication lean, Microsoft's fundamentals-first style — read the Google, Amazon & Microsoft question breakdown for the side-by-side. To anchor on the universal frequency ranking before you specialise, the most important DSA topics for interviews covers the shared 90%. And the DSA patterns cheat sheet is the fastest way to drill the BFS/DFS and grid patterns Amazon over-weights.

The whole problem this post describes — "drill the patterns this company over-indexes on, not a generic 150" — is exactly what SUITS automates. Pick your target and it reorders the curated 370 problems (Apna College, Love Babbar 450, Striver A2Z) so grids, graphs, and trees float to the top of an Amazon-bound queue instead of being buried at step 14 — then tracks your progress and runs AI skill-analysis on the gaps you keep slipping on. For the role-level version of the same logic, see the DSA roadmap by role.