코딩 면접 준비: 마스터해야 할 주요 평가 영역

### 최고의 기술 기업에서 코딩 면접을 통과하기 위한 필수 팁
* 👋 이 동영상은 **구글, 페이스북, 아마존 등 주요 기술 기업에서 코딩 면접**을 준비하는 분들에게 양질의 정보를 제공하기 위해 제작되었습니다.
* 📚 면접 과정의 기본이 되는 알고리즘과 데이터 구조부터 시작하여 **면접에서 지원자를 평가하는 6가지 주요 영역**에 초점을 맞출 것입니다.
* ⏳ 코딩 면접은 일반적으로 **약 45분간 진행**되며, 지원자는 데이터 구조를 효과적으로 활용하여 개념적, 프로그래밍적으로 접근할 수 있는 문제를 해결해야 합니다.
* 🧠 응시자는 많은 문제를 무작정 풀기보다는 **최적의 솔루션을 이해하는 '스마트한 연습'**을 해야 좋은 성적을 거둘 수 있습니다.
* 📈 복잡성 분석, 특히 **빅 O 표기법**은 응시자가 시간과 공간 복잡성과 관련하여 솔루션의 효율성을 논의할 준비가 되어 있어야 하므로 매우 중요합니다.
* 💻 코드 품질은 면접에서 평가하는 또 다른 중요한 측면으로, 지원자는 자신의 코딩 기술을 보여주기 위해 **깔끔하고 설명이 명확하며 자명하게 코드를 작성**하는 데 집중해야 합니다.
* 🗣 면접에서 의사소통은 매우 중요하며, 지원자는 **자신의 사고 과정을 명확하게 표현**하고, **명확한 질문**을 하며, **문제 해결 능력**을 보여줄 수 있는 접근 방식을 요약해야 합니다.
* 🌟 마지막으로, 지원자는 **팀워크, 갈등 처리, 회사와 그 가치에 대한 진정한 관심** 등 회사가 평가하는 문화적 적합성 또는 '구글스러움'에 대해 알고 있어야 합니다.

지원자는 알고리즘, 데이터 구조, 효과적인 커뮤니케이션을 숙달해야 코딩 면접에서 뛰어난 역량을 발휘할 수 있습니다.

what's up, everybody? How's it going? This video is gonna be a very high-quality, high-information video. If you're preparing for your coding interviews, especially at Google or any other big tech company, like, for instance, that one big tech company that starts with F and rhymes with look, or that other big tech company that starts with A and rhymes with on, or that other big tech company that starts with M and rhymes with wits, you get the idea, or any startup like Robinhood, Stripe, Airbnb, any tech company. If you are preparing for your coding interviews, watch this video from start to finish. You're gonna be able to get some valuable information, even if it's stuff that you've already heard. I think that the repetition and hearing it again is gonna prove to be very useful, and you might be able to get a nugget of wisdom that makes the difference in that coding interview and lends you example in

this video. I'm gonna be covering the six most important things that you're being assessed on in these coding interviews, and that you really need to focus on as you're preparing for the coding interviews. And so, without further ado, give this video a pre-emptive smashing of the leg button. It's not for the content of the video, for my haircut, or for my beard trim. And let's dive into it. And by the way, I decided to hide a magic trick in the middle of this video instead of at the start of the video. That way, if you want to see it, you're gonna have to watch the whole video. So, the first thing that you're gonna be assessed on in these coding interviews is gonna be algorithms and data structures. Now, this should come as no surprise to those of you who are already familiar with these coding interviews, because algorithms and data structures are really the bread and butter of these coding interviews. Think of it as the thing that you're really being tested on at heart, the content of the interviews.

Now, let's take a small step back. These coding interviews tend to be conducted in 45-minute honks, meaning you have multiple back-to-back interviews if you're on-site, or maybe if you have a phone interview, it's just one phone interview that takes about 45 minutes. In that interview, you, the candidate, are being given a problem or maybe a couple of problems that you have to solve in those 45 minutes. These problems are kind of like puzzles, not brain teasers; do not confuse them with brain teasers, but they're sort of like puzzles that can be solved both conceptually and programmatically, and that's really important. These problems could actually be solved conceptually by someone who doesn't know programming, who doesn't code, but then you not only have to do that; you also have to transcribe your solution into code. A good example of these algorithm problems that you're gonna be given is, imagine you have a list of numbers as well as an integer k, and you have to find the k-th largest.

