Interview
A Jane Street Software Engineering Mock Interview with Grace and Nolen
Jane StreetGrace, Nolen, Nolan, Emily Fortuna, Colton Ogden, Todd Kerpelman, Jen Person, Colt McAnlisley, Dan Galpin, Mark Mirchandani
- The mock interview is structured as a live coding session followed by a debrief, designed to replicate the specific format and process of a Jane Street interview, with dedicated time reserved for candidate questions regarding the process or the company.
- Coding expectations include the requirement to write functional code capable of running in a compiler or interpreter where minor syntax errors are permissible, with a default focus on clear and readable code over immediate optimization unless specifically requested.
- Standard library memorization is not required; interviewers anticipate agreeing on reasonable APIs if common functions are forgotten, and candidates may use languages unsupported by syntax highlighting provided they can run the code.
- Communication during the session is intended to align expectations rather than necessitate line-by-line commentary, though candidates are informed they may request silence for thought, and clarity is emphasized as critical for future collaboration in large shared codebases.
- Candidates are expected to employ straightforward solutions rather than clever ones, with optimization considered only if part of the specific problem statement, acknowledging that interview performance is a learned skill distinct from day-to-day coding.
- Recommended preparation involves setting a timer, implementing solutions independently, and practicing verbalizing thoughts, rather than passively reviewing solutions.
- Specific implementation plans described include parsing input facts upfront to simplify queries, constructing a graph of units and conversion factors where disjoint graphs are anticipated, and utilizing BFS or DFS traversal to find paths.
- Technical considerations for the candidate include using a dictionary to store unit-to-node mappings with float conversion rates, handling unfindable targets by returning "not convertible," and preventing floating-point rounding errors by multiplying a running total rather than storing a list of multipliers.
- Potential implementation risks identified include adding nodes to a queue multiple times, omitting checks for start and end unit existence in facts, and failing to create bi-directional edges in the graph structure.