Name: コーディング面接のクラッキング（ソフトウェアエンジニアのための簡単な5つのステップで (Cracking the Coding Interview (in 5 simple steps, for software engineers))
Uploaded: 2021-01-14T10:17:43.000Z
Duration: 10 min 39 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

現在進行形

Hey, technique here am Welcome back to another episode Today we are drinking green tea with pomegranate and cranberry.

It's we intend you kind of like a Asian fusion mixture for people who can't truly appreciate really green tea and need that American sweetness to it.

Sort of like orange chicken or sushi with 1000 island dressing or any type of Asian food with 1000 island dressing today.

I wanted to give you five last minute tips for your technical coding interview, and this is about what you're going to be graded on.

And every technical interviewer is going to be watching you and evaluating you on five basic things.

And I think that if you were to nail these five things, you're gonna be go there now before we get started.

Do they were actually have a new and exciting sponsor?

They actually make coding interview videos that walking through entire sets of many coding interview questions and they make a ton of these videos you should check about algo expert I'll slash tech lead.

Okay, so the first thing that you're evaluated on is Cody coding is the primary thing.

You're gonna want focus on if your entry level engineer.

Generally, if you do a bunch of white board Cody and exercises, you go to lee co dot com and do a bunch of those coding exercises.

Then that should get you set up for the coding portion and won't make sure you're writing real code and the code looks good.

Each method argument is very clear, and each return value is clear.

It's not like Do you have a method that accepts five different parameters?

You know, you break it down and there's just sections for each one.

Many people come in, and they only writes you the code.

They can't turn that workers of function into a drawer function, and you won't remember that in.

The interviewers often would like to take a picture of the code that you write and then reference that in their actual feedback report for you, you know I like to do is bring a small marker pen, right and medium small fund.

Believe enough space between lines of code such that I can insert lines of code if I need to later on.

And just make sure that everything looks nice and neat.

Okay, so Number two the second thing we want to make sure that we're good on our data structures, and this is being able to have mastery of things like hash tables.

A raise linked lists, classes object or into programming accused stacks.

Using any of these types of data structures or mentioning them would get your points.

And it's important to also know their run times, you know, at the time of space analysis.

And if you could just mentioned these as you're going through them in your analysis, then that's going to be really great for you.

And that would make sure to try to find opportunities to just show off that you know, object or into programming, like even in the initial function that you may be creating.

You can put that inside the class, and that would just we need those extra points and the interviewer just feels a little bit more comfortable, more confident that you at least know some structures.

The other benefit of using O P is, unless you create instance variables, which are essentially global's.

But even though interviewers were generally frowned on you if you start using Global's, if you set that up using object, going to program and make him instance variables, then you're going to start looking good.

Actually, it may also help make your function signatures cleaner, because you may be able to find areas where you can remove certain variables from the method parameters and moved them into the instance parables instead over.

Although the more data structures that you could mention in your analysis, the more points you're going to be getting.

So one common pit far is you always want to be thinking about new data structures that you're creating new variables, especially heavy data structures like a raise, and you won't be thinking about if you really need that and what the cause of that are going to be.

And if you create this, is there a better way you can be creating that like, should it be a hash map?

Instead, you have to train yourself to really be careful any time you start creating a raise maitresse, sees factors, anything that takes the last space and just really take a look at that and think about it and think about if you really need that and if you can justify that, okay, the third thing that people are going to be looking for is designed.

And this is really something that comes more into play for senior engineers, and this has less to do with the actual solution of the problem, but rather how you came about reaching that solution and which alternatives you considered.

And so this portion about design, I would say, is really about alternatives.

How many alternatives did you think about how many did you propose?

Maybe if there's a recursive algorithm, why did you choose to do it that way?

If there's a trace of data structures, there's usually a tradeoff of time versus space.

Time versus space is always a trade off In software engineering, you can usually trade one for the other, and the design portion is about being able to analyze that and explain you know you want faster time or do you want faster space?

Which they, the structures would leave youto one or the other?

Generally, you're goingto one pick the one with faster time.

There may occasionally be more design oriented interviews where there's less Cody, and that's it.

No, it could be about the Sanya entire system or architecture and figuring out how many different pieces of code may interact together.

And my recommendation for this is to always think about data flow.

What other objects in your system how did they communicate between one another?

You know, if you have, like, five objects, how are they communicating with each other?

It's just spaghetti communication, and everyone's communicating with each other.

That's going to be a mess, is going to be even bigger mess once you have 50 objects or 500 objects.

If you sense that design or into question coming your way, you may want to start buzzing out those software design patterns.

I made the video about that so you could check it out if you like, but you can start mentioning patterns like Mount a few controller Singleton's observers establishing a cleaner, one way data flow.

I would say that design also encompasses proper understanding of big O time space analysis, and you absolutely have to know this.

The funny thing is, most people no big toe time space analysis you give them enough time, and they can slowly stumble upon the answer after one or two failed attempts, you know there's only so many different ones.

There's, like constant time Lin, your time log rhythmic explanation show quadratic something like that, and you give people five guesses and they'll figure one that it's really about having mastery and fluidity.

So if you know the answer and usually I think the answer isn't that hard to find, like if it's the op tomorrow, rhythm is probably gonna be Lynn your time or something like that.

If you know the answer just mentioned it.

If you could do it quickly and confidently, that'll just get you more points.

You want to make sure that you're communicating effectively.

I think this comes into play in two areas.

The first is when you're talking about yourself, your prior projects your experience you want.

Make sure you don't lose the interviewer.

And just if you can explain what you did and not lose the interviewer and grasp but their attention while you're explaining it you want.

Make sure that you're explaining clearly and you're checking the interviewers or actions.

If you can do this effectively than that's already going to get you big points here the second portion, maybe in explaining the arbor them that you may have written at the end.

You know, I would think carefully about if you want to be talking while you're writing code, you want to explain some of it.

But if your writing and your friend to talk at the same time, at least for me, I find that it's difficult for me to speak fluidly if I'm trying to write at the same time.

Well, I like to do is explain what I'm going to do.

Write the code, right a few things, then talk about it and then go back to writing.

But I wouldn't necessarily do it all at the same time.

And that the fifth thing that people look for which I think a lot of candidates forget or don't pay attention to this speed and efficiency, speed and efficiency is really what separates the top tier candidates from the mediocre candidates.

Because the fact is, I think many people will be able to ultimately solve a problem, solve a whiteboard in problem, even get the answer, even be able to analyze it.

You want to make sure that if you know the answer, just solve it, solve it quickly, blow the interviewer away, and you may be surprised to find that the problem that they asked was only the beginning of a problem.

And there were two or three additional advanced stages to the problem.

You just get as far as you can around the problem.

And don't underestimate the problem is as simple as it seems and that you can just take all the time you want are too often I would see candidates start working on the edge case some useless function or something like that, and they'll just spend tons of time trying to write the code perfectly and you know, they focus almost too much on the coding portion, and they want right every single semi colon, every single variable.

And they have really long, variable names, and they think it's going to make their coat look beautiful.