number in that list. That's a very simple problem, seemingly simple, that someone who doesn't code would be able to solve conceptually. But you have to not only do that but also transcribe it into code. And to do that, you're gonna obviously have to use data structures. Data structures are kind of like the tools that you can use to solve these problems, to implement an algorithm that solves these problems. Now, there are a lot of algorithms and data structures out there. For instance, sorting algorithms, searching algorithms, recursive algorithms, greedy algorithms, divide and conquer algorithms, algorithms that lend themselves to dynamic programming. For data structures, you've got heaps, graphs, trees, linked lists, stacks, hash tables, strings. The list goes on and on, and it's extremely important that you be intimately familiar with these various algorithms and data structures. And on top of that, that you'll be able to recognize very quickly the common patterns that are present in these algorithm questions, so that you can immediately figure out what type of algorithm or what data structure you might need to use to solve the problem.

Now, obviously, you might be wondering how do I do this. This sounds like a lot of stuff. How do I become good at it? And the answer is actually surprisingly simple: smart practice. Coding interview problems and specifically algorithms and data structures is something where the proverb practice makes perfect really, really applies. The more practice coding interview questions you do, the better you will be in the coding interview room. Now, the one caveat, which I hinted at a few seconds ago, is that practice alone isn't actually the answer. You have to make it smart practice because there's a type of practice that might actually be counterproductive. You have to practice in such a way that you understand what the correct or rather most optimal solution to the problem is. And we're gonna get to that a bit more into the second tip or thing that you ask to know for coding interviews. But what that means is that you can't just blindly do a billion questions without actually knowing if what you're doing is the best way to do it. There are a lot of problems.

that you might be able to solve, but if you don't learn how to solve them the best way, then it's not gonna do that much for you. Of course, this is where I'm gonna recommend I'll go expert, my company, my product. I'll go expert. Do we give you a curated list of some of the best coding interview questions? And for each question, you can do the problem, actually code it out in your language of choice, and run it against our pre-made test cases on our full-fledged coding workspace. But the key thing is that for every question, we give you a video explanation, a very comprehensive video explanation. And that's the most important part because even those questions that you think you solved because you passed all the test cases, you want to make sure that you watch those videos to see what other things did you not think about. Do you have the best solution, the most optimal one? Is there another way to solve the problem that you may not have thought about? This is the stuff that's going to be super

important now on the platform. We have a video in the interview tips section that explains exactly the best way to use the platform, how to time yourself, how to mimic the coding interview environment. So definitely watch that. It's totally free on the platform. But I would definitely recommend Algo Expert. Now, I want to make something clear here. Of course, I'm recommending Algo Expert because it's my product, and I'm a little bit biased from that point of view. However, based on the feedback that we've been receiving lately, I genuinely believe that Algo Expert is the best tool out there that you can use to prepare for your coding interviews, especially for the algorithms and data structures portion of the coding interviews. This week alone, we've received such amazing feedback, unsolicited feedback, from a bunch of people who've used Algo Expert and attributed it in large part to acing their coding interviews and landing their dream jobs. We had someone who got a Facebook internship as a software engineer, someone who got a full-time software engineering position at Google.

another person who got a position at Oracle. It's been awesome, and it's really convincing me more and more that algo exper is the best tool for the job, or rather to land the job out there. And if you do decide to buy algo expert, use the promo code cleanse, CL-E-M, for a discount on the platform. But to some of that first point, smart practice for algorithms and data structures. The second thing that you're being assessed on in the coding interviews and that you need to prepare for is going to be complexity analysis, big O notation. This one is very much related to the previous point of algorithms and data structures. Once again, let's take a step back for a second. When we're dealing with these coding interview problems, it's not at all unreasonable to assume that there are going to be multiple ways to solve the same problem. But so then the question becomes, what makes one way better than another way? And that's where complexity analysis comes into play. Now in an actual coding interview, this is gonna manifest itself when you actually

