Amazon Software Engineer Interview Prep Guide

Focus most on Amazon LP STAR stories, core coding patterns, DP, graph reachability, heaps/windows, and distributed design because your self-ratings are 3/5 and there are no solved-question signals yet. Merely review GenAI verification, OOD/cache variants, and SQL/Linux since you did not mark any concept shaky/new and missing concept ratings default to solid. The Amazon-specific emphasis is Leadership Principles probing, scale/operational-readiness design, and Online Assessment-style algorithm speed. With 1-2 weeks, plan concentrated daily blocks: roughly 60% coding, 25% behavioral/system design, and 15% quick refreshers.

Technical Screen — 41 min

Behavioral & Leadership

• Leadership Principles STAR Stories (Focus) — covered in depth under Onsite below.

Coding & Algorithms

• Arrays, Strings, Hashing, And Two Pointers (Focus) — covered in depth under Online Assessment below.

• Graphs, Grids, And Reachability (Focus) — covered in depth under Online Assessment below.

• Trees, Recursion, And Binary Search Trees — covered in depth under Other below.

System Design

Focus area — At 7 years, Amazon may expect design depth; system design rating is 3/5 with only viewing signals, no practiced output.

What's being tested

These designs test whether you can decompose a distributed system into clear APIs, state ownership, data paths, and failure boundaries rather than jumping directly to technologies. Across configuration delivery, caching, input reconstruction, log analytics, and ad serving, the interviewer probes partitioning, ordering, consistency, durability, latency, and recovery under realistic failure modes. Amazon cares because Software Engineers must build services that remain correct and operable when machines fail, traffic spikes, messages are duplicated, and requirements conflict. A strong answer makes guarantees explicit, quantifies assumptions, and explains tradeoffs instead of claiming “exactly once” or “strong consistency” without defining scope.

Core knowledge

• Requirement clarification should establish read/write QPS, object sizes, retention, latency targets, availability, durability, geographic scope, and acceptable staleness. Convert vague goals into measurable SLOs such as p99 < 100 ms, 99.99% availability, or recovery point objective (RPO) of zero.

• API contracts should define resource identity, version fields, pagination, timeouts, retries, authentication, and error semantics. Use an idempotency key for retried writes, and return a monotonic version or ETag so clients can perform conditional updates with If-Match.

• Partitioning distributes keys across nodes using consistent hashing or rendezvous hashing. Virtual nodes reduce imbalance, but rebalancing still requires bounded data movement, throttling, and a clear behavior for requests during ownership transitions.

• Replication improves availability but introduces consistency choices. Leader-based replication simplifies ordered writes; quorum replication uses $R + W > N$ for read/write intersection, while $R + W \leq N$ permits stale reads. State exactly which operations require a leader or quorum.

• Consistency is per operation and per data type, not a single system-wide label. Configuration versions and reconstructed input may require ordered, linearizable updates; cache reads may tolerate bounded staleness; log aggregation can usually be eventually consistent with correction for late events.

• Ordering needs a defined scope: per key, per client, per partition, or globally. A sequence number plus source identifier supports deduplication and gap detection; a global total order is expensive and often unnecessary. Clock timestamps alone do not establish causal order because clocks skew.

• Durability and recovery typically combine a replicated write-ahead log, durable snapshots, and replay. Define the acknowledgment point: acknowledging before replication risks data loss, while waiting for multiple replicas increases write latency. Recovery must address partial writes, duplicate replay, and corrupted or missing segments.

• Invalidation and cache correctness require a write policy: cache-aside, write-through, or write-behind. Cache-aside is simple but permits stale values and stampedes; use versioned values, delete-after-write, leases, request coalescing, and randomized TTL jitter to control races and synchronized expiry.

• Messaging semantics are normally at-least-once, so consumers must be idempotent. Durable queues or logs such as Kafka support replay and backpressure; dead-letter queues isolate poison messages. “Exactly once” generally means an end-to-end effect achieved with transactions, deduplication, or idempotent state transitions.

• Streaming and aggregation should separate ingestion from query serving. Partition logs by tenant or time, maintain indexes for exact attributes, and use time buckets for windows and histograms. Late events require a watermark or correction strategy; high-cardinality substring search may need inverted indexes rather than full scans.

• Hotspots and overload are first-class design concerns. A popular configuration key, cache key, advertiser, or log tenant can overload one partition; mitigate with replication, request hedging only when safe, admission control, batching, load shedding, and exponential backoff with jitter.

• Observability and operability should expose request rate, error rate, saturation, p50/p95/p99 latency, replication lag, cache hit ratio, queue depth, dropped events, and version gaps. Include health checks, canaries, alerts tied to SLOs, tracing correlation IDs, and a rollback or fail-forward procedure.

Worked example

