Evaluate Division is a graph problem disguised as algebra. You are given a list of equations like:
a / b = 2.0
b / c = 3.0
Then you are asked queries like:
a / c = ?
c / a = ?
x / x = ?
Your job is to compute each query’s result using the relationships implied by the equations. If a query cannot be answered using the given information, you return -1.0.
The key detail is that variables behave like nodes in a network. Each equation gives you a direct conversion rate between two variables. Once you see it that way, the problem becomes less about division and more about “Can I travel from one variable to another, and what is the product of weights along the path?”
This is why Evaluate Division is a common interview question. It tests whether you can translate a problem into the right model, then choose a traversal strategy that handles multiple queries efficiently.
What makes it tricky
The equations do not come in a helpful order. You might need multiple hops to answer a query.
For example, if you know a / b and b / c, you can derive a / c by multiplying. If you need c / a, you take the reciprocal.
Some variables may be completely disconnected. Others may appear only once.
Queries can also include variables that never appear in the equations at all, which must immediately return -1.0.
Want to explore more coding problem solutions? Check out the Maximum Sum Circular Subarray and Coin Change II coding problem solutions.
The solution idea that interviewers expect
Model the equations as a weighted graph
Think of each variable as a node.
Each equation u / v = k becomes a directed edge:
u -> v with weight k
v -> u with weight 1 / k
That second edge matters because division relationships are reversible. If you can go one way, you can go back using the reciprocal.
Once you build this graph, each query x / y becomes:
“Is there a path from x to y? If yes, multiply the edge weights along that path.”
How to answer queries using graph traversal
For a single query, the most straightforward approach is to run a search from the start variable until you find the target variable.
Depth-first search works well here because you are not looking for the shortest path. You just need any valid path, and you need the product of weights along it.
Breadth-first search works too. The choice usually comes down to personal comfort and implementation style.
During traversal, you carry a running product. If you start at x with product 1.0, then each time you move across an edge, you multiply by that edge’s weight.
When you reach y, the running product is the answer for x / y.
To avoid loops and repeated work, you keep a visited set for the current search. That prevents cycles like a -> b -> a -> b from trapping you.
What to do with missing variables and impossible queries
Before you search, you check whether both variables exist in the graph.
If either variable is missing, you return -1.0 right away.
If both exist, but there is no path connecting them, the search will end without finding the target. That also returns -1.0.
A special case people ask about is x / x.
If x exists in the graph, then x / x should be 1.0 because any value divided by itself is 1, and the graph representation supports that identity.
If x does not exist at all, it should be -1.0, because the problem treats unknown variables as undefined.
Why this approach is efficient in interviews
Building the graph takes linear time in the number of equations.
Answering each query takes time proportional to the size of the connected component you explore in the worst case.
That is usually fine for typical interview constraints. It’s also easy to explain, which matters as much as correctness in a real interview.
If the problem has many queries and you want to reduce repeated searches, you can consider caching results or using a union-find structure with weights. But most interviewers are satisfied with the graph traversal solution as the primary approach, as long as you communicate the idea clearly.
Common mistakes to avoid
A frequent mistake is forgetting to add the reciprocal edge, which breaks queries in the reverse direction.
Another common issue is not using a visited set per query, which can cause infinite recursion or repeated work on cyclic graphs.
Some candidates also return 1.0 for x / x even when x is unknown. In this problem, that usually counts as incorrect.
Top comments (0)