How I Passed The Google Coding Interviews

I passed every round of coding interviews at Google but then they announced a hiring free so I didn't end up working at Google but I did end up pretty decent at coding interviews trust me I dare you to interview me I dare you please give me an interview I studied computer science at UC Berkeley I also did software engineering internships at Amazon Bloomberg Facebook Lyft and then I landed some big sixf fig full-time offers on top of that I've taught coach and Mentor people through the coding interiew process and I've seen them get offers as well today I want to talk about specific strategies tricks mindsets and thought processes that I used on the spot during my actual interviews they worked for me and maybe they could work for you this will include brainstorming and planning a solution collaborating with the interviewer and communicating your thought process as well as working towards an optimal solution I'll give tips for actually structuring and writing the code itself as well as mention some common pitfalls that you should watch out for Here We Go [Music] here are basically all the data structures and algorithms you should be familiar with I'll cover each of these in detail in future videos but today we're focusing on just doing the actual coding interview they give you a problem you're just staring at the problem what do you do first thing I would recommend you keep in mind is take way longer than you think you need to before you start coding right you want to spend as much time in the collaborating with the interviewer step the planning step the brainstorming writing comments and sudo you want to spend a lot of time there and you do this for a few reasons one Your solution for most problems is going to be what like 10 to 30 lines of code imagine you already know the solution you know what you're going to code it takes you like 2 minutes to actually type out all the code yes you will have to debug issues and handle edge cases while you're coding but generally right if you can't think of your solution and plan it out and understand why it works and convince your interviewer that you know the solution what are the chances you're suddenly going to do all of that while you're coding it is very difficult to multitask once you start typing code you're thinking about syntax you're thinking about your conditionals you're thinking about how to structure your functions right how are you going to do that while coming up with the solution right just do one at a time another reason is I feel like interviewers are more likely to help you out if they understand what you're trying to do and they understand you know where you're going if you just start coding and you don't know where it's going to end up the interviewer is just going to check out they'll just sit back and they'll be like all right I'll wait till he gets stuck or maybe he solves it you don't want that to happen you want to keep them engaged the next thing I would do is collect observations about the nature of the question itself all the edge cases and base cases that you might need to handle right maybe you want to write these out in comments right cuz making observations is going to help you pick up on the structure of the problem and patterns and maybe those will lend themselves perfectly to known data structures or known algorithms so now this part is super important okay the interviewer is probably going to give you a bunch of sample inputs and a bunch of sample outputs that correspond with the inputs and you want to come up with a bunch of sample inputs of your own a bunch of test cases for basically every single problem there is a way to manually intuitively turn an input into a solution output otherwise there would be literally no way for the interviewer or for you to verify what a correct solution might even look like and the good news here is that if you can get an input and convert it into its solution with no code no algorithm then you do know an algorithm for solving the problem right it's just subconscious your brain follows algorithms whether you know it or not your subconscious your intuition it's very powerful right and then it just becomes a matter of mindfully asking yourself okay why did I make the decision that I what process am I intuitively following why did I decide to switch these two numbers and not these two numbers and I think it's easier to think of it like this right you're just drawing out something you kind of feel intuitively and converting it into something that you can consciously step by step write out this feels a lot more manageable than thinking of it as I'm inventing an algorithm on the [Music] spot the next thing I would recommend is as you're planning as you're coming up with your solution and as you're verifying ing it with the interviewer pseudo Cod it because it's really tempting to just plan a whole algorithm ask your interviewer oh is this reasonable should I go ahead and code this and then by the time you start coding you got to remember everything you just walk through right people do things differently this is what works for me personally you basically want to think out loud in comments and in pseudo code right just write out the steps in plain English so that by the time you start coding all you have to do is just swap out every line of pseudo Cod and fill it in with actual code another thing I personally just my opinion feel like most reasonable interviewers will appreciate you admitting that you don't know something that you're not sure showing a willingness to learn and I think it's okay to ask I'm not sure about this could I get a minute to think about it I think it's way better to have silence where you're just critically thinking rather than rambling on with a bunch of filler words where you're just distracting yourself and it's not a good look okay so now what I would do is try to get to a Brute Force solution this is basically whatever is the most obvious solution right however you can possibly solve the problem even if it's super inefficient I have trouble with this because I get really ahead of myself I get really full of myself and I'll start thinking of these really complicated optimizations and it over complicates it and it turns out the interviewer would have been perfectly happy with just the Brute Force solution I'll give you an example right let's say you're doing a problem where you have to count all the unique permutations of a number right you might think there's some crazy hack to pre-calculate this number without actually generating all the permutations but you could start off just by saying all right one way to solve this is to just pick every possible number as a starting point and then recursively add on numbers until we've generated every single permutation and then just return the number of new unique ones right that sounds very slow that's n s I can think about how to optimize this but what do you think is this good enough and the interviewer might just say okay that's cool let's code that so then you don't have to over complicated as you can see I'm really trying to emphasize thinking and talking about runtime and memory usage constantly just so the interviewer knows you're thinking about efficiency but the main thing is it helps me not go in the wrong direction right let's say I look at a problem I really think about it I build this intuition that I'm pretty sure that this could be solved in end log end time I really don't see any reason why I would need to be slower than that but then I start coding and I add a loop that changes it to N squ I want to be able to catch that and be like oh we shouldn't need this let's shut it down go back to the drawing board and it saves me a lot of [Music] time I'll walk you through an example using everything I've mentioned so far here we have a list of meetings which are intervals of start and end times we want the minimum number of rooms to accommodate these meetings right now I kind of want to walk through some very simple example answers and see if we can pick up on any patterns so some observations when would the answer be zero if there's no meetings when would the answer be one well if there's only one meeting or if there's many meetings but there's only one going on at any time answer would be two if there's Max two meetings at any time and so on quick little proof by cases so given what we've noted we can reframe the question as the maximum number of meetings that overlap at any time so how would we solve this intuitively forget the code imagine you're actually in an office and a supervisor gives you these meeting times and they say hey let me know the max number of rooms they used you would be able to do this in person you could just sit at your desk and as the day goes on constantly check how many rooms are used in real life you would really see these meetings in chronological order boom intuition we can sort these intervals by start time so we can track all of them as the day goes on again just Brute Force at any start time we could go through all the meetings and see which meetings are going on there we go a Brute Force solution it's a bad one but there are things that just stick out so we're constantly checking on rooms only because we want to update the max so far but the maximum number of rooms only ever changes when it could only ever change if we're adding another room you would only ever add a room if a new meeting is starting when a meeting starts well do we need a new room well first we got to see if previously running meetings have ended by now so we clearly need to store meetings that are currently running and we only need to know when they end so we just store the end times so now for our current start time we're looking at for all the meetings that have ended by now we'll never need to check them later on in the day so we can remove them from where we're storing them boom this screams Heap so we remove all the previous meetings grab a room for our current one and update our Max and what look at that boom plug in each line there plug in each line there look at that everything was literally already there oh is it too long just pull out the comments bam optimal solution at this point it doesn't really feel like a programming test we're really just noticing things over and over I encourage you to try this kind of approach for even harder problems some good things I like to ask what do we actually want is there anything that needs to happen for us to get that what are all the things that could affect it what are all the possible cases of things that could [Music] happen now let's say you get a Brute Force solution and you need to find a more optimal one if there was a formula I could give you to do this in a straightforward way companies wouldn't be doing coding interviews it's just really tricky in general a lot of times I'll get stuck thinking what's a better way to solve this problem can I come up with a new algorithm that might be better and then how fast is that one now I've actually learned to do it kind of the opposite way I'll actually look at my current solution and think what is the runtime of this one let's say hypothetically it's n log in and then I'll think what is the next faster runtime I know Big O of N is a step up from nlog in what algorithms do I know already that fit linear time Big O of n I know sliding Windows generally big oen and I know quick select is usually and assuming I pick good pivots do either of those apply to my current problem and usually I'll make progress this way if you're having trouble finding a solution a lot of times it's because of the way the input is structured you might want to think how can I rearrange or pre-process the input differently such that it lends itself to an algorithm maybe you got to sort it or convert it to a new data structure let me show you example this is aite code hard called bus routes so you're given a list of routes and each route is itself a list with a bunch of numbers which represent bus stops so you're trying to go from one source bus stop to a Target bus stop and you're trying to find the minimum number of buses that you need to get from source to Target now we know that breath ver search does for sure give you a shortest path between two nodes in an undirected graph but if you look at the way the input is structured This lends itself to a graph where the bus stops are the nodes so if we ran BFS on this it would give us the minimum number of bus stops to get from source of Target but we don't care about the number of bus stops we want the minimum number of buses or routes we could handle this by doing some really complicated modifications to breath first search essentially in our BFS Q we would normally just track the nodes of the graph which are the stops but now for this problem we would need to track combinations of of stops routes and transfers between routes this means you might also revisit nodes from different routes which you wouldn't do in normal BFS at this point this is no longer traditional BFS so we can no longer rely on the guarantees of correctness and optimality that BFS has a better way to do this would be to convert this from a graph of bus stops to a graph of routes and two routes are connected if they share a common bus stop and now that we have this kind of a graph we can just run for search as it normally is and we know that it works key Point here is we can either modify an algorithm to fit the data structure or modify the data structure to fit the algorithm second method usually isn't as obvious but it's super [Music] useful so now we get to actually writing the code you want to start really Broad and then fill in the details later there's this concept called the single responsibility principle and what that means is that each function or method should really only be responsible for implementing just one thing if you need to implement multiple things you should split it into different function calls a big reason you do this is just in case you run out of time if I'm going to run out of time I would rather show that I outlined and pretty much coded out the entire solution but I missed some really boring implementation details versus implementing some really tedious function and missing out on the rest of the overall solution generally using abstraction and SRP it does does make it easier to test with print statements it makes your code more readable and also it's good practice in software development it allows you to do mock test and also separate functionalities into different API calls but you'll likely not do that in an interview when I give any of these tips I mean use them just to the extent that they don't slow you down and they don't make your code performance less optimal I'll show you an example with Elite code hard we basically going to reverse a link list except K nodes at a time of course I'm writing out my intuitive approach while I still have nodes to reverse I'm going to get the next K nodes reverse that sublist and move on and just reassign the pointers that's basically the solution tricky part is basically handling all the pointers and the references it's really hard if you do it like this you Rod Dog it all in one chunk you're trying to do black belt pointer Jiu-Jitsu boom error how are you debugging this I would write it like this yes it is longer but it exactly follows the steps that I outlined earlier it is not confusing just my opinion and boom there we go now let's talk about naming and readability sometimes you'll see code like this sure this is really concise but the function name the variable names all these on liners I don't know what I'm looking at what does this do this is still valid though there are reasons to write code like this like in competitive programming where all you really need is speed but I would rather have an interviewer read this exact same problem exact same Sol solution but it's more readable and I feel less likely to mess up the coding or have a logic error when the code looks like this the function name tells you exactly what this does and the variable names are descriptive they tell you exactly what they mean and the formatting of the code follows the actual logic I want to finish off this video by talking about something that's extremely important and it's probably the most underappreciated or neglected parts of this whole process how are are you yourself as a person showing up to this interview how are you managing your motivation your confidence and your mental health throughout the interview process it's a grueling process not just the interview day but the weeks or the months leading up to an interview for me personally as an example let's say I have an interview coming up I'll try my very best not to let this interview be the only thing I have going for me in my life I'll try to keep up with the sport keep going to the gym make sure I'm socializing with friends try dating someone new try playing a video game get into a new show right if this is the only thing you're anticipating it's going to put way too much pressure on it right I want to come into an interview feeling like okay I would really like this job but if I don't get it I can walk away and I'm doing fine and that gives you confidence to be really self assured during the actual interview what kind of problems should you do leading up to the interview this isn't super common advice that I've seen but for me personally for the last day or two days or 3 days even leading up to the interview I want to steer clear of doing any ridiculously hard problems that I likely can't solve I want to avoid doing really high pressure mock interviews sure maybe before that for the weeks prior I challenge myself I do some crazy DP some crazy graph reversals but I don't want to walk into the interview on what feels like a losing Street if I'm failing hard problem after hard problem after heart problem then when I get a problem in the interview my first thought is I'm going to fail this like all the others right I try to go feeling like I'm used to handling whatever's in front of me another thing is you want to avoid cramming in the last 24 hours of the interview every second every hour of studying does count but in the last 24 hours there are things that count way more let's say in the last day I cover an extra two or three or maybe four leod problems that probably helped but then I show up to the interview my attention is a little bit scattered I'm a little bit burned out I'm a little bit tired or demotivated my performance plummets it's like I climbed two steps up the stairs and then fell down the staircase but let's say instead I got a lot of sleep took a nap if I needed to had a video call with a friend spent time on a creative Outlet I cooked a really nice meal that I like and I'm feeling good what would rather have one hour to Maybe cover one new le code problem before the interview or get in a light to a moderate workout that's going to give you mental Clarity it's going to give you motivation give you energy give you stability in your mood and so on right a lot of bang for your book there at the end of the day coding interviews they are just this arbitrary puzzle game it's kind of like the SAT or the MCAT or the LSAT it's not meant to be a perfect representation of how you are on a day-to-day basis on a job or on a project unfortunately companies just need some way to interview people in a way that's practical for them efficient for them and standardized across people and I guess this is the best way that people have come up with so while this is the standard I guess it is what it is got to do what we got to do so thank you so much for watching I hope you found this helpful I had so much fun making this video make sure to give this a like subscribe and hit the notification Bell if you want to see more videos and I'll see you in the next one good luck on your interviews

Channel: Chris Jereza

Views: 21,433

Keywords: google, software, engineering, software engineering, swe, coding, coding interview, coding interviews, chris jereza, christopher j, python, programming

Id: ksZ2wFRZ3gM

Length: 18min 49sec (1129 seconds)

Published: Fri Apr 19 2024