Amazon SDE Interview Questions: What Each Level Asks

Amazon SDE interview questions focus on coding, system design, and Leadership Principles, but the expected depth and the loop shape change by level: interns get shorter coding-focused rounds and behavioural checks; SDE1 adds fuller algorithmic problems and light design; SDE2 includes multiple coding rounds plus at least one system-design conversation and a stronger Leadership Principles bar.

Key Takeaways

• Succeeding at Amazon SDE interviews means matching question scope to level: short, crisp answers for interns; tight algorithmic solutions for SDE1; deeper design and ownership signals for SDE2.

• The loop mixes coding, design, and Leadership Principles; interviewers are assigned technical and LP areas and score both in each interview 1.

• Practice answering while you code, prepare 6-8 strong STAR stories tied to Leadership Principles, and run at least two full mock loops in the two weeks before your interviews.

Credit: Photo by congerdesign on Pixabay

How the Amazon SDE loop is shaped, end to end

The Amazon loop blends an online assessment, recruiter screen, and a multi-interview loop where interviewers test technical skill and Leadership Principles in the same meeting. Amazon documents that, for SDE II, candidates complete an online assessment, then a recruiter arranges a loop typically consisting of four 55-minute interviews covering technical competencies and non-technical competencies tied to Leadership Principles 1.

That OA for SDE II is split into three sections: Coding, System Design, and Work Styles, with the coding challenge timed at 90 minutes and the candidate typically given a seven-day window to complete it 2. Use those facts as the baseline: the OA filters first, then the loop evaluates depth, ownership, and communication under pressure 2.

How the loop differs by level

the same round name is not the same bar - interns face shorter, less ambiguous prompts; SDE1 faces medium-to-hard algorithmic problems; SDE2 faces harder algorithms plus at least one deep system-design conversation and a stronger emphasis on ownership and dive deep.

SDE Intern: scope, depth, and what passes

SDE Intern questions prioritise basic data structures, coding correctness, and clear communication rather than broad system ownership. Expect one or two coding tasks that check arrays, strings, hash maps, and simple trees, plus a brief behavioural or work-style check tied to basic Leadership Principles like Learn and Be Curious or Ownership. Interviewers are looking for correct, readable solutions and the ability to explain tradeoffs out loud.

Passing an intern loop is often about demonstrating a clear approach, avoiding unnecessary complexity, and communicating your thought process as you code. Use a short STAR story for one or two Leadership Principles, and show you can accept feedback and iterate on a solution under time pressure.

SDE1: scope, depth, and what passes

SDE1 questions raise the algorithmic bar: medium-to-hard LeetCode-style problems in arrays, trees, graphs, dynamic programming, and hash-based techniques. You should produce a correct solution, explain complexity, and optimise the implementation; partial credit for a correct approach with an efficient plan is possible, but polished code helps.

SDE1 interviews also probe role fit through Leadership Principles. Expect the interviewer to evaluate 2-3 Principles alongside the technical question. A strong SDE1 answer ties a short STAR story to concrete metrics or user impact and shows the ability to debug and iterate in the moment.

SDE2: scope, depth, and what passes

SDE2 elevates the design expectation: multiple solid coding rounds plus at least one full system-design discussion where you discuss scale, tradeoffs, APIs, and high-level components. Amazon explicitly notes that SDE II candidates should expect at least one question on software systems design and that interviews evaluate technical and non-technical competencies based on Leadership Principles 1.

To pass at SDE2, you must show systems thinking - how a service handles scale, failure modes, and operational concerns - and stronger ownership evidence in behavioural answers. Communicate where you made tradeoffs and how you measured success in prior work. If you see a design prompt, structure the conversation from requirements to API surface to storage and scaling considerations.

Credit: Photo by Malte Luk on Pexels

How coding rounds work - and how to talk while solving them