For Design a configuration subscription service, I would first ask whether updates must be globally ordered, how many clients and subscriptions exist, the maximum propagation delay, and whether a disconnected client must receive every missed version. I would state an assumption such as per-configuration-key ordering, durable storage, at-least-once notifications, and eventual convergence within a defined SLO. I would organize the answer around the write API and version store, subscription/connection management, durable event distribution, and client catch-up plus observability. A writer would persist the new value and monotonically increasing version before publishing an event through a replicated log, while subscribers would acknowledge versions and fetch missing ranges after reconnecting. I would make delivery idempotent by including (key, version) and requiring clients to ignore versions at or below their applied version. The key tradeoff is whether to maintain long-lived connections for low latency or use polling for simpler scaling and firewall behavior. I would explicitly avoid promising global ordering if per-key ordering satisfies the requirement. If I had more time, I would detail multi-region conflict handling, authorization propagation, snapshot compaction, and a rolling schema-migration plan.

A second angle

For Design a Distributed In-Memory Cache: Partitioning, Failover and Invalidation, the dominant framing changes from durable event delivery to low-latency reads under bounded inconsistency. Start by separating cache ownership, replication, eviction, and database interaction, then define behavior when a node fails or a cached value races with a write. Consistent hashing and replica promotion address availability, while versioned cache entries and write-through or explicit invalidation address correctness. The interviewer may specifically test stampede prevention, hot-key replication, and whether failover can return stale data. A strong answer states that the database remains the source of truth and explains how recovery repopulates the cache without overwhelming it.

Common pitfalls

Analytical mistake: Saying “use a distributed cache” or “use Kafka” without defining the consistency and delivery guarantee is incomplete. State the invariant first—for example, “a client never applies version 7 after version 8”—then select mechanisms that enforce it.

Pitfall: Treating timestamps as a total order, or claiming quorum reads are always strongly consistent, ignores clock skew, leader changes, stale replicas, and the actual acknowledgment protocol.

Communication mistake: Jumping into node counts and schemas before clarifying scale makes a technically reasonable design appear unfocused. Lead with assumptions, draw the request and failure paths, and periodically tie each component back to a stated requirement.

Pitfall: Listing every possible feature—multi-region active-active, global ordering, exactly-once delivery—without prioritizing the baseline design signals poor scope control.

Depth mistake: Designing only the happy path misses what these systems are intended to test. Walk through duplicate messages, lost subscribers, partition movement, replica failure, cache/database races, backpressure, and recovery from durable state.

Pitfall: Saying “retry on failure” without timeouts, exponential backoff, jitter, idempotency, and a retry budget can turn a partial outage into a cascading failure.

Connections

The interviewer may pivot to CAP theorem, leader election, consistent hashing, backpressure, idempotent APIs, or multi-region replication. They may also ask for a focused implementation of an LRU cache, a bounded queue, a rate limiter, or a versioned subscription client.

Further reading

• Designing Data-Intensive Applications — Martin Kleppmann’s detailed treatment of replication, partitioning, consistency, logs, and stream processing.

• Amazon Dynamo — seminal discussion of quorum-style replication, consistent hashing, and availability-oriented design.

• The Tail at Scale — why p99 latency, hedging, and fanout behavior matter in distributed services.

Practice questions

Onsite — 29 min

Behavioral & Leadership

Focus area — Amazon interviews probe Leadership Principles deeply; you viewed behavioral content nine times but have no solved-practice signal yet.

What's being tested

“Demonstrate Bias for Action” tests whether you make sound engineering decisions under uncertainty instead of waiting for perfect information. The interviewer is looking for ownership, technical judgment, risk management, communication, and measurable results—not a story about simply working quickly. Amazon cares because Software Engineers routinely choose between shipping a reversible improvement, investigating longer, or escalating a potentially costly failure.

Core knowledge

• STAR—Situation, Task, Action, Result—keeps the story causal: establish the system context, define your personal responsibility, explain your technical decisions, and quantify the outcome rather than narrating every project event.

• Bias for Action means reducing avoidable delay while preserving safety. Distinguish reversible decisions, such as a feature-flagged code path, from irreversible ones, such as a schema migration or destructive data operation.

• Frame uncertainty explicitly: state known facts, assumptions, unknowns, and the smallest experiment or implementation that can resolve uncertainty. This demonstrates judgment without pretending the requirements or failure mode were obvious.

• Show blast-radius control through canaries, feature flags, staged rollout, request timeouts, circuit breakers, rate limits, and automated rollback. Explain which safeguards were appropriate for the affected dependency and traffic volume.

• Quantify engineering outcomes with metrics such as `p99` latency, error rate, throughput, availability, deployment frequency, recovery time, or infrastructure cost. Establish a baseline and compare the result against it.

• Explain observability as a decision tool: structured logs identify request-level behavior, metrics reveal aggregate regressions, and distributed traces expose cross-service latency or failure propagation.

