Currency Conversion Through Exchange Paths
Reported by candidates from Stripe's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The data structure is the whole question here. Stripe reported this one in January 2025, and it's a currency graph disguised as a string-parsing exercise. Every rate is an edge, every reverse is its reciprocal, and each query asks for the product along a path. If you've seen Evaluate Division, you already know the shape. If you haven't, you've got a day or two to learn it. And if your mind goes blank mid-assessment, StealthCoder runs invisibly as a safety net and hands you the approach in real time.
The problem
You are given directed currency rates as from,to,rate. A rate of USD,CAD,1.26 means one USD converts to 1.26 CAD. Every supplied rate may also be used in reverse with reciprocal value. For each source,target query, return the conversion rate from source to target. The currencies may be directly related, connected through one intermediate currency, or connected through an arbitrary number of intermediate currencies. All queries are connected, rates are positive, and every cycle is consistent, so every valid path between the same two currencies gives the same result. Function convertCurrencies(rates: String[], queries: String[]) → double[] Examples Example 1 rates = ["USD,CAD,1.26","USD,AUD,0.75","USD,JPY,109.23"] queries = ["CAD,USD","CAD,AUD"] return = [0.7936507937,0.5952380952] CAD to USD uses the reciprocal of 1.26. CAD to AUD follows CAD → USD → AUD. Example 2 rates = ["EUR,GBP,0.86","GBP,JPY,190","JPY,KRW,9.1"] queries = ["EUR,KRW","KRW,GBP"] return = [1486.94,0.0005786008] The first query multiplies three forward edges. The second uses the reciprocals of KRW → JPY and JPY → GBP. Constraints 1 <= rates.length, queries.length <= 10000. Currency codes are non-empty and contain no commas. Every rate is finite and strictly positive. Every query's currencies exist in the same connected component. All supplied rates are mutually consistent. Answers are accepted within 1e-6 absolute or relative error.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Build a weighted graph with a hash map from currency to a list of (neighbor, rate). Add both directions, with 1/rate for the reverse. For each query, run BFS or DFS from source, multiplying rates as you go, and return the product when you hit the target. Since every cycle is consistent, any path works, so you don't need shortest. With 10000 rates and 10000 queries, per-query traversal could get heavy, so a weighted union-find or precomputing each component's ratio to a root makes each query O(1) after setup. The common pitfalls are forgetting the reverse edge, skipping a visited set and looping forever, and parsing the rate as an int. If you freeze on the weighted union-find, StealthCoder is the hedge during the live OA, but plain BFS passes the examples cleanly.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Currency Conversion Through Exchange Paths 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. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
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 Stripe's OA.
Stripe reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Currency Conversion Through Exchange Paths FAQ
What's the trick in the Stripe currency conversion problem?+
Treat currencies as nodes and rates as weighted edges, with the reverse edge storing 1/rate. A query is then the product of weights along any path from source to target. Consistency guarantees every path gives the same answer, so any traversal works.
Should I use BFS, DFS, or union-find?+
BFS or DFS per query is the simplest and is usually enough to pass. Weighted union-find is faster for 10000 queries because each lookup becomes near constant time. Pick whichever you can write without bugs under pressure.
What's the LeetCode equivalent?+
Evaluate Division is the closest match. It also gives pairwise ratios and asks for ratios between arbitrary pairs through chains. The currency version adds string parsing of the comma-separated rates and returns doubles for each query.
What edge cases break solutions?+
Missing reverse edges, no visited set causing infinite loops on cycles, and parsing rates incorrectly. Also watch floating point: answers need 1e-6 tolerance, so multiply doubles directly and don't round early. A query where source equals target should return 1.
How do I prepare in 48 hours for this?+
Write Evaluate Division from scratch twice, once with BFS and once with weighted union-find. Then add the string parsing layer for the from,to,rate format. Practice building the adjacency map and checking your output against both examples in the problem.