Grace and Nolen's Software Engineering Mock Interview

Grace and Nolen are software engineers at Jane Street. They created a mock interview to make the process less mysterious, followed by a recap of what they look for and how candidates can prepare. Grace plays the interviewer and Nolen the candidate; some advice is specific to Jane Street.

Grace explains that they will work in a shared editor. Nolen may use the language he knows best, and they will not run the code during the interview. She asks for real code but does not expect perfect punctuation or memorization of every standard-library API; they can agree on a reasonable interface.

Grace says she values clear, correct and readable code over immediately producing the most optimized solution. She can ask for a faster version later if needed. She also leaves time at the end for the candidate's questions.

The problem is to answer unit-conversion queries using a list of facts. Examples include one meter equaling 3.28 feet and one foot equaling 12 inches, as well as hour-to-minute and minute-to-second facts. Facts arrive as string–float–string tuples and queries as amount–source-unit–target-unit tuples; parsing text is not required.

Nolen asks whether to separate preprocessing from query answering. Grace invites him to choose, and he prefers building a representation once so multiple queries can use it. He recognizes disconnected groups of units: length conversions form one graph and time conversions another.

Nolen explains the graph model: units are nodes and a conversion fact is an edge annotated with its multiplier. To answer a query, start at the source, traverse toward the destination and multiply the amount by the factors along the path. If the destination is unreachable, return that the units are not convertible.

His initial representation is a dictionary from unit names to graph nodes, with edges carrying a multiplier and a neighboring node. He recalls that union-find might offer a more clever alternative but does not remember the details, so he asks whether to proceed with the straightforward approach. Grace agrees.

Nolen sketches Edge and Node classes to make the representation explicit. He then starts a preprocessing function that loops through facts, creates nodes for unit names not yet present, and connects the appropriate nodes. He notes that he may simplify the Python later after getting the structure down.

Moving to query handling, Nolen considers collecting multipliers and combining them at the end, then changes his mind: carrying the current amount and multiplying it along each edge may be clearer. Grace asks about the change, and he explains his reasoning instead of silently moving on.

Nolen proposes a queue containing a unit and the amount expressed in it. For each outgoing edge, enqueue the neighboring unit with the amount multiplied by the edge factor. A visited set prevents repeatedly exploring the same nodes.

He chooses breadth-first search because it finds a shorter path in number of edges, which he hopes will reduce accumulated floating-point rounding from multiplying many factors. Grace confirms that the approach is a BFS carrying additional state for each queued item.

While writing the code, Nolen revisits the Node class and adds an edge list. Grace points out that the sketched Edge class is not yet being used, and Nolen fixes that. He initializes the queue with the starting node and amount so the main loop can handle the initial state consistently.

Nolen does not remember the exact Python queue API, so Grace permits him to assume a reasonable one. In the loop he removes a node and amount, returns the amount if it is the destination, and otherwise explores its edges. Grace spots that he has reversed the tuple order, which he corrects.

The traversal multiplies the current amount by each edge's factor before enqueuing its destination. Nolen notices that marking nodes only after they are removed can put the same node in the queue multiple times, so he adjusts when nodes enter the visited set. If the queue is exhausted, he returns None.

Grace asks Nolen to walk through an example. He first notices that the query function has not looked up its source and target in the preprocessed facts. He adds checks for unknown units and retrieves the corresponding nodes before tracing the algorithm.

For two meters to inches, the queue starts with meters and amount 2. Following the meter-to-foot edge multiplies by 3.28, giving 6.56 feet; following the foot-to-inch edge multiplies by 12, yielding 78.72 inches. The walkthrough checks both the state and the control flow.

The walkthrough exposes another issue: the graph currently records only the direction supplied in each fact. It can convert meters to inches but may fail in the reverse direction. Nolen adds a reverse edge with reciprocal multiplier, so a foot-to-inch fact also supplies inches-to-feet conversion.

Nolen concludes that with reverse edges the same traversal can answer the reverse query as well. Grace ends the mock interview; because Nolen already works at Jane Street, they skip the usual candidate questions and move to a recap. The exercise was discussed rather than executed in the shared editor.

In the recap, Grace and Nolen say the main goal is to understand what it is like to work with a candidate. Solving the problem matters, but it is not the only criterion: they also look for communication, code clarity, design intuition, carefulness, response to feedback, relevant expertise, and general problem solving.

They caution against interpreting ‘think aloud’ as an obligation to narrate every line. Communication helps interviewer and candidate stay aligned so the interviewer can understand the plan and assist when needed. Clarifying the specification or talking through an approach before implementing it can be more useful than exhaustive commentary.

Thinking aloud can itself be difficult, and candidates can say they want a moment to think silently. The speakers also emphasize clear, correct code: control flow, useful helper functions, and good names make it easier for others to work in a large shared codebase.

Unless optimization is part of the question, a straightforward solution is generally preferable to a clever one. Their strongest advice is practice: use a timer, implement the solution yourself, and explain your thinking as you would to an interviewer, rather than merely reading a solution and assuming you could have produced it.