• Demonstrate ownership by identifying what you personally changed: a code path, API contract, deployment process, test suite, alert, runbook, or design decision. “We fixed it” is weaker than explaining your specific contribution and reasoning.

• Include tradeoff analysis rather than claiming an obviously correct choice. For example, a synchronous dependency may preserve immediate consistency but increase tail latency; asynchronous processing improves resilience but introduces retries, duplication, and eventual consistency.

• Use idempotency when acting quickly in systems with retries. An idempotency key, deduplication record, or safely repeatable state transition prevents a timeout from causing duplicate writes or duplicate external actions.

• Discuss failure handling concretely: bounded retries with exponential backoff and jitter, dead-letter handling, timeouts shorter than the caller’s deadline, and clear rollback criteria are stronger than saying you would “monitor it.”

• Connect speed to operational readiness: tests, dashboards, alerts, deployment ownership, and a rollback procedure let you move quickly without transferring hidden risk to on-call engineers or customers.

• When escalating, bring a recommendation and evidence rather than only a problem. State the decision needed, alternatives considered, risk level, what you already tested, and the deadline after which delay becomes more expensive than action.

Worked example: Demonstrate Bias for Action

In the first 30 seconds, I would clarify whether the story concerns a production incident, a delivery deadline, or an ambiguous design decision, then state the scale, customer impact, my authority, and the success metric. I would frame the answer with four pillars: detect and scope the problem, choose the smallest safe action, communicate ownership and risk, and validate and institutionalize the result. For example, I might describe discovering elevated `p99` latency in a backend service shortly before a high-traffic event. I would explain how I confirmed the regression through dashboards and traces, isolated an expensive code path, and proposed a feature-flagged optimization rather than waiting for a complete architectural rewrite. The explicit tradeoff would be accepting a temporary reduction in functionality for a subset of requests to protect availability and tail latency. I would mention a canary deployment, rollback threshold, on-call notification, and post-deployment comparison against the baseline. The result should include concrete numbers, such as reducing `p99` from 900 ms to 350 ms while keeping the error rate below the agreed threshold. I would close by saying that, with more time, I would remove the temporary degradation, add regression coverage, and document the operational guardrails.

A second angle

The same principle applies when the pressure is not an incident but an ambiguous implementation request with an approaching deadline. Instead of coding against unverified assumptions, I would build a narrow vertical slice behind an interface, validate the contract with the dependent team, and preserve the option to replace the implementation. The important evidence is that I made progress while containing rework through tests, compatibility checks, and a clear decision deadline. I would still explain what I deliberately did not solve, why that scope was safe, and how the design could evolve without a breaking migration. This framing emphasizes delivery judgment and reversibility rather than emergency response.

Common pitfalls

Pitfall: Saying “I acted quickly” without explaining the technical risk, guardrails, or outcome. A stronger answer names the baseline, the decision threshold, the rollback mechanism, and the measured result.

A common analytical mistake is confusing activity with impact: “I worked overnight and changed five services” does not prove good judgment. Explain the smallest change that addressed the bottleneck, why broader changes were unnecessary, and how tests or production signals verified the result.

A communication mistake is presenting the story as a solo rescue while omitting affected teams, reviewers, or on-call owners. Show how you notified stakeholders, stated uncertainty, requested targeted help, and kept decision-makers informed without waiting for unanimous consensus.

A depth mistake is choosing a technically impressive story but staying at the architecture-diagram level. Be ready to explain the relevant timeout, retry, consistency, deployment, or data-structure decision and one failure mode that your design had to prevent.

Connections

An interviewer may pivot from this story to operational excellence, dive deep, Have Backbone; Disagree and Commit, incident response, safe deployment, API compatibility, or distributed-systems tradeoffs. They may also ask what you would do differently, so prepare one honest limitation and the engineering practice you added afterward.

Further reading

• Amazon Leadership Principles — the official wording behind Bias for Action, Ownership, and related behavioral expectations.

• Designing Data-Intensive Applications by Martin Kleppmann — useful depth on retries, consistency, fault tolerance, and tradeoffs in distributed systems.

• Release It! by Michael T. Nygard — practical patterns for timeouts, circuit breakers, bulkheads, and production-safe change.

Practice questions

Coding & Algorithms

• Arrays, Strings, Hashing, And Two Pointers (Focus) — covered in depth under Online Assessment below.

• Graphs, Grids, And Reachability (Focus) — covered in depth under Online Assessment below.

• Trees, Recursion, And Binary Search Trees — covered in depth under Other below.

Online Assessment — 24 min

Coding & Algorithms

Focus area — Core OA/screen pattern; coding self-rating is 3/5 and only one coding view/no solved signal suggests practice is needed.

What's being tested

