Page Referrer Reachability
Reported by candidates from Amazon's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Amazon reportedly served this one in September 2026, and the 2 * 10^5 records cap is the whole story. It looks like a string parsing task, but it's directed graph reachability in disguise. Each [url, referrer] row is an edge from referrer to url, and you answer one query: can start reach target. If you try rescanning the records for every hop, you'll time out. Build an adjacency map once, then traverse. If you blank on the setup during the live assessment, StealthCoder runs invisibly on your desktop as a safety net, but the pattern is simple enough to lock in tonight.
The problem
You are given a list of web traffic records. Each record is represented as a two-element string array [url, referrer]: url is the page that a visitor reached. referrer is the page the visitor came from. An empty string represents a direct arrival with no referrer. Every record whose referrer is non-empty creates a directed movement from referrer to url. The reverse movement is not implied. You are also given query = [start, target]. Return true if target is reachable from start by following zero or more recorded movements. Therefore, return true when start and target are the same page. Otherwise, return false. Direct-arrival records do not create additional movements. Function canReachPage(records: String[][], query: String[]) → boolean Examples Example 1 records = [["/catalog","/home"],["/item/7","/catalog"],["/cart","/item/7"]] query = ["/home","/cart"] return = true The records create the directed path /home to /catalog to /item/7 to /cart. Example 2 records = [["/pricing","/home"],["/signup","/pricing"]] query = ["/pricing","/home"] return = false The record creates a movement from /home to /pricing, but not the reverse movement requested by the query. Example 3 records = [["/landing",""],["/account","/landing"]] query = ["/account","/account"] return = true A page is reachable from itself without following an edge. Constraints 1 <= records.length <= 2 * 10^5. Every row in records contains exactly two strings in the order [url, referrer]. Every url, start, and target is non-empty and has length at most 100. Every referrer is either an empty string or a page URL of length at most 100. query.length == 2. Page URLs are compared exactly and are case-sensitive. The records may contain repeated movements and directed cycles.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is direction. The record is [url, referrer], so the edge goes referrer to url, not the other way. Flip it and Example 2 breaks. Build a hash map from referrer to a list of urls, skip rows with an empty referrer, then run BFS or iterative DFS from start with a visited set. Check start equals target first and return true immediately. Visited matters because the records can contain repeated movements and directed cycles, and without it you loop forever. Prefer iterative traversal over recursion, since a chain of 2 * 10^5 pages can blow the call stack in some languages. Total work is O(n) for building plus O(n) for traversal. Pitfalls: reversing edges, adding edges for empty referrers, and forgetting case-sensitive exact matching. If the live OA rattles you, StealthCoder can hand you the clean BFS as a hedge.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Page Referrer Reachability cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Amazon's OA.
Amazon reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Page Referrer Reachability FAQ
How hard is the Amazon Page Referrer Reachability question really?+
Easy to medium. It's a single-source reachability check on a directed graph. The hard part is noticing it's a graph and getting the edge direction right. Once you build the adjacency map, a standard BFS finishes it in about fifteen lines.
What's the trick to this problem?+
Treat each record as an edge from referrer to url, ignore empty referrers, and traverse from start with a visited set. Return true right away if start equals target. The visited set handles cycles and repeated records, which the constraints explicitly allow.
Why does brute force fail here?+
With up to 2 * 10^5 records, scanning the full list at every hop makes the work quadratic in the worst case. Build the adjacency map once in O(n), then each page is visited at most once. That keeps the whole solution linear.
BFS or DFS, which should I use?+
Either works. BFS with a queue or DFS with an explicit stack both run in O(n). Avoid recursive DFS on long chains because deep paths can overflow the stack. Pick whichever you can write without bugs under pressure.
How do I prepare for this in 48 hours?+
Write graph reachability from scratch twice: build the map from edge pairs, then BFS with visited. Test the three examples, plus a cycle and the start equals target case. Also practice reading the input order carefully, since [url, referrer] is easy to flip.