Name: Googleの模擬面接（ソフトウェアエンジニアの仕事のための） - コーディングとアルゴリズムのヒント (Mock Google interview (for Software Engineer job) - coding & algorithms tips)
Uploaded: 2021-01-14T10:17:04.000Z
Duration: 19 min 20 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

命令形

And welcome back to another episode of the T 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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

字幕リスト動画再生

Googleの模擬面接（ソフトウェアエンジニアの仕事のための） - コーディングとアルゴリズムのヒント (Mock Google interview (for Software Engineer job) - coding & algorithms tips)

basically

practice

tackle

impact