These problems test hashing, two pointers, sliding-window reasoning, and careful string parsing over arrays and text. Strong solutions identify whether order, contiguity, duplicates, circular indexing, or exact token boundaries determine the appropriate O(n) or O(n log n) strategy.

Patterns & templates

• Two pointers on sorted arrays — move the left pointer upward or right pointer downward based on the sum; handle duplicates deliberately.

• Hash maps and sets — track frequencies, last-seen positions, or distinct characters for linear-time substring and pair-counting solutions.

• Contribution counting — count how many substrings include each character’s unique contribution instead of enumerating all O(n²) substrings.

• Prefix sums for circular distances — duplicate or modularize indices, then compute interval distance as prefix[r] - prefix[l].

• Monotonic boundary scans — find the first inversion from the left and right, expand around the unsorted region, then validate the repaired range.

• Finite-state parsing — recognize complete price tokens using character boundaries; avoid matching $12 inside $123 or unrelated text.

• Complexity discipline — prefer O(n) time and O(n) space; use sorting only when its O(n log n) cost simplifies correctness and duplicate handling.

Common pitfalls

Pitfall: Treating circular routes like linear arrays; compare clockwise and counterclockwise distances and normalize with modulo.

Pitfall: Counting distinct substring spellings rather than occurrences by position, or accidentally using 32-bit arithmetic for large totals.

Pitfall: Moving both two-pointer indices after every match without grouping duplicates, causing missed pairs or repeated output.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — High-frequency Amazon coding area; with 3/5 coding rating and no solved graph signal, prioritize BFS/DFS and reachability.

What's being tested

These problems test graph traversal, reachability, and choosing the right representation for directed, undirected, and grid graphs. You must distinguish BFS for unweighted shortest paths, DFS/Union-Find for connectivity, and state tracking for cycle detection, while stating time and space complexity clearly.

Patterns & templates

• BFS shortest path — use a queue and distance map for unweighted graphs; runs in O(V + E) time and returns minimum hop count.

• DFS reachability — recursively or iteratively explore neighbors with a visited set; avoid revisiting nodes, especially when graphs have cycles.

• Multi-source ancestor search — traverse parent links from each person, store all reachable ancestors, then intersect sets to test shared ancestry.

• Directed meeting node — compute distances from both starts independently, scan nodes reachable from both, minimize max(distA[i], distB[i]), then break ties by index.

• Grid traversal — model four-neighbor movement with direction vectors; mark cells visited immediately to prevent duplicate island counts.

• Cycle detection — undirected graphs need parent tracking or Union-Find; directed graphs need three-state DFS: unvisited, active, and completed.

• Obstacle handling — reject blocked start or destination, check bounds before indexing, and use BFS when every legal move has equal cost.

Common pitfalls

Pitfall: Marking a node visited only when dequeued can enqueue it repeatedly; mark it when discovered instead.

Pitfall: Treating directed edges as bidirectional changes reachability and can incorrectly identify paths, ancestors, or cycles.

Pitfall: Claiming O(V + E) without defining V and E; for a grid, state V = rows × columns and explain memory usage.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Other — 27 min

Coding & Algorithms

• Arrays, Strings, Hashing, And Two Pointers (Focus) — covered in depth under Online Assessment below.

• Graphs, Grids, And Reachability (Focus) — covered in depth under Online Assessment below.

Important for onsite, but not in OA and not flagged as shaky, so treat as a standard refresher.

What's being tested

These problems test recursive tree traversal, careful base-case design, and choosing the right aggregation for each node’s subtree. You must distinguish general binary-tree logic from BST ordering, then state correctness, complexity, and edge-case behavior clearly.

Patterns & templates

• Depth-first recursion — return subtree height or best contribution; define null explicitly, typically O(n) time and O(h) call-stack space.

• N-ary tree height — compute 1 + max(child heights); initialize the maximum correctly and clarify whether depth counts nodes or edges.

• Postorder dynamic programming — combine left result, node value, and right result after recursive calls; useful for height balance and maximum path sum.

• BST LCA — compare both targets with the current value; move left when both are smaller, right when both are larger, otherwise current node is the split point.

• Catalan recurrence — distinct BST shapes satisfy $C_n=\sum_{i=1}^{n} C_{i-1}C_{n-i}$; use bottom-up DP and 64-bit integers for n ≤ 19.

• Maximum path sum — return the best downward gain while separately tracking a path that bends through the node; clamp negative child gains to zero.

• Level-order encoding — map array indices consistently, validate missing children, and avoid assuming every position represents an existing node in sparse representations.

Common pitfalls

Pitfall: Confusing node depth with edge depth, or returning only root-to-leaf paths when the maximum path may start and end anywhere.

Pitfall: Claiming O(log n) for BST operations without stating the tree is balanced; an unbalanced BST can degrade to O(n).

Pitfall: Forgetting null, single-node, duplicate-key, negative-value, and “target not present” behavior when explaining correctness.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions