And welcome back to another episode of the T lead.

It's good tete lead.

Now, I thought what I would do for you guys today by popular demand is give a mock Google interview.

Now, I've done about 100 of these interviews at Google, and I wanted to present you what it would actually be like and to give you a real question that I ask.

So let's just get right into it.

You walk in.

Agreed you.

Hi.

My name is Patrick.

Great to meet you.

Everything going okay?

Are you?

You need a couple of water, You need a bathroom break.

And as I mentioned before, if you don't really need a drink or a bathroom break, that just refuses.

So you have as much time as possible for the interview.

And then I generally give you a little bit of background about myself.

Tell you what I've been working on so that you can calibrate your conversation for me.

And basically, by giving you some of my background helps you understand how technically deep you can go in your own conversations or what areas I might be interested in knowing about it and be able to comprehend.

So I've been working here at this number of years, I've been on this team.

I used to work at this company.

I have this background now I would like to hear about you.

Tell me about yourself with your story, and this is kind of where you may need to have something prepared.

I probably haven't even read your resume completely.

At this point, I may have stand it, and all I know is I've been scheduled to chat with you, and basically, this is your chance to shine.

Talk about in the interesting project that you've done.

You can go broad and just say like you graduated from this school, that you went to this internship and with this company and you did this project, and that's okay.

But you really do want to at some point go deeper into some project because what I would really like to hear is some technical challenge for leadership or something technically impressive that you may have done, and it doesn't necessarily need to be impressive.

Like you'd be surprised how little you need to do to actually do something that may sound impressive.

You know, like if you can even set up a website and do basic back and cause and connect to a database on bringing some users or something like that, like that's already pretty good, really.

And as I understand, a lot of people may not even ask you for your story.

I personally like to ask for your story so that I'm not just give you a whiteboard in question.

And if there's something interesting that you've done in your own spare time in some project or something, unless you talk about that and that's the other thing is, there's no real rule about the interview.

Everyone conducts the interview however they want, so I can tell you how I might do things.

But it's really not reflective about how anyone else may be doing this.

This is just the way I do it.

And basically, if you can talk about feigns like technical challenges and complexity that you may have done like engineering efforts or technical leadership, like managing people or initiating projects or a possum sort of impact that you may have had like you were able to tackle this key area that was able to bring in lots of users or something like that, like any of those three areas would be really great to hit and probably for junior people.

What you're really looking to show is some technical complexity.

And by that I mean, like, not just like creating a really complicate the system.

We're like there's a ton of four loops and that if l statements, the technical complexity is more like good consideration of tradeoffs, pros and Collins memory time, maybe using NBC principles, object oriented design.

Maybe hooking up a lot of different AP eyes together would be interesting to hear about.

And you want to remember to show that impact because a lot of people will say some complicated thing that they've done, and it's really hard to understand.

Okay, was what was this really about?

Like, was this real?

And if you could say, Yeah, we got, like, 5000 users or something, you have that kind of validates a lot of the work, So I would recommend that any project we do try to figure out what was the impact of that and craft a story and be able to prepare that story so that you can talk about it as soon as somebody asks, You tell me about yourself and then this portion.

I would recommend checking the interviewers reactions of it and find out if they have questions for you like they may not be interested in your story at all.

They may think you're going in that direction.

That's not interesting.

They may be bored.

They may not understand the technical jargon that you may be using and this key that you don't lose the interviewer here.

If you bewildered the interviewer at this stage, you will be viewed as somebody who can't communicate clearly.

And not only that, you would have made the interviewer board and the interview would just be like, Yeah, I don't know.

Let's let's just move on to the white boarding because this doesn't make sense.

This is a waste of time, and you basically lose your chance to shine in the qualitative portion.

Don't make it too long, but it might even be nice if you could get on the white board and quickly draw a diagram of whatever you were building.

And just remember to keep it quick because you generally have about 45 minutes to complete the interview.

I'd like to spend the 1st 15 minutes on you telling me about yourself and then have that last 30 minutes on the after a whiteboard in question.

So in the whole scheme of things, just really not enough time like that.

Time passes by really quickly now.

Often when the candidate is still talking, I will start drawing on the white board because I know we're running short on time already, and I would draw this picture.

So this is the question that I really like to ask.

And it is that given a grid, find the maximum number of connected colors on dhe.

You can see that in this picture it is five.

Those five blue.

It is those five blue boxes at the bottom.

Now, this is a question that I ask very often because it gives me a very good signal just in my own personal experience.

And in fact, it is very similar to this question called Flat Phil and fled.

Phil is such a great question.

I think it's even been banned.

But the question I ask is a slight variation on that.

So I so ask it.

And in my opinion, even if the question is considered a band because it is so commonly asked.

And people think that everyone knows the answer to this question because it is such a coming interview question usually actually for me.

Even when the candidate tells me that they've heard this question before, I still like to ask if it's not really about.

If you can solve it, most people can solve.

It is really about how yourself and I'd like to see how you solve it on Dhe.

That's what makes it such an interesting question, because it will actually tackle things like data structures, algorithms, coding touches a lot of different areas Now, over the years, a lot of tech companies have started to phase out trick questions where you either have, how moment and you get the answer or you basically failed because that really doesn't give any good signal.

And a lot of those questions have no real practical use in the industry.

This question, I feel, actually, is a pretty good question because it's actually practical, like this question basically involves something very similar to treat reversal, and it's something that's actually done all the time.

Like you may have like a tree of views and sub views, and you want the builder Trevor's every single view and serve you without necessarily duplicating each one.

Or you may have a bunch of notes that are connected, and you want to be able to visit every single note.

You should also keep in mind that you're being evaluated on your ability to rise to become a senior engineer.

So you may not use some of these skills as a junior engineer.

But junior engineers are expected eventually.

Get to that senior engineer level.

And if you can't make it there like you don't have the foundations to be able to become a senior engineer than there's no future for you at that company.

Basically, because you need to be able to get to that level.

And when you're interacting with senior engineers who may be putting out proposals for treat reversals and efficient day those directors and things like that, it would be great if you could be able to at least converse with them and not just asked completely amateurish questions like Why are you using hash table?

Why not using the rays like because the array of slow how do you traverse a tree structure.

What, like how do you do that?

Like that's, um, Anyway, let me give you the solution.

And if you want to think about that yourself, go ahead and pause the video.

But the solution is a death for a search in the double for loop, so you have to four loops that you can operate through every single cell in that grid.

And for each sell, you issue a death for a search.

And you this could be a breath for a search to.

It's pretty much the same.

And that's just going to visit every single neighbor and from their visit every other single neighbor and is a recursive outward.

Then, basically, and it can also be done figuratively as well.

And what you also need to do is make sure that you don't revisit cells that you have already seen.

Otherwise, you will Rikers forever going back and forth between two different neighbors.

So this may require to Memphis.

The first is a double for Luke method that it raced through every single point and caused death for research on each point, and then the second is that their first search function.

I'd like to leave it pretty open ended so I can see what the destructor as you choose.

Some people may choose to use the actual day this director to represent each grid point and, like they could have a great data structure.

Actually, some people tried to set up a connected group of notes.

It may be simplest to just have it to the array of deters where each entered your represents a color.

Any of these is really fine.

And if it looks like the candidate is somewhat junior, I'm going to push them to just do it to the array of indigenous as probably the simplest.

Also, if the candidate is junior on my simplified the question and just say, let me just give you a starting point so you don't have to reiterate through every point.

You just start at the point.

It's basically just at that first search function from their own now, and the meat of this algorithm is really going to be in that first search function.

That's why I want to see you right, and it really involves going to each point and from each point calling that first search worker sickly on each of the four neighbors, and it's basically interesting to see how people would get those neighbors like like you could check each individual point like left top right bottom.

And the problem with that technique is you're going to have a lot of bounds checks like you're going to be doing EJ checks all over the place.

For that on that can be a little messy and tedious threat.

And if you instead we're too right.

Methods like is valid or get neighbors or something like that, that would actually help you.

Then we get some of the edge cases to other methods.

Other functions that you can later fill out if you have time.

But basically be able to save yourself as much time as possible is going to be one key thing in this.

Another thing I've seen some people do is they set up an array of coordinates like negative 100110 and zero negative one, and those represent before neighbors and then the injury through that list to compute the neighbors.

And I thought that was also pretty neat way to generate the neighbors, although that's really not all that necessary either, Like if you know it's it's perfectly fine to just write out the neighbors manually.

But I think you do probably want a way to deadly get away the need to do bounce checks on all the neighbours because that's going to be somewhat time consuming to do.

One thing that people will need to do is to duplicate detection.

So each time you visit a cell, you need to somehow remember that and the optimal day.

The structure for this is probably going to be like a Hashmat hash cape with eye popping.

And here's where I like to ask people as well.

Like, Hey, what happens if there's a collision with your hashing function?

And that kind of shows, like Do people understand the time space complexity of a hash table?

How it works, what that hashing function is?

So I think those are our great things to see.

Some people will not use the hashtag one just using array, and that's kind of a red flag because an array is less efficient.

Day this director and and by now personally, I just like to see engineers know when to use hash tables like they should have that to at their disposal and know when to use it.

Clearly.

So usually candid, this will write the recursive our than first and you know that's great.

But then what I like to do is ask them.

Hey, do you know about Stack overflow from Rikers in?

And you know, it was like, Oh, yeah, Rikers generally uses stack space.

We're just limited, and that limit is going to be based on the amount of staff space you have.

But it's something like 10,000 iterations or something like that.

So this is where you probably should have asked the question, like, How big is this great going to be?

And I would have said, Oh yeah, the great would have been, like 10,000, 10,000 or something.

And that's when you realize OK, you should be using an intuitive solution because the intuitive algorithm is basically not going to be bound by a stack space, but by actual memory size, which will be like as much ram as you've got.

The innovative solution basically involves using either like a stack for Q and pushing cells onto that stack work you like.

You visit each cell and you take the four neighbors and percent wantto stack or cube, and you basically just pop them off the stack and you press is each one.

You take each one and you push therefore neighbors onto the stack again, and you just keep doing that until you hit every single cell.

And all the while you're making sure that you don't revisit cells that you've already seen.

And so this is the expansion of that problem and probably why you want to make sure that you have plenty of space on the white board you're gonna want inside the top left corner and just write in a small fund.

Not too smart, but not too big, either.

And give yourself some space between each line, in case you need to add statements between each line.

And what I like to do is, I'd like to make sure that I bring my own pen just so that I'm not stuck with like a bad penny, like just a red pen or like a pen that's out of ink like a like a big black panthers.