find a solution to the problem, and your interviewer asks you the infamous question, Can you do better? This question is a facade; it is a simplified way of asking you what is the time complexity of your algorithm, what is the space complexity of your algorithm. In other words, what is the complexity analysis of your algorithm, of your solution, and can you come up with a solution or another algorithm that has a better time complexity or a better space complexity. Super quick recap on complexity analysis for those of you who aren't familiar with it: when we talk about the time complexity of an algorithm, we're asking how fast does that algorithm run with respect to the input. For instance, if you've got a gigantic input string or a gigantic input list of integers, how does that affect the speed of your algorithm? And space complexity is exactly the same thing, except here we're talking about the amount of auxiliary or extra memory that your algorithm is going to take up with respect to the size of the input. Okay, so what does this mean? It means that you

need to be very familiar with complexity analysis implications of your algorithms and of your data structures. You need to know things like how fast it takes to look up a string in a tree. You need to know how fast it takes to print a bunch of numbers in a list. If you're using a double for loop, you need to know how fast a depth-first search takes. All these things you need to know, and what that translates into as far as practice is concerned is that for every single problem that you do, you should really focus on the complexity analysis of your algorithm when you're trying to solve it. And then you should really try to understand why the optimal solution might be better from a complexity analysis point of view. Now, of course, again here, I'm gonna plug in algo expert. For every single question in our video explanations, we cover in depth the time complexity and the space complexity of the algorithm of the solution. We don't let anything be ambiguous or unclear. So here, I'll go expert on i/o. You get the

idea at this point. The third thing that you're being assessed on in coding interviews, and that you need to prepare for, is your code. This one should come as no surprise to anybody because it's a coding interview, so your coding skills are gonna be tested. Now, the interesting part here is that people who are otherwise really good at some of the other parts of the coding interview, like algorithms and data structures and complexity analysis, might not be super good at the coding part. The person that comes to mind here is the competitive programmer or maybe the PhD student. People who are really good at these other parts but who might not be super great at the actual coding part because they have been doing things in an environment that doesn't test them on the same parts of coding. A competitive programmer is working under time pressure, where all they care about is getting an algorithm that runs in a certain time, so they really care about the complexity analysis of their algorithm, but they don't have a human being actually reading their code and assessing the quality of their code.

Although they care about is that their code passed the test cases really quickly. Similarly, a PhD student might be really good at the theoretical parts of computer science or whatever discipline they concentrated in, but they might not have as much experience writing actual quality code. Now, some of you might be thinking, but wait, Clemmons, how the heck do you assess code quality in a 45-minute interview on a puzzle-like problem like coding interview problems? Well, you'd be surprised how much signal an interviewer can actually get as far as your coding skills are concerned in these 45-minute interviews. And the key thing is that you be aware of this signal that they can get and that you really focus on getting your code up to par such that you send positive signals with regards to your coding skills. There are basically a bunch of really simple things that you can do to demonstrate that your coding skills are up to par. The first and perhaps easiest thing that you can do to improve your coding skills in a coding interview is to name your variables descriptively. It's so easy to

do basically don't give your variables one-letter names or don't name your variables things like array or string unless really the question lends itself to that. Like if the question were just to sort an array of numbers, then perhaps you could name the variable array. But if the question is dealing with something like an array of grades for an array of people, then name the array grades or people. It's just gonna go a long way to show your interviewer that you know what you're doing and that you can write quality and readable code. The second really easy thing that you can do in your coding interviews for your coding is abstraction. Basically, create helper methods for parts of your code that lend themselves to helper methods. If you have a piece of code in your algorithm that's gonna repeat itself or that's sort of like a clear separate action in your code, make a helper method out of it. That's the kind of thing that's very simple to do, and it's gonna make your code a little bit cleaner, and it's gonna send positive signals to your

interviewer that your code is good in general. A couple of things that you can keep in the back of your mind as you're writing your code in these interviews is, number one, is your code dry, which stands for do not repeat yourself. And if it's not dry, if you're repeating a bunch of logic multiple times, make sure to use those helper methods I was talking about a second ago. And number two, you aren't gonna need it. Don't write stuff in your coding interview that you're not gonna need. You'd be surprised how many people write stuff like a function where they just say to the interviewer, Hey, I'm writing this function out because we might need it later, and then they end up not needing it, and it's just like distracting from the interview, and they wasted their time, and it's also just a poor coding practice. You don't want to write code that you're not gonna use just to have it there in case it's needed in the future. Another thing that you can do is to document

