A Jane Street Software Engineering Mock Interview with Grace and Nolen

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hi my name is Nolan I'm a software engineer at Jane Street I've been here for about six and a half years and I'm Grace also a software engineer at Jane Street and I've been here for about two and a half years we put together this mock interview because we know that interviewing is a stressful process and people come in with different expectations um so we just like to show you what a Jane Street interview might look like and share some advice well we hope that at least some of this advice will be useful for any Tech interview you do we're both James Street employees we interview for Jane Street so we do expect that some of the advice is going to be specific to our own interview process so the video itself is composed of a mock interview followed by us doing a recap of the interview you can find some of the timestamps in the description below if you'd like to jump around and take a look foreign Grace I'm calling from Jane Street uh is this Nolan hey Grace yeah this is uh this is Nolan awesome Nolan it's nice to meet you uh we were scheduled for an interview around now is now still a good time for you yes now is great awesome um and since we'll need it for the bulk of the interview are you next to a computer with internet access yes I am so why don't I go ahead and read you a link that'll get you dropped into the shared editor we're going to be using for the interview and we'll make sure that our technology works and we can kind of talk about the shape of the interview great yeah so just let me know when you're ready to type in the link I'm ready foreign [Music] cool I think I am in awesome I think I see your name at the bottom yes um can you just type something to make sure that I can see it awesome cool uh do you see that I've typed yes sweet uh so our technology Works um that's great news so a couple of things before we jump into this interview the bulk of the interview today is going to be us working through a question in this shared document I'm sure this is not how you normally write code it'd be surprising if you normally wrote code talking to a stranger on the phone in a web browser um so a couple of things to try to make that a little more pleasant so first off please write in whatever language you're most comfortable in there's syntax highlighting for a lot of popular languages in the upper right corner of your screen and if you want to write in one that's not there that's fine too um so you should feel free to change the language go ahead and use Python three awesome sounds great um so another thing to note is that we're not going to be running your code so while I'd like you to write real code so code that given a compiler interpreter you can make run if you do the equivalent of missing a semicolon or something like that that's totally fine um and similarly I'm not expecting that you have the standard library for your language of choice memorized if you forget the name of a common Library function that exists just say something and we'll agree on a reasonable API for that function sure sounds good awesome and then one last note is just kind of like high level advice for what I'm looking for um we really value clear and correct code here and so by default I'd like you to focus on that overwriting super efficient code right off the bat that doesn't mean that you shouldn't try to make your code fast and I'm always going to be happy to come back and ask you to make something faster if I'd like you to um just that by default I'd like you to focus on clear readable implementations okay um so I'm thinking about like code structure variable names things like that foreign cool sounds good cool awesome and I'll leave a chunk of time at the end of this for any questions that you've got for me about the interview process or Jane Street more broadly or whatever's on your mind um but otherwise do you have any questions about what I just described before we get started nope no questions about that sounds great awesome so let's jump into it today we're going to be dealing with unit conversion um and specifically I would like to ask you to write a program that can answer unit conversion questions like how many meters are in an inch given a big list of conversion facts about units so by way of example I'm going to paste in some example facts and queries in the coder pad so a few things to note so the top has a list of example effects and the bottom is like a list of example queries that you can use could be you might be able to answer in this way given those facts um you don't have to do any parsing so I'm going to pass the facts to you as string float string tuples and the query is a float string string Tuple uh got it okay cool yes makes sense cool um so do you have any thoughts on how we might be able to kind of like write a function that will be able to answer these queries given those facts let me think a little bit about this so what are we going to want to do we're going to take in all of these facts are there kind of like two different steps like should I expect to kind of write a function like you know parse facts something like this that returns something and then um answer query query facts or something like that like is this a kind of a reasonable thing or uh would you rather than I kind of parse the facts every every query I think this seems to reason what do you think I mean this seems a little nicer um just so that I can do some pre-processing up front to kind of make answer query simple uh I guess I could do that every time but it seems a little nicer to do all of that work once um so let's think a little about what type of work we want to do here um I guess like conceptually we have a couple of different like disjoint graphs right like there's the like distance graph and the the duration graph in this question and or in in your example and um what do you mean by graph yeah so like we have um one node in our graph is is maybe meter and we have an edge between meter and foot um and that edge has some annotation indicating that a meter is is equal to 3.28 feet similar for feet to inches um and then I mean maybe we have like one big graph and it's just not fully connected um but we have kind of a separate series of connections between hours and minutes and minutes and seconds right and I think like this so go ahead go ahead I just want to confirm so parse fax is going to take that list of facts and like return some sort of like set of graphs or graph um is that is that what you're thinking yeah yeah I mean I'm mostly I'm thinking about like I think at a high level like let's imagine that everything was connected here let's imagine that there is no uh duration then like our algorithm is like pick some arbitrary starting point maybe we could be clever about what that starting point is um and but like pick some node in this graph um oh I I sorry very clearly never mind we pick the node that is equivalent to like meters here because we're answering the two meter question and then kind of uh uh do some type of like BFS or DFS I don't actually know off the top of my head which would be more appropriate here um and keeping track of the state stored in our edges until we find our inches node and then apply some conversion based on that state multiplying like two by the various floats that we've stored at edges to get 78.72 and I guess like when doing that the thing we want to do is um or I guess like if we explore um every node that's connected to meters and um at no point um do we find inches uh which I mean isn't going to happen but like this does happen with inches and hours then we want to return not convertible instead so I think like actually the state that I want to store um to start out is going to be something like a dictionary that Maps strings units to some class that represents a node and a graph and then those nodes in the graph will store like um node store like a float node Tuple where float is kind of the the way that we want to convert between the node that we are operating over and the node that we're linking to um and the node that we're linking to is some other unit that we can convert to so it stores some like you know edges um type of class variable um and then our algorithm is going to be taken um a string look it up in the dictionary do uh some traversal over the nodes kind of stored in that dictionary and return an answer or not convertible um I think there is a clever way to keep these graphs that we're building up as small as possible I have this vague recollection of a thing called Union find but I don't actually really remember uh how it works off the top of my head um I would need to go look it up um is it all right to kind of write the naive thing that I've sketched out here or do you want me to do something uh a little faster absolutely let's go for the naive solution and see how that goes cool and is the thing that I've described like somewhat reasonable does it make sense or is it unclear I think this makes sense to me at a high level um so you want to construct a graph that maps from uh some units to some other units and you're keeping track of in your graph what that conversion rate is does that sound right to you yeah so let's maybe for the sake of being super explicit we can make a Edge class um did you take self in Python 3 I don't remember um multiplier we can just go for it um node solve dot multiplier equals multiplier stuff dot node equals node class node def net self um and we are going to take in like a what uh unit so that's something like M or IM self dot unit equals unit deaf add a child that edge self and multiplier and node other unit something like this self dot multiplier it's multiplier self.other unit equals other unit so um hopefully you know maybe that's that's a bit of Overkill but hopefully that makes it a little clearer how I actually want to store this data and then we're gonna like I said have some dictionary that tracks individual units to their node class so um we can call this whatever name to node it's a dictionary for and then you said this comes as um unit left unit multiplier right unit in facts is that right yeah that seems right float or a string float string or is it yeah okay straightforward string flow seems like a reasonable representation Okay so um let's see what do we want to do if left unit not in name two node uh equals node of left unit aim to node unit balls left node so we want to do that if right unit all right this is surely there's like a nicer way to do this in Python but I'd like to at least kind of sketch this out before I simplify it at all and this is actually named to node not name to name which wouldn't make a lot of sense right unit equals right now and then um equal dot add edge multiplier right unit something like that so I think this is like somewhat reasonable I guess yeah okay so I think that's fine uh maybe I'll come back for a second pass of that in a second but we've got this facts dictionary um mapping units to other units and here multiplier is something like 3.28 or 12. and the thing that I need to remember is to like multiply by it all the time and never divide by it or something like that I can imagine having a bug there so now our query comes in as what float times left unit times rate unit so um final multiplier left unit from unit to unit equals query so I think my plan is just going to be to keep this final multiplier around and multiply right at oh no never mind starting unit amount so now what do we do um let's have some so we're going to kind of have some list that represents how do we want to do this so why did you change it from starting amount to uh oh right yeah um I guess I didn't necessarily need to do that um originally I was thinking like I am going to have some state that I kind of produce um at the end of answer query and that will be like some set of numbers multiplied by each other um and or sorry like some list of numbers and then I'll like multiply all those numbers by each other and then I'll multiply it by starting amount um but was thinking a little more and was like oh it seems a little clearer to instead um have like kind of multiply starting amount in real time like um that is uh instead of like keeping some list around or something like that like every time we kind of uh Traverse across some Edge multiply a starting amount by by the value in that edge so you just kind of keep a running total but I think what I actually want there depends on like how I want to solve the underlying problem here um and I want to think about that for a second um okay sure what do we want to do I think like at a given node we want to enqueue um a Tuple of like current amount and like unit to check or something like that um what is unit to check yeah so so let's see um this is going to be like uh given we are at some node it has some number of edges we want to enumerate all of those edges and um for each of those edges add some new Tuple to a queue where that Tuple contains kind of the amount that we were already keeping track of times the amount encoded in that edge along with the uh uh node that that edge kind of links to um when we do that we want to be careful to not add nodes that we have seen before so we're going to want some visited set and I think also kind of saying all this out loud we want to do this in kind of a bfsu way because of the thing that we care about is finding a short path we don't want to take some convoluted path um because we're like multiplying floats by each other and the more we like multiply fluids by each other the more likely we are to run into like weird float routing errors cool yeah that makes sense to me cool um so we're trying to write a BFS here and you're now thinking about how to effectively keep track of like uh the running product of these um conversion rates does that yeah yeah that's right yeah and so I think it's like it's a BFS but it's a little funny because I think normally at least I don't write that many videos but but I'm not normally kind of trying to like keep some other state associated with like each different kind of conceptual unit in the BFFs um and but but here we are so we want like a visited set and that contains only units um equals set and I guess actually visited dot add from unit at the start and I think or in fact maybe it's easier to do I want to do this I think I just need to like write out a couple of lines of code to see what this looks like so um oh I didn't do this right let's take a step back we want this node class to have some other edges starts out as the empty list and other node I guess that's already a node class so self.edges dot append multiplier other unit you want to do something like that cool and that way we can refer to edges so like four um and I guess you probably want to make that and actually you actually use the Edge class there right oh totally yeah huh uh Edge equals I sketched these out to make my thoughts clear and then just totally failed to use them multiplier other and let's just for explicitness instead of calling this unit call this node to make it a little more clear that it is a full-on node class so we're going to grab that and then we're going to append Edge like that so we've got this Edge in let's not do this so the thing I want to do is instead have some cue that I'm going to be pulling off of right and I think the thing that I want to do is to start by inserting from unit comma starting amount into that queue um and that way my Loop can be like while that cue isn't empty otherwise I'm going to have to like awkwardly pre-fill that queue with a couple of elements and then after that kind of iterate over the queue for a long time does that make sense yeah I think I think this sounds right cool um I also don't quite remember what cues look like in Python I think that there's a q class in collections can I kind of import that and make up a reasonable API yeah I think you should feel free to make up a reasonable API for a queue you can feel free to use a list and we can assume it's a queue up to you okay I'll do like a from collections support Q I think it's capital um so to visit equals Q and let's not actually add from unit to the visited set yet to visit dot push um and so what did we say um from unit starting amount and we can do while not to visit dot empty is empty I don't know um and we're going to say current amount current unit equals to visit dot pop if current unit 2 unit return current amount right or print answer equals but presumably returning that or returning like none is maybe a reasonable API here yep I think that sounds reasonable yep and I think you like swapped your Tuple a little so I think it should be unit comma amount in your two visits set your tube is a cue oh you're totally right current unit current amount thank you for that yeah all right so either the unit is uh the thing that we're looking for or it's not and if it's not first we want to add it to our visited set so visited dot add current unit then for Edge in current unit dot edges um if Edge Dot and what do we call these node and multiplier Edge dot node not invisited if it isn't visited we don't do anything otherwise this amount this is kind of a bad name uh yeah um updated amount I don't know this is all kind of abstract and and high level um but we can say this is equal to current amount times Edge dot multiplier I guess we could say like with latest multiplier and then we want to do to visit Dot push Edge dot node and with latest multiplier and there's something gross here which is that if we see the same node many times here before we process that node once we're going to add it to to visit many times um I'm gonna I think so like a gross thing that we can do is also say visited dot add um Edge dot node um that feels gross to me because we're doing that twice um maybe the right thing to do is to add this up here and special case in the first node cool so we're going to push that in there and I think that's it if it's invisited we don't need to do anything we've added all of the edges adding more stuff to to visit and if we get out here believe we can just return none um how does this look do you want to walk through an example uh yeah sure so oh well there's something one thing that we haven't done I guess like a pretty obvious thing is we've never referenced facts um so we probably want to do that um I think the relevance reason is that um from from unit equals you can just do something like if from unit not or n uh facts for none of two unit not in facts none otherwise um from as a keyword so we'll continue using um maybe I think it's it's maybe a little nicer in Python to not shadow that name so let's do something like facts of from unit and two node equals facts of two unit we're going to update a couple of names here uh to a node conceptually I think like update all of these as well great okay uh so that was kind of a glaring emission um otherwise I think I'm mostly convinced that this parse fax is correct um so I guess I'll focus on answer query we come in we get a query let's say that it is how many uh inches are in two meters and I'm going to be scrolling up and down a lot in order to kind of double check the examples so actually maybe I'll just paste in um this stuff right above my code that way it's a little easier for me to do that so we get in a starting amount which is two a starting unit which is n in an ending unit which is inches both are in facts because we've seen them referenced up here um we retrieve them from fax we put current a current unit is not defined from node we put from node and starting them out so that's meters and two into two visit and we also put meters into the visited set then we pop off meter and two meter is not equal to inches so this check doesn't fire we numerate our edges and our only Edge is going to be feet um so we enumerate our edges we get to feet we add that to our visited set we create a new multiplier which is two times the multiplier associated with that edge which is 3.28 so that's 6.56 I think um and then add feet and 6.56 or whatever it was that I said um we loop back up here we're at feet now we received a foot equals 12 interest fact so foot should have oh you know what one problem when I run into I'm not sure that I'm running it into it here into it here um but I think one problem that I am going to run into eventually is that this parse fax thing that I'm building up isn't bi-directional and it should be yeah that makes sense so you're saying like can you give me an example of what that yeah so this first query that I was walking through this was gonna I believe return the correct thing um because we fed it meters is like meters to feet and we fed it feet to inches however I think when we did this 13 inches thing inches would not have any edges um because well we never thought to add them and so we would immediately give up yep and so what are you proposing changing here um so I think that that means up on line 40 and 41 we want to do something like name to node naively this is all we need to do right unit dot add edge one divided by maybe one point I don't remember how Python 3 division works yeah but um hopefully if I floatify everything it does the right thing left unit and so now we should be adding like when we add a foot is 12 inches we also add that an inch is 1.0 over 12 feet and so things should kind of end up working out yep I think that given one particular fact you can it actually gives you kind of like con two conversion rates right yeah yeah exactly yeah I hadn't thought about that before but that um that seems right cool that makes a lot of sense um cool but otherwise I think that we end up doing the right thing here like in the example we were walking through we were in feet we were enumerating its edges um we would have gotten to inches we would have done 6.56 times 12 which I can't do in my head uh we would have pushed that into our set um or into our queue we would have popped that off current node would be equal to two node they're both Inches and so we would return that amount and I believe that um the kind of reverse case converting inches to meters would now be correct cool all right so during the point at which I would say all right thank you so much I said at the beginning of the interview that I would leave some time for questions and and now is that time we're not going to do that here with Nolan because he already works at Jane Street so presumably his questions about Jane Street have already been answered so we'll just wrap up the mock interview here and dive into a recap of the interview [Music] so to start out let's talk about what we're looking for in an interview at a high level more than anything we're trying to understand what it's like to work with you solving the problem is one aspect but it tends to get overweighted some people get stressed out when they don't solve the problem flawlessly or conversely focused on solving the problem at the expense of everything else and there are many different things that we look for uh you don't have to be excellent at all of these things but we are looking for some areas where you shine some examples of things we might look for include clear communication code structure and Clarity design intuition carefulness updating to your interviewers feedback expertise in your fields or language of choice and of course General problem solving skills now we're going to dive deeper into a couple of those so let's start by talking about clear communication there's advice floating around on the internet that you should be constantly talking out loud during Tech interviews and we think this advice kind of misses the mark a bit because it doesn't tell you what the purpose of that communication is or what types of things you should be communicating to your interviewer communicating clearly helps you and your interviewer get on the same page um this means that your interviewer knows what to expect and they can help you if something isn't going quite right now this doesn't necessarily mean that you need to talk through every line of code as you write it and it also doesn't mean that you need to write your whole solution in pseudocode or in comments before implementing it you can do all of that if it helps you but you should keep in mind that it will slow the interview down a bit and there are often more effective ways to sync up with your interviewer for example communicating clearly might mean clarifying the questions spec up front or Talking Through Your solution before implementing it we also acknowledge that talking out loud while thinking is difficult and is one of those weird interviewing skills if this is particularly difficult for you you should feel free to say something like I'd like to think in silence for a bit so another thing that we care about is clear and correct code correctness is important but we also look for clarity amongst other things that means whether the code structure is easy to follow for example in terms of clear control flow and useful helper functions and whether it's readable for example in terms of good function and variable names we care a lot about code Clarity because it's really important when working in a large and shared code base we want to make sure that there aren't corners of the code base that nobody understands and that it's really easy to dive into unfamiliar code and get started quickly yep and in interviews we generally don't look for code optimization unless it's part of the question straightforward Solutions are typically better than clever ones the best general advice we can give is to practice unfortunately interviewing is a learned skill that takes practice you're in a somewhat contrived setting that's very likely different from what you do and how you code day-to-day now there are sites that offer practice problems for free and we're going to link some of them in the description however those sites tend to focus solely on the algorithmic components of technical interviews while as we've said we try to take a more holistic View so when you practice instead of just looking at the solution saying yeah I could have gotten that we recommend setting a timer trying to implement it yourself and talking out loud like you would with an interviewer thanks for watching we hope this was helpful [Music]
Info
Channel: Jane Street
Views: 251,937
Rating: undefined out of 5
Keywords: Jane Street, Jane Street Capital, Software Engineering, Finance, Trading, Coding
Id: V8DGdPkBBxg
Channel Id: undefined
Length: 37min 24sec (2244 seconds)
Published: Mon Feb 27 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.