interviews test two things at once - your algorithmic solution and your ability to communicate a clear thought process under pressure. Start with a concise problem restatement and clarify constraints. Outline a brute-force approach, then a refined plan, and only then start coding. Verbalise loop invariants, edge cases, and complexity as you write. Interviewers expect spoken checkpoints every few minutes so they can follow your reasoning.

Specific steps to follow mid-problem: 1) restate the problem and confirm constraints, 2) propose an approach and its complexity, 3) write code in small, testable chunks, 4) run through 2-3 hand examples including edge cases, and 5) discuss optimisations or alternative approaches. Short parenthetical asides help: say the obvious checks aloud (null inputs, empty arrays, single-element edge cases) - it shows structured thinking rather than code luck.

System and component design by level

design expectations scale with level - interns see micro design or component-level questions, SDE1 sees modest HLD prompts, and SDE2 sees end-to-end system design that requires tradeoffs on storage, consistency, latency, and failure handling. Amazon warns SDE II candidates to expect at least one systems design question in the loop 1.

For an SDE2 design answer, begin with requirements, sketch core components, propose APIs, choose storage and caching strategies, discuss data flow, and call out bottlenecks and monitoring. Be explicit about scale assumptions and how you'd measure success. For SDE1, keep the design compact: a clear component diagram and one or two scaling notes usually suffice. For interns, focus on how a single component or API would behave and the simple tradeoffs involved.

Leadership Principles and where they appear in the loop

Leadership Principles are evaluated alongside technical skill - Amazon assigns interviewers to assess specific Principles in each interview, and interviewers score both technical and non-technical competencies during the same meeting 1.

Practically, expect LP questions interwoven into coding or design rounds. Interviewers will often pause a technical conversation to ask about a related past experience. Prepare 6-8 STAR stories mapped to Principles like Ownership, Dive Deep, Bias for Action, and Customer Obsession. Strong answers name the metric or outcome you influenced, the concrete action you took, and what changed because of it. Weak answers are vignettes without a measurable result or without a specific personal contribution.

Where the Bar Raiser fits and what they look for

the Bar Raiser exists to ensure hire quality and consistent standards across teams; they participate in the loop as an independent interviewer whose score carries extra weight. Public Amazon guidance explains the loop structure and the mix of competencies interviewers evaluate, though precise Bar Raiser placement varies by team 1.

Do not assume which slot the Bar Raiser will take - teams differ. Instead, treat every interview as if a Bar Raiser could be present: be structured, explicit about impact, and tie answers back to measurable outcomes and long-term thinking. If a Bar Raiser asks a behavioural follow-up, lean into evidence and depth rather than summaries.

Strong and weak versions of the same answer

the difference between strong and weak answers is specificity, impact, and clarity. A weak technical answer describes the algorithm at a high level and produces ambiguous complexity claims. A strong one shows tested edge cases, a working complexity analysis, and a one-minute summary of tradeoffs. For behavioural questions, a weak answer lists tasks; a strong answer gives a personal action, a metric, and a learning point.

Example: for Ownership. Weak: "I helped with a project to fix a bug." Strong: "I noticed a recurring outage affecting a noticeable share of requests, isolated it to a caching bug, deployed a fix that reduced failures, and added an alert rule to prevent regression."

Question Bank: Amazon SDE Interview Questions

below are 22 targeted questions grouped by intent with concise model answers you can adapt to your level. Use the intern, SDE1, and SDE2 sections above to calibrate depth before you answer.

1. Describe how you would remove duplicates from a large stream of user IDs in near-real time.

Use a probabilistic deduplication approach like a Bloom filter for memory efficiency, combined with periodic checkpointing or an LRU cache to bound memory. If false positives are unacceptable, keep a persisted hash set or use sharded processing where each shard owns a range of IDs and maintains exact state.

2. Given a binary tree, return the maximum path sum between any two nodes.

Use a post-order DFS that returns the maximum single-path sum from a node to its descendants; compute the local max through the node as leftMax + node.val + rightMax and update a global best. Handle negative values by clamping downward paths to zero when appropriate and explain complexity O(n) time and O(h) recursion stack space.