your code, even in a coding interview. So, for instance, if you've got a complicated function that might not be self-descriptive, you can add a very short comment at the top just explaining what the function does or what a piece of logic does. That could always send a little positive signal to your interviewer. However, and here I want to give you a very good piece of advice, you may have noticed that I just said if the function is not self-descriptive. You should actually try to make all of your code as self-descriptive as possible. So, a little hack that I'll give you here, this is something that I give to everyone who asks me for coding tips, especially for coding interviews, is if you ever deal with a piece of logic in your code that it's kind of complicated. The canonical example that I would give here is imagine you've got an if statement, and the condition in your if statement is something kind of tricky, like if a number is divisible by two and it's in between two other numbers, which is something that doesn't necessarily

mean much instead of adding a comment right above that if statement and the candy explaining what the condition is, which would be a decent thing to do. You can literally declare a variable above the if statement that says something like should do this equals the condition, and then you say if should do this blah blah blah else blah blah blah. In other words, you can avoid documentation altogether if you write your code in such a way that it is self-descriptive, and oftentimes you can do that by just creating variables that describe your code. Because someone reading it is gonna be reading that variable name, and this can be like, Okay, I understand what this is doing, and you're gonna be much better off. These are all a bunch of little techniques that are gonna really go a long way to send those positive coding signals to your interviewer. And the last thing that I'll say here is make sure that you focus on writing quality code during your interview prep, during your practice. If you're using Algo Expert, for instance, write quality code as you're doing the problems on Algo Expert. Don't

just say, Oh, here I'll write single letter variables because I'm just practicing. No, because the day of the interview when you're gonna be stressed and you're gonna be under time pressure and really it's gonna matter, you want to have that sort of muscle memory of writing quality code ingrained in you. Seriously, if you don't write high-quality code while you're practicing, I'm not gonna be happy, and you won't like me when I'm angry. Oh, and one more tip for your coding skills: a good way to know whether or not you're writing quality code when you're preparing for your coding interviews is to either one, go back to an old piece of code that you wrote, let's say two weeks ago on a coding interview problem, and see if you can actually get what you wrote. That's gonna actually tell you whether or not that code was pretty good or written pretty well. And two, ask one of your friends, someone who's into coding, to read your solution to a problem without giving them the prompt of the

problem and to see if they know what's going on, if they can at least kind of figure out what the problem is just by reading your solution, and that's probably an indication that your code is pretty good. If they can't figure out anything, then either it means that they're [ __ ] or, more likely, it means that your code could use a little bit of improvement. Okay, the fourth thing that you're being assessed on in a coding interview and that you really need to prepare for is your problem-solving ability. Algorithm problems are a really good way to test someone's problem-solving ability. I realize that this is a contentious topic, that some people might disagree with that statement, but for the sake of this video, just accept it. This is the premise that big tech companies and startups are operating under when they give you these algorithm problems for coding interviews. They assume that these algorithm problems are a good way to test your problem-solving ability, so just accept that as a truth. And so, the key thing here is that you want to demonstrate to

your interviewer that you are a good problem solver, someone who has great problem-solving ability. By the way, why is this important for these companies? Because when you're gonna be a software engineer on the job, your job is literally gonna be to solve problems. You're gonna be given problems like, for instance, build this user interface, or build this API, or figure out why this is buggy, figure out how to improve the performance, and you're gonna have to solve these problems. Now, how do you convey that you are a good problem solver? Well, here are a few things that you can do in your coding interviews to convey just that. The first thing, which is so, so, so important, is to ask clarifying questions at the beginning of your interview. Coding interview questions are oftentimes purposely ambiguous. So, for instance, your interviewer might give you a list of numbers and ask you a problem with that list of numbers, and it is your job to start the interview by asking them a bunch of clarifying questions. This is not only going to be very helpful to you because

Sometimes you need to know extra information that they haven't given you to solve the problem correctly. So really, it's gonna be really helpful for you, but also it's gonna demonstrate to them that you are a good problem solver. So if we take the example of the list of numbers, well, are we dealing with integers or are we dealing with decimal numbers? Are we dealing with purely positive numbers or can we have negative numbers? Is it possible that we'll be given bogus inputs without numbers or we're only giving numbers? Is the array ever gonna be empty or is it not gonna be empty? You get the idea, there are tons of clarifying questions to ask. Make sure that you ask them. This is probably the easiest way for an interviewer to get a sort of bad signal from you if you don't ask any clarifying questions. I'm not saying that this is a hard and fast rule where if you don't ask questions, the interviewer is immediately gonna be like terrible problem solver, but it is something where the interviewer will

most likely be like okay, so this candidate assumes that they have all the information they need, and really, most problems, there will be extra information that you're missing. So, please ask clarifying questions. And the second thing that you can do is to come up with a strategy that is logical and sound on how you're gonna solve this problem. Does the problem ask two different questions that can be tackled separately? For instance, find the subsequence in an array that sums up to the greatest value. This is a question that actually has two implicit questions: find the maximum sum that you can get from a subsequence in the array, and then find the actual subsequence. And it might make sense to tackle one of these sub-questions before the other. Another thing that you could ask yourself is, can you divide this problem into a bunch of subproblems? Typically, this is the kind of thing that you can ask yourself when you're faced with a problem that lends itself to dynamic programming. Another question to ask yourself is, is there a very obvious naive solution to this problem that we

can maybe start by doing, and that might give us hints as to how to solve the problem more optimally, or is this a different type of problem. There are a lot of ways that you can go about tackling a problem, and it's important for you to think about all these different strategies and to vocalize them to tell your interviewer that you are a good problem solver. Then you can actually implement your algorithm or your solution to the problem in an organized manner that shows that you're logical and consistent. And finally, make sure that you test your solution. Make sure that you think about what kinds of inputs you would use to test your solution. This is the kind of thing where being proactive about testing is gonna really convey to your interviewer that you're a good problem solver and just a good software engineer in general, because testing, as you probably know, is super important in software engineering and especially at Google. The fifth thing that you're being assessed on in coding interviews, and this is probably my favorite one, it's one that can actually make or break you.

in a coding interview, and it's communication. You can be the best person at algorithms and data structures and have perfect code, but if you're a terrible communicator, you may very well mess up the interview and not get an offer. Similarly, if you're not amazing at algorithms and data structures, and in your interview, you don't do super well in that regard, your code isn't necessarily the best code, but you are a fantastic communicator. That may very well put you above the line and get you an offer and that dream job. So, make sure that you keep communication in mind in your coding interviews. So, how do you demonstrate great communication skills in an interview? The key thing, and this really shouldn't be a surprise, is that you have to talk. You have to vocalize all of your thoughts, anything that you're thinking about or debating about in your mind. You want to vocalize and let your interviewer in on. So, for instance, if you're comparing two different data structures, like you're thinking, Hmm, should I use an array here?

or a heap vocalise it. Tell your interviewer that you're thinking about these things. Tell them why you're debating between these two things. If you're considering going with one approach or another approach, like maybe a recursive solution or an iterative solution, tell your interviewer you want to keep your interviewer in the loop. This is really gonna help because it's going to show that you're a good communicator, but also it's gonna make sure that your commute, that your interviewer is not confused throughout the interview. One of the worst things that can happen in an interview is when your interviewer is really confused and has no idea what you're doing, and typically that happens because you're not communicating, and they just start to try to make guesses about things. Like they're saying, Hmm, that person didn't use this data structure here, and I guess I'm gonna guess it's because they don't know about it, or No, they'll make assumptions because you're not vocalizing your thoughts, and that can really be bad for you. I really want to hammer in this.

