Evaluate Division
Reported by candidates from Amazon's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Amazon OA from September 2026 hands you Evaluate Division, and the version going around is the scaled-up one. Up to 200000 equations, up to 200000 queries, repeated pairs. The classic graph search per query looks fine on the samples and then dies on the big tests. Variables are strings, ratios are doubles, and a variable that never appeared is undefined even against itself. That last rule is where people lose points. If you blank mid-assessment, StealthCoder runs invisibly on your desktop and gives you the weighted union-find outline in real time.
The problem
You are given variable pairs equations and positive real numbers values. For every index i, equations[i] = [a, b] and values[i] mean a / b = values[i]. For each pair in queries, return the requested quotient. Return -1.0 when it cannot be determined. The equations are valid and mutually consistent, and a variable absent from all equations is undefined even when queried against itself. The query stream can be very large and can repeat the same ordered pairs. Reuse previously resolved relationships or preprocess component weights so repeated calls do not traverse the full graph again. Function calcEquation(equations: String[][], values: double[], queries: String[][]) → double[] Examples Example 1 equations = [["a","b"],["b","c"]] values = [2.0,3.0] queries = [["a","c"],["b","a"],["a","e"],["a","a"],["x","x"]] return = [6.0,0.5,-1.0,1.0,-1.0] Compose or reverse known ratios; undefined variables produce -1.0. Example 2 equations = [["a","b"],["b","c"],["bc","cd"]] values = [1.5,2.5,5.0] queries = [["a","c"],["c","b"],["bc","cd"],["cd","bc"]] return = [3.75,0.4,5.0,0.2] Products along graph paths evaluate indirect ratios. Example 3 equations = [["a","b"]] values = [0.5] queries = [["a","b"],["b","a"],["a","c"],["x","y"]] return = [0.5,2.0,-1.0,-1.0] The reverse edge uses the reciprocal; unknown variables have no path. Constraints 1 <= equations.length <= 200000 values.length == equations.length 0.0 < values[i] <= 10^9 1 <= queries.length <= 200000 Variable names contain one to five lowercase letters or digits. The equations contain no contradictions and no division by zero. Every quotient implied between two connected variables is between 10^-100 and 10^100, inclusive, so all component weights and requested results are finite. Results within 10^-5 of the expected value are accepted.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is to stop traversing per query. Build a weighted union-find where each node stores its ratio to its root. Find with path compression updates the weight as it flattens. Union merges two roots and sets the root weight so a/b = value holds. Each query is then near constant time: if either variable is missing, return -1.0. If both share a root, answer weight[a] / weight[b]. Otherwise return -1.0. The pitfall is the edge case: x/x must be -1.0 when x never appears in any equation, but a/a is 1.0 when a exists. Check membership before comparing names. Another trap is recursive DFS on a 200000-node chain, which can overflow the stack. Go iterative or use union-find. If the weighted find logic slips under pressure, StealthCoder is your hedge during the live OA.
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 Evaluate Division 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
This OA pattern shows up on LeetCode as evaluate division. If you have time before the OA, drill that.
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.
Evaluate Division FAQ
What's the trick for Evaluate Division at this scale?+
Use weighted union-find, or BFS from each component once to assign weights relative to a root. Either way you preprocess so every query is a lookup and a division. Running a fresh DFS per query on 200000 queries is what times out.
What's the edge case that breaks naive solutions?+
A query like [x, x] where x never appears in any equation must return -1.0, not 1.0. Many solutions short-circuit when the two names match. Check that the variable exists in your map first, then return 1.0 for known variables.
Do I need to handle repeated queries specially?+
If you preprocess components, repeats are already cheap. Each query is two finds and a division. If you go with graph search instead, cache results by the ordered pair in a hash map. Preprocessing is cleaner and less error-prone.
Is precision a concern with these values?+
Results within 10^-5 are accepted, and implied quotients stay between 10^-100 and 10^100. Doubles handle that range. Just avoid summing logs unless you're careful. Multiplying and dividing doubles directly is fine and simpler.
How do I prepare for this in 48 hours?+
Write weighted union-find once from scratch, with path compression that updates weights. Test it on a chain, a reversed edge, and a missing variable. Then test x/x for both a known and unknown x. That covers nearly everything this problem throws at you.