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

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?

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? Because 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 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 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, pseudocode 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 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 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 get really full of myself and I'll start thinking of these really complicated optimizations and it overcomplicates 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's N factorial. 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 overcomplicate it. 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 N log N time. I really don't see any reason why it would need to be slower than that.

But then I start coding and I add a loop that changes it to N squared. 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 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.

The 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 start time, we could go through all the meetings and see which meetings are going on there.

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 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 N, and then I'll think, what is the next faster runtime I know?

What algorithms do I know already that fit linear time, Big O of N? I know sliding windows generally Big O N, and I know quick select is usually N, 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 preprocess 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 LeetCode 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 breadth-first 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 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 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 breadth-first 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.

The second method usually isn't as obvious, but it's super 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 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 a 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 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 raw 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 one-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.

How I Passed The Google Coding Interviews

Scripts