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.

think out loud in comments and in pseudo code. Write just 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 code 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

what would you 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, motivation, energy, stability in your mood, and so on, right? A lot of bang for your buck 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

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 miss 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 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 tests 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 LeetCode hard. We're basically going to reverse a linked 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

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 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

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

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 you're 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

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.

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.

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. The key point here is we can either modify an algorithm to fit the data structure or modify the data structure to fit the algorithm. The 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

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! 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-complicate it. As you can see, I'm really trying to emphasize thinking and talking about runtime and memory.

I passed every round of coding interviews at Google, but then they announced a hiring freeze, 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 six-figure full-time offers. On top of that, I've taught, coached, and mentored people through the coding interview 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.

and base cases that you might need to handle, right? Maybe you want to write these out in comments, right? 'Cause 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

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 n, and then I'll think, What is the next faster runtime I know? Big O of N is a step up from n log n. What algorithms do I know already that fit linear time Big O of N? I know sliding windows generally Big O of N, 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 an example. This is a code hard called bus routes. So you're given a

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 three 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 streak. If I'm failing hard problem after hard problem after hard problem, then when I get a

to get the next K nodes, reverse that sublist, and move on, and just reassign the pointers. That's basically the solution. The 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 solution, but it's more readable, and I feel less likely to mess

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 did? 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 it with the interviewer, pseudo-code 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 walked through, right? People do things differently; this is what works for me personally. You basically want to

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 breadth-first search does for sure give you the 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 to 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 breadth-first search. Essentially, in our BFS queue, 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 stops, routes, and transfers between routes. This means you

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.

[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, and you're just staring at the problem. What do you do? The first thing I would recommend you keep in mind is to 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 pseudo. 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

How I Passed The Google Coding Interviews

How I Passed The Google Coding Interviews

Scripts