3. How would you design a URL shortening service?

Start with requirements: read vs write ratio, desired availability, and TTLs. Sketch components: API layer, service to generate short keys (base62), storage (partitioned DB), cache for hot entries, and a redirection service. Discuss collision handling, key generation (hash vs counter), analytics tracking, and how you would scale writes with sharding and read caching.

4. Walk me through how you would shard a write-heavy table.

Choose a shard key that spreads writes (not a monotonically increasing field). Use consistent hashing or range partitioning with hot-shard mitigation strategies, add a write buffer or queue to smooth spikes, and replicate shards for reads. Monitor per-shard latency and rebalance shards when load skews appear.

5. Implement LRU cache operations get and put.

Use a hash map for O(1) lookup and a doubly linked list to maintain order of use. On get, move node to head; on put, insert at head and evict tail if capacity exceeded. Explain concurrency considerations if used in a multithreaded context.

6. Tell me about a time you disagreed with a technical decision and how you handled it.

Use STAR: state the context, your action (data-backed experiment, prototype, or a benchmark), the concrete result, and the learning. Emphasise collaboration and how the final decision improved the product or prompted a mitigation plan if the original choice persisted.

7. Given an array of integers and a target sum, find all unique quadruplets that sum to the target.

Sort the array, then use k-sum reduction: fix two indices and apply two-pointer search for the remaining pair, skipping duplicates to ensure uniqueness. Explain time complexity O(n^3) worst-case and discuss optimisations and edge-cases like overflow or empty input.

8. How do you ensure data consistency across microservices that can fail independently?

Discuss idempotent operations, retries with backoff, distributed transactions tradeoffs, and saga patterns for long-running workflows. Emphasise observable compensating actions and how to design for eventual consistency with clear customer-facing guarantees.

9. Design an autocomplete system for a search bar.

Outline a prefix trie or a reverse-index approach for lookup, augment with frequency counts or recency signals, and discuss caching hot prefixes. For scale, partition the index, use approximate suggestions with ranking models, and consider latency budgets when deciding where to compute suggestions (edge vs service).

10. How would you detect and handle a memory leak in production?

Describe monitoring metrics (heap growth, GC pause times), use sampling profilers or heap dumps to localise leaking allocations, reproduce in a staging environment, and deploy a fix with feature flags or canary rollout while adding alerts to catch regressions.

11. Implement a thread-safe singleton in your language of choice.

Explain the language-specific pattern: use double-checked locking with a volatile variable in Java, or a static-initialiser approach where the runtime guarantees thread-safe init. Mention test strategies and how dependency injection can reduce the need for singletons.

12. Describe a time you simplified a complex codebase or system.

Use STAR to describe the specific complexity (fragile deploys, duplicated logic), what you removed or refactored, the measurable improvement (reduced incidents, faster builds), and how you maintained behaviour through good tests or gradual rollouts.

13. Explain CAP theorem with an example when you would choose availability over consistency.

Define CAP: Consistency, Availability, Partition tolerance. Give a concrete example like a global cache service where availability under partition is preferred for user-facing reads, with eventual consistency and background reconciliation for correctness-sensitive writes.

14. Given two servers that must agree on a leader, outline a simple leader election approach.

Mention approaches: use a consensus algorithm like Raft for multiple nodes, or use an external coordinator like ZooKeeper/etcd. For a simple two-node setup, explain using a third-party lock service or a lease with failure detection to avoid split-brain scenarios.

15. How do you prioritise technical debt against feature work?

Discuss quantifying debt impact via incident frequency and customer impact, assigning remediation stories with acceptance criteria, and using small, incremental fixes during feature work. Tie the answer to a Leadership Principle like Dive Deep and Ownership.

16. Intern question: Reverse a linked list in place.

