코딩 면접 전략: 계획, 마음가짐, 실행

### 코딩 면접에서 성공하기 위한 전략
* 🎥 코딩 면접 실력을 향상하려면 **좋아요를 누르고 구독하고 알림 벨**을 눌러 더 유용한 동영상을 확인하세요.
* 💬 인터뷰 중에는 **큰 소리로 생각**하고, 확실하지 않을 때는 인정하고, 침묵을 채우는 말로 채우는 대신 **생각할 시간을 요청**하는 것이 도움이 됩니다.
* 🔍 무차별 대입 솔루션으로 시작하면 비효율적이더라도 **문제를 명확하게 시각화**할 수 있으므로 사고 과정의 윤곽을 잡는 데 도움이 됩니다.
* 🏋 면접 준비와 신체 활동의 균형을 맞추면 **정신이 맑아지고 기분이 좋아져** 면접에서 더 효과적으로 임할 수 있습니다.
* 📝 코드를 여러 함수 호출로 구조화하면 **시간 관리에 도움이 될 뿐만 아니라 가독성이 향상**되고 나중에 **디버깅이 더 쉬워집니다.**
* 📊 문제를 해결할 때는 **질문의 성격을 이해**하고 에지 케이스에 대한 관찰을 수집하여 해결책을 찾는 데 집중하세요.
* 💡 면접관의 참여를 유도하고 협력적인 문제 해결을 가능하게 하려면 항상 **자신의 사고 과정을 면접관에게 명확하게 전달**하는 것을 우선시해야 합니다.
* 🧠 마지막으로, 면접 과정 내내 동기 부여와 정신 건강을 관리하는 것이 중요하므로 **균형 잡힌 생활**을 유지하고 면접 직전에 **벼락치기를 하지 않도록** 하세요.

면접관은 코딩 면접에서 불확실성을 인정하고 배우려는 의지를 보이는 지원자를 높이 평가합니다.

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

[Music] 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, and you're just staring at the problem. What do you do? The first thing I would recommend you keep in mind is to 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. You want to spend a lot of time there, 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? It is very difficult to multitask. 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? 'Cause 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 [Music] 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, pseudo-code 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. Write just 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 over-complicates 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 sounds very slow, that's n! 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 over-complicate 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 end log end time. I really don't see any reason why I would need to be slower than that. But then I start coding and I add a loop that changes it to N squ. 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 [Music] 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. 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 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 [Music] 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? Big O of N is a step up from n log n. What algorithms do I know already that fit linear time Big O of N? I know sliding windows generally Big O of N, and I know quick select is usually, and 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 pre-process 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 code 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 the 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 for search as it normally is, and we know that it works. The 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 [Music] 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 miss 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 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 Rod 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 on-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. But I would rather have an interviewer read this exact same problem, exact same solution, but it's more readable, and I feel less likely to mess

up the coding or have a logic error when the code looks like this. The function name tells you exactly what this does, and the variable names are descriptive. They tell you exactly what they mean, and the formatting of the code follows the actual logic. I want to finish off this video by talking about something that's extremely important, and it's probably the most underappreciated or neglected parts of this whole process. How are you yourself as a person showing up to this interview? How are you managing your motivation, your confidence, and your mental health throughout the interview process? It's a grueling process, not just the interview day, but the weeks or the months leading up to an interview. For me personally, as an example, let's say I have an interview coming up. I'll try my very best not to let this interview be the only thing I have going for me in my life. I'll try to keep up with the sport, keep going to the gym, make sure I'm socializing with friends, try dating someone new, try playing a video game, get

into a new show, right? If this is the only thing you're anticipating, it's going to put way too much pressure on it, right? I want to come into an interview feeling like, Okay, I would really like this job, but if I don't get it, I can walk away, and I'm doing fine. And that gives you confidence to be really self-assured during the actual interview. What kind of problems should you do leading up to the interview? This isn't super common advice that I've seen, but for me personally, for the last day or two days or three days even leading up to the interview, I want to steer clear of doing any ridiculously hard problems that I likely can't solve. I want to avoid doing really high-pressure mock interviews. Sure, maybe before that, for the weeks prior, I challenge myself, I do some crazy DP, some crazy graph reversals, but I don't want to walk into the interview on what feels like a losing streak. If I'm failing hard problem after hard problem after hard problem, then when I get a

problem in the interview. My first thought is I'm going to fail this like all the others, right? I try to go feeling like I'm used to handling whatever's in front of me. Another thing is you want to avoid cramming in the last 24 hours of the interview. Every second, every hour of studying does count, but in the last 24 hours, there are things that count way more. Let's say in the last day I cover an extra two or three or maybe four leod problems. That probably helped, but then I show up to the interview, my attention is a little bit scattered. I'm a little bit burned out. I'm a little bit tired or demotivated. My performance plummets. It's like I climbed two steps up the stairs and then fell down the staircase. But let's say instead I got a lot of sleep, took a nap if I needed to, had a video call with a friend, spent time on a creative outlet, I cooked a really nice meal that I like, and I'm feeling good.

what would you rather have: one hour to maybe cover one new le code problem before the interview, or get in a light to a moderate workout that's going to give you mental clarity, motivation, energy, stability in your mood, and so on, right? A lot of bang for your buck there. At the end of the day, coding interviews, they are just this arbitrary puzzle game. It's kind of like the SAT or the MCAT or the LSAT. It's not meant to be a perfect representation of how you are on a day-to-day basis on a job or on a project. Unfortunately, companies just need some way to interview people in a way that's practical for them, efficient for them, and standardized across people. And I guess this is the best way that people have come up with. So while this is the standard, I guess it is what it is. Got to do what we got to do. So thank you so much for watching. I hope you found this helpful. I had so much fun making

this video. Make sure to give this a like, subscribe, and hit the notification bell if you want to see more videos. And I'll see you in the next one. Good luck on your interviews.

How I Passed The Google Coding Interviews

Chris Jereza

코딩 면접에서 성공하기 위한 전략

연사는 Google의 모든 코딩 면접을 통과했지만 채용 동결로 인해 입사하지 못했습니다.

컴퓨터 과학과 소프트웨어 엔지니어링에 대한 탄탄한 배경 지식을 갖추고 있으며, 최고의 기업에서 인턴십을 거쳐 정규직 제안에 성공했습니다.

연사는 브레인스토밍 솔루션, 면접관과의 협업, 사고 과정 전달, 코드 구조화 등 코딩 면접을 위한 구체적인 전략을 공유하면서 테스트 케이스 작성과 런타임 최적화의 중요성을 강조합니다.

이 문제는 버스 정류장 그래프에서 폭 우선 검색(BFS) 방식을 사용하여 출발지 버스 정류장에서 목적지 버스 정류장까지 이동하는 데 필요한 최소 버스 수를 찾는 것입니다.

BFS 대기열은 문제를 효과적으로 해결하기 위해 정류장, 노선, 노선 간 환승의 조합을 추적해야 합니다.

또한 중복되는 회의를 관리할 때 힙을 사용하여 종료 시간을 저장하고 이전 회의를 제거하면 새 회의를 위한 회의실을 효율적으로 할당하는 데 도움이 될 수 있습니다.

면접 스트레스 및 문제 해결 전략 관리하기

면접 과정은 힘들 수 있으므로 이 기간 동안 동기 부여, 자신감, 정신 건강을 관리하는 것이 중요합니다.

스포츠, 사교, 취미 등의 활동으로 균형 잡힌 생활을 유지하면 면접의 압박감을 완화하는 데 도움이 될 수 있습니다.

코딩 문제를 풀 때는 패턴을 파악하고 접근 방식에 의문을 제기하며 솔루션의 비효율성을 파악하여 시간을 절약하고 결과를 개선하는 것이 중요합니다.

편안한 마음가짐으로 면접에 임하면 자신감을 높이고 부담감을 줄일 수 있습니다.

면접을 앞둔 며칠 동안은 어려운 문제나 압박감이 큰 모의 면접을 피하는 것이 연패를 방지하는 데 도움이 됩니다.

코드 가독성을 우선시하고 계획에 의사 코드를 사용하면 사고 과정을 명확히 하고 코딩으로 더 원활하게 전환하는 데 도움이 될 수 있습니다.

면접 전에 부담감을 느끼면 번아웃과 성과 저하로 이어질 수 있으므로 휴식과 자기 관리에 우선순위를 두는 것이 중요합니다.

코딩 중에는 멀티태스킹이 어려울 수 있으므로 자신의 사고 과정을 계획하고 면접관에게 전달하는 것이 중요합니다.

알고리즘에 맞게 데이터 구조를 수정하고 폭넓은 접근 방식으로 코딩을 시작하면 문제 해결력과 면접관과의 소통을 향상시킬 수 있습니다.

모르는 것이 있으면 인정하고 생각할 시간을 요청하세요.

비효율적이더라도 무차별 대입 솔루션으로 시작하세요.

문제를 여러 함수 호출로 분할하여 시간을 관리하고 코드 가독성을 개선하세요.