← Amazon Interview Insights

Amazon·Software Engineer·Onsite - Coding / Algorithms·Intermediate

IntermediatePrefer not to say
May 2026

Summary

Amazon SWE coding round with two algorithm problems back to back. Both were graph/set problems dressed up in product clothing, which felt very Amazon. Nothing behavioral, just code and complexity analysis.

Questions Asked (2)

Q1

Given a list of users (each with friends and purchases), write a function that returns product names purchased by at least one friend of a target user but never purchased by the target user themselves. Walk through your algorithm and give time/space complexity.

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

Seemed straightforward at first.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data model and edge cases (e.g., target user not found, no friends, duplicate purchases). Then outline an algorithm using sets: collect the target user's purchased products, gather all products purchased by their friends, and return the set difference. Finally, analyze time and space complexity, and discuss potential optimizations or trade-offs.

Pro tip: Explicitly state your assumptions about the input format and constraints (e.g., number of users, products, friendships) before diving into the solution—this shows you think about scalability and real-world data, which Amazon values.

1. Clarify requirements and edge cases

Ask questions to confirm the data structure (e.g., how users, friends, and purchases are represented) and handle edge cases like missing target user, no friends, or empty purchase lists.

2. Design the algorithm

Propose using sets: build a set of the target user's purchased products, then iterate through each friend to collect their purchased products into another set. The result is the set difference (friends' products minus target's products).

3. Walk through an example

Trace the algorithm with a small concrete example to verify correctness and demonstrate your thought process.

4. Analyze complexity

State time complexity: O(F * P) where F is number of friends and P is average purchases per friend, or O(total purchases among friends) if using hash sets for O(1) lookups. Space complexity: O(P_target + P_friends) for the sets.

5. Discuss optimizations and trade-offs

Mention potential improvements like early termination if the target user has no friends, or using a single pass with a hash map if the data is large. Discuss trade-offs between time and space.

Key Points to Mention

  • Use of hash sets for O(1) average-time membership checks and deduplication.
  • Handling edge cases: target user not in list, no friends, friends with no purchases, duplicate product purchases.
  • Time complexity: O(total number of purchases among friends) assuming set operations are O(1).
  • Space complexity: O(number of unique products purchased by target and friends).
  • Potential optimization: if the target user has many friends, process friends in parallel or use a distributed approach for large-scale data.
  • Clarify whether the output should be sorted or if order doesn't matter.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

You have a table of navigation events with source and destination URLs. Build an in-memory graph from these records and implement a function to determine if url2 is reachable from url1. Include complexity analysis in terms of distinct URLs and edges.

Algorithms & Data StructuresSystem Design
Author's notes

Reachability in a directed graph, basically BFS or DFS from url1.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the problem: we need to build an in-memory graph from navigation events (source and destination URLs) and determine reachability from url1 to url2. Then, outline the graph representation (adjacency list) and the traversal algorithm (BFS or DFS), followed by complexity analysis in terms of distinct URLs (V) and edges (E).

Pro tip: Mention that BFS is preferred for reachability because it finds the shortest path in terms of hops and can early-exit when the target is found, which is efficient for large graphs. Also, discuss handling of duplicate edges and self-loops to avoid unnecessary work.

1. Clarify requirements and assumptions

Confirm that the graph is directed (since navigation has a source and destination) and that we need a boolean reachability check. Ask about constraints like graph size, memory limits, and whether the graph is static or dynamic.

2. Design graph representation

Use an adjacency list (hash map from URL to list of neighboring URLs) to efficiently store the graph. This handles sparse graphs well and allows O(1) average lookup for neighbors.

3. Implement reachability algorithm

Choose BFS or DFS to traverse from url1. BFS is often better for reachability due to early exit and shortest path guarantee. Use a visited set to avoid cycles and redundant work.

4. Analyze complexity

Time complexity: O(V + E) for traversal, where V is distinct URLs and E is edges. Space complexity: O(V + E) for the graph and O(V) for visited set and queue/stack.

5. Discuss edge cases and optimizations

Handle cases like url1 == url2, url1 or url2 not in graph, disconnected components, and duplicate edges. Mention possible optimizations like bidirectional BFS for large graphs.

Key Points to Mention

  • Graph representation: adjacency list using hash map for O(1) average neighbor lookup.
  • Traversal algorithm: BFS or DFS with visited set to avoid cycles; BFS for shortest path and early exit.
  • Complexity: O(V + E) time and O(V + E) space, where V = distinct URLs, E = navigation events (edges).
  • Edge cases: self-loops, duplicate edges, missing URLs, and url1 == url2.
  • Optimization: bidirectional BFS can reduce search space for large graphs.
  • Scalability: discuss memory usage and potential for distributed graph processing if data is huge.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.