Walk through iterative pointer reversal using prev, curr, next pointers. Discuss base cases (empty or single-node lists) and mention time O(n) and space O(1). Cite a short code sketch if asked.

17. Scenario: A payment job is intermittently failing at scale. How do you triage it?

Check error logs and metrics, reproduce failure under controlled load, identify bottlenecks (DB locks, external service latency), add circuit breakers or batching as mitigation, and roll fixes in canary before full deployment. Communicate the rollback plan to stakeholders.

18. How would you design a feature flag system?

Define APIs for evaluation, store flags centrally with SDKs for clients, ensure low-latency evaluation via local caches, and plan for audits and rollout controls. Discuss data model for targeting and how to expire or cleanup stale flags.

19. Explain a time you recovered from a production incident.

Give a concise timeline: detection, mitigation steps you executed, root cause analysis findings, and follow-up prevention work. Focus on your specific actions and the impact on customers or metrics.

20. How would you test an API that streams real-time events to thousands of clients?

Cover load testing with simulated clients, validate backpressure and rate-limiting behaviour, check resource usage, and test failover scenarios. Also describe monitoring for lag, dropped messages, and consumer-side recovery strategies.

21. SDE2 design question: Architect a global leaderboard service with low-latency reads and frequent writes.

Partition by leaderboard key, use in-memory sorted data stores for hot partitions, maintain persistent backing stores and asynchronous aggregation for long-term storage. Discuss tradeoffs between read and write latency, consistency models, and how to handle large fanouts and ranking recalculation.

22. What questions do you have for me about the role or team?

Ask about the team's current technical priorities, how success is measured for this role, the last technical debt the team paid down, and what the onboarding path looks like. These show curiosity and help you evaluate fit.

How to use this bank in the two weeks before your loop

structure the final two weeks around focused simulation and review - practise coding under time constraints, run design whiteboards, and rehearse STAR stories mapped to Leadership Principles. The goal is not new theory but fluency under pressure.

• Week 2: Build a baseline - refresh core algorithms, solve 6-8 problems under timed conditions, and finalise 6-8 STAR stories tied to specific Principles.

• Week 1: Simulate - run two full mock loops with peers or mentors (one coding-heavy, one design-heavy), fix pacing issues, and iterate answers based on feedback.

• Final days: Light coding warm-ups, review your stories, sleep well, and prepare short clarifying questions to ask interviewers.

Run a timed mock interview that mirrors your target level to validate pacing and communication by practising a loop at /?module=practice.

Questions you should ask interviewers

ask questions that clarify expectations and show product thinking. Good examples: "What is a recent area the team is trying to improve technically?", "How do you measure success for this service?", and "What technical tradeoffs are acceptable on this team?" The aim is to learn what the interviewer values and to align your follow-ups to those signals.

Frequently Asked Questions

How many rounds will I have?

Amazon publishes role-level guidance but not a universal round count; SDE II guidance describes a loop of multiple 55-minute interviews following the OA, though exact counts vary by team and role 1.

What does the Online Assessment include?

The SDE II Online Assessment is split into Coding, System Design, and Work Styles; the coding section includes a timed 90-minute challenge, and candidates typically have seven days to complete the OA after it is sent 2.

Where to go next: run practice that mirrors the loop

Most candidates improve fastest when they practise a realistic loop and get feedback on pacing and structure. Run a mock interview that mirrors the level you are applying to and rehearses both coding and Leadership Principles in the same session at /?module=practice.

What most candidates get wrong and how to fix it

Most candidates treat technical skill and behavioural answers as separate rehearsals; at Amazon they are evaluated together, and that is where candidates lose points. The concrete fix is simple: practise combined rounds where you code and then deliver a concise STAR answer tied to the same theme, and run at least two full mock loops under timed conditions. It is not glamorous. It is effective.

If you want a focused next step, run a mock SDE loop for your target level to test pacing, LP answers, and design clarity at /?module=practice. It will feel slightly uncomfortable the first time. That is the point.