point because it's so important. You want to make sure that your interviewer is always aware of what's going on in your mind. So, for instance, if you're taking a lot of time trying to come up with a solution, because you know sometimes you have to take a bit of time to figure stuff out, make sure that you give your interviewer a few signals of what you're thinking about. You want them to know where you're at in the problem. Otherwise, they're just gonna assume that maybe you're stuck, and they're gonna give you a hint even though you actually don't need a hint yet. It's super important that you not assume that your interviewer knows why you're doing something because they don't, or they are trained to not make these assumptions, or sorry, to not like give you the benefit of the doubt because they shouldn't give you the benefit of the doubt. They're there to make sure that what you're doing is good, and you have to prove that what you're doing is good. You have to convey to them

all the reasons that you're doing certain things now, which is great about communication, is that it can also help you in cases where you really are stuck. So, for instance, imagine that you're twenty-five minutes into an interview. You've done a lot of thinking, you've explored a few different options, and you're at the end of your solution, but you're stuck for whatever reason. You don't really know how to get to that final part to actually returning the correct answer. A great little communication technique that you can use here is to summarize everything that you've done out loud. Make sure that you vocalize it. You know, for instance, you can say, Okay, so we started by doing this. Then we sorted the input. Then we considered either using a heap or an array. We ended up going with the array because it was simpler for x, y, and z reasons. And then we're here. We did this loop, and now for whatever reason, I'm actually kind of stuck because I don't know how to get from there to the answer.

We seem so close, yet I'm not sure how to get to it. Does that make sense? You know, you ask your interviewer, Does that make sense? and this is great for many reasons. First of all, it recaps everything. If your interviewer was a little bit lost, now they're no longer lost. It shows to them that you've really thought about all these different things, and it kind of implies that you're asking for a hint. And you know, they should know when to give you a hint, but it might remind them that, Hey, this might be a good time to give you a hint. And also, it might be that you actually just did a silly mistake, you know, the kind of mistake that everyone can make, like you did two plus two equals five instead of four, the kind of mistake that no good interviewer would penalize you on. And if you actually did do a silly mistake like that, they'll be like, Okay, this person has all the sort of logic and things that we're actually assessing them on correct. They just made a dumb mistake.

I'll tell them what the mistake is, and we can move forward. If you didn't go through that, you know all the thought process that you did and everything. They might assume, Hey, does this person like a big gap in their logic, and they just don't get what they did? You know, they'll make assumptions; they won't give you the benefit of the doubt that you've just made a silly mistake of two plus two equals five. So, this is a great communication technique that you can use if you're genuinely stuck in the interview. Communication is super important, and it also goes hand in hand with problem-solving. It's a great way, perhaps the best way, to demonstrate to your interviewer that you are a great problem solver. And by the way, this is why I would highly recommend, if you're given the option to use a laptop during your interview, which at Google you should be given that option, I think, unless there's an exception. These days, Google offers you the option to have a laptop during your interviews and to actually cut out your solute.

On the laptop, I would definitely take it. Why? Because I think most people find it easier to type out their solution on a laptop than on a whiteboard. If you don't, then fine, but if you do, then grab the laptop. But then use the whiteboard to put all of your sort of conceptual thoughts and all the tests that you're doing and everything there and communicate that, and then use the laptop just to solve the problem and type it out. So, I remember what I did in my interview is that I would type out my stuff on a laptop, then in the middle of typing stuff, I take a pause and be like, Wait, let me go back to the whiteboard here. We considered using a heap, but... and that would work because of this, But wait, let's try it. What happens if we put a number there? Okay, let me type out this solution. Wait, wait, going back to though the point is like you can use a laptop and a whiteboard together with communication to really give you an edge.

In your interview, last little note about communication. I realize that I, for instance, am a very bombastic communicator. I tend to talk very loudly with big gestures and all of that. That does not mean that interviewers in a coding interview are assessing you on that. It doesn't mean that if you're not a bombastic communicator or someone who talks very loudly that you're gonna fail in the communication aspect. No, not at all. Some of the best communicators that I've met are people who were actually very light speakers, didn't talk super loudly, weren't over-the-top, and they were just very clear, very concise, very logical, and they just vocalized their thoughts. So again, if you're someone who's a bit more reserved and you think that there's gonna be some sort of bias against you as far as communication goes, that's not true. And in fact, sometimes the other types of people, people kind of like me who are more, you know, more gestures, louder and everything, sometimes they can

actually be bad because you don't want to be communicating just for the sake of talking, right? You don't want to be saying like a bunch of [__]. You want to be using your communication for an actual reason. The sixth and final thing that you're being assessed on encoding interviews, and then you have to prepare for, is a little bit more nebulous nuance than the other things, and to be honest, has got a few different names. Some people like to call it culture fit, other people like to call it just personality. Google calls it googliness and leadership (GNL). They actually introduced a brand new type of interview, googliness and leadership interview, about a year ago, where I think if you're interviewing as a software engineer, you will get a googliness and leadership interview in your slate of interviews. Some other companies, big tech companies, like to include this in one of their coding interviews, so they'll have one of their coding interviews that's half focused on this, on behavioral type of

questions and half of it that's just a coding interview. But the point is, you need to be aware of that. First of all, there are a few things that you really want to avoid. These are the kinds of things that can just eliminate you right off the bat. So, for instance, don't be arrogant, don't be an [__] or a jerk, don't be offensive in your interviews. Really, these should be no-brainers. Like, if you say something offensive in one of your interviews, I don't know what to do to help you. But then, the main thing that you want to convey in your interviews is that you are a smart and capable person who would make for a great co-worker. And the way that these companies are gonna assess that is through behavioral questions. So, the types of questions that you can expect are things like, Tell me about a time that you had conflict in a project and how did you handle it? or Tell me about a time that you had a very successful project. How do you measure the success?

of that project and how do you know that you yourself contributed to the success of that project or maybe it'll be something like tell me about a time that you didn't meet a deadline for a project how did you handle that how did you deal with it how do you correct it later on there are lots of different kinds of behavioral questions that these companies can ask and by the way we're really working on adding behavioral questions to algo experts you can really practice but I honestly think that these behavioral questions aren't too difficult the main thing that you need is to be very familiar with everything that's on your resume any past work experience or project experience that you might have you need to be able to answer questions that might ask you about them so know things like what you did on the project exactly the rule that you had on the project prepare answers for things like did something bad happen with the project or did something really good happen with the project be able to sort of give non-superficial answers to those types of

questions again. At the end of the day, your interviewers don't really care about the content of your answer, if that makes sense. They don't really care that you tell them, Oh, the project generated two million dollars in revenue for the company, versus, Oh, the project generated twenty thousand dollars in revenue for the company. That doesn't really matter. What they're assessing you on is more how you, as a software engineer and as a co-worker, dealt with things as part of the project, and is that the kind of thing that would make you a good coworker, one that they would like to work with. For smaller companies and startups, I think that this idea of culture fit or of, you know, googliness, which has obviously related to Google specifically, but I think that this is a bit different for smaller companies and startups. For those types of companies, I think that it's very important that you do research on the companies, that you really convey a genuine interest in the companies, because if you're applying to a 10-person blockchain company, it's

probably gonna be very important to them that you be interested and perhaps even very knowledgeable in blockchain. Similarly, if you're applying to a five-person start-up, it's probably important that you read their About the Team page and that you make sure that your sort of personality or principles match theirs. Otherwise, even for you, it's not gonna be a good thing, and this is the kind of thing that they might put emphasis on in their interviews. As a final note on this point, I think that I had read in an article or research paper on this topic that people who are able to fake this part of the interviews, behavioral types of questions, I think that there's apparently a positive correlation with people who are able to fake it and performance on the job. In other words, if you are able to kind of fake your way through these questions, that is actually not necessarily bad, in my opinion, an indication that you are a very, very cognitively capable person. So take that for what it's worth. I'm not gonna give

any advice here, but you have the information that's gonna be it for this video. And if you made it this far, you truly have all the information that you need to ace those Google coding interviews or the coding interviews that any other big tech company or startup. And if you found this video helpful or informative, as always, smash the like button and comment down below what you thought about it. It really helps with the YouTube algorithm and helps get this video more exposure and views. If you think that anybody else would find it helpful, make sure to share it to them. I would really appreciate that. These videos take a lot of time to make, so I would really appreciate that in return. And with that, I will see you in the next video.

How To Ace The Google Coding Interview - Complete Guide

Clément Mihailescu

코딩 면접의 성공을 위한 핵심 요소

대기업의 코딩 면접은 주어진 문제를 해결하는 데 중요한 알고리즘과 데이터 구조에 대해 지원자를 평가합니다.

이러한 면접은 일반적으로 45분 동안 진행되며 개념 및 프로그래밍 문제 해결을 포함합니다.

코딩 면접 문제를 마스터하려면 단순히 많은 문제를 풀기보다는 최적의 솔루션을 이해하는 데 중점을 두고 현명한 연습이 필수적입니다.

코딩 면접 준비하기: 핵심 전략

코딩 면접을 위한 현명한 연습에는 코딩 문제를 풀고, 원하는 언어로 코딩하고, 다양한 접근 방식을 이해하기 위한 포괄적인 동영상 설명을 시청하는 것이 포함됩니다.

시간과 공간의 복잡성을 포함한 복잡성 분석은 알고리즘과 데이터 구조의 효율성을 평가하는 데 매우 중요합니다.

Algo Expert는 엄선된 코딩 문제 목록, 동영상 설명, 복잡도 분석에 대한 심층적인 내용을 제공하므로 면접 준비에 유용한 도구입니다.

코딩 능력은 코딩 면접에서 매우 중요한 부분이며, 지원자는 다른 분야에서는 뛰어나지만 코딩에 어려움을 겪을 수 있습니다.

설명적인 변수 이름 지정, 헬퍼 메서드 생성, 불필요한 코드 피하기는 코딩 능력을 보여줄 수 있는 핵심 전략입니다.

또한 코드를 문서화하고 자기 설명적으로 작성하면 면접관에게 긍정적인 신호를 보낼 수 있습니다.

의미 있는 변수 이름을 사용하여 자기 설명적인 코드를 작성하면 문서화할 필요가 없습니다.

면접을 준비하는 동안 고품질 코드를 연습하는 것은 기억력을 키우는 데 매우 중요합니다.

면접을 시작할 때 명확한 질문을 하면 문제 해결 능력이 뛰어나다는 것을 보여주고 문제를 효과적으로 해결하는 데 필요한 정보를 수집하는 데 도움이 됩니다.

코딩 면접에서 문제 해결을 위한 효과적인 전략

응시자가 중요한 정보를 놓치는 경우가 많으므로 명확한 질문을 하는 것이 중요합니다.

문제를 하위 질문과 하위 문제로 세분화하면 보다 논리적이고 체계적인 접근이 가능합니다.

생각과 결정을 말로 표현하는 것은 면접관에게 정보를 제공하고 참여를 유도하는 데 도움이 되므로 면접 내내 효과적인 의사소통이 중요합니다.

면접에서 커뮤니케이션의 중요성

면접 중 효과적인 의사소통은 면접관에게 지원자의 사고 과정을 전달하는 데 매우 중요합니다.

구두로 신호를 보내고 자신의 행동을 요약하면 면접관이 진행 상황을 이해하고 필요한 경우 도움을 제공할 수 있습니다.

면접 중에 노트북을 사용하는 것도 문제 해결 능력을 보여주고 해결책을 제시하는 데 도움이 될 수 있습니다.

면접에서 노트북과 화이트보드를 효과적으로 사용하기

솔루션을 타이핑할 때는 노트북을, 개념적인 생각을 정리할 때는 화이트보드를 사용하면 면접 시 커뮤니케이션을 향상시킬 수 있습니다.

효과적인 의사소통을 위해서는 현란한 스타일이 필요하지 않으며, 명확하고 간결하게 생각을 표현하는 것도 마찬가지로 중요합니다.

회사는 행동 질문을 통해 지원자의 적합성을 평가하므로 훌륭한 동료가 될 수 있는 똑똑하고 유능한 인재임을 전달하는 것이 중요합니다.

행동 면접 질문은 과거 프로젝트 경험과 지원자가 문제를 어떻게 처리했는지에 초점을 맞추는 경우가 많습니다.

이력서를 숙지하고 자신의 역할과 프로젝트에 미치는 영향에 대한 질문에 대한 자세한 답변을 준비하는 것이 중요합니다.

소규모 회사나 스타트업의 경우, 진정한 관심을 보여주고 회사의 문화와 가치에 부합하는 모습을 보여주는 것이 중요합니다.