지원자 인터뷰 기본 코딩 능력에 대한 도전

### 기술 면접의 어려움: 개인적인 성찰
* 🤔 기술 면접을 진행하다 보면 많은 지원자가 기본적인 코딩 개념에 어려움을 겪는 경우가 많아 **양측 모두에게 35분이라는 긴 시간이 소요되는 경우**가 많습니다.
* 💬 저는 지원자들에게 힌트를 제공하고 코드를 연습할 수 있도록 격려함으로써 지원자들을 돕고자 했지만, 이러한 접근 방식은 **제가 진행한 면접에서 거의 아무도 합격하지 못하는 결과**를 낳았습니다.
* 🔄 면접관은 때때로 의도치 않게 **지원자를 다른 방향으로 몰아붙여 지원자의 주의를 분산**시킬 수 있으며, 이는 지원자의 사고 과정을 따라가는 데 방해가 될 수 있습니다.
* 📚 면접 교육이 현저히 부족하여 많은 응시자가 기본기를 먼저 익히지 않고 **LeetCode와 같은 플랫폼에서 중간 수준의 질문**을 시도하는 경우가 많습니다.
* 🛠 저는 응시자들이 중간 난이도의 문제를 풀기 전에 **적어도 50개의 쉬운 문제**를 풀어야 한다고 생각합니다. 이 기초 지식은 더 복잡한 문제를 효과적으로 푸는 데 매우 중요하기 때문입니다.
* 🚶 "간단한 개념을 숙지하지 못하면 지원자가 **루프나 조건문과 같은 기본적인 작업에 어려움**을 겪을 때 면접에서 어색한 상황이 발생할 수 있기 때문입니다.
* 📝 비교적 쉬운 문제라도 응시자들은 종종 간단한 코딩 작업에서 실수하는 경우가 많아 **고급 주제를 시도하기 전에 기본 프로그래밍 기술을 탄탄히 다지는 것**이 중요하다는 점을 강조합니다.
* 😟 면접관들이 처음에는 긴장하는 것이 일반적이지만, 시간이 지나면서 **많은 지원자들이 처음 10분 이내에 탈락**한다는 사실을 알게 되었고, 이는 사전 준비에도 불구하고 면접 과정에 대한 준비가 부족할 수 있다는 것을 알 수 있었습니다.

응시자들은 알고리즘을 알고 있음에도 불구하고 기본적인 코딩 작업에 어려움을 겪고 있어 더 강력한 기초 기술의 필요성을 강조합니다.

if you've interviewed at Google or if you know about the interview process. People say like Google's interview process is one of the hardest. I don't know if that's true or not, but I asked actually relatively easy problems. I chose problems from like Google's question bank. Most of the questions are not on LeetCode. I think that's the most unique thing about Google's interview process. They don't ask textbook questions. Most likely the question you'll be asked is something you haven't seen before. And so I chose, in my opinion, a relatively easy problem. Interviewers will interview a candidate, and then they'll give feedback for the candidate. The packet of feedback will go to something called a hiring committee, where a bunch of like seniors and managers will look at the feedback and then give a yes or no. And somebody from the hiring committee actually like gave me a comment saying, Hey, the question you asked was too easy. You got to ask harder questions in the future. So I know my question wasn't too hard. Now that said, I don't even think the person passed the

interview in that case, and I don't think I gave them a positive rating. I think I gave them leaning no higher. Yeah, I asked, in my opinion, relatively easy questions. Even then, people would get so tripped up by the question, and it was so weird because it wasn't like they were completely dumb. It wasn't like they didn't know how to code because they were talking at the beginning of the problem. They would ask a couple clarifying questions. They would say, Okay, maybe we can do a depth-first search or something like that. They knew what algorithms were. They clearly had done preparation for algorithms and data structures, but when it came time to writing basic code, like for loops, if statements, and things like that, they would make the most trivial errors. In fairness, maybe they were nervous. I can understand that. Like, if you're nervous, you might make a mistake you wouldn't. But I would even tell them, Okay, maybe there's a bug in the for loop over here. Just dry run through it. Just

walk through it, maybe you'll figure it out. They would just make like off-by-one errors in the for loop. I was just surprised by that and things of that nature. They would mess up if statements. That's why I think you should focus more on the basics. Get really, really good at the basics. Get really, really good with if statements, for loops, conditionals, control flow, just basic things like that. Because you really need to walk before you can run. Because if you don't do that, you're going to look kind of dumb when you're like trying to do a depth-first search or like a graph traversal or something complicated, but you don't know how to do really trivial things. It's just going to look really, really weird. And it doesn't take that long to do that. I think that's the same problem people run into with like LeetCode questions. Obviously, the classic mistake is people will start coding before they even know the approach that they're going to take. Even if you can't solve a LeetCode problem, the way to get

good at leak code problems is not to go down like really big rabbit holes. Focus on like the most complicated stuff right away, like dynamic programming. Why not just get really, really good at backtracking before you do dynamic programming? Why focus on harder stuff when you can't do easy stuff anyway? You shouldn't, in my opinion, do any leak code medium questions unless you're already good at leak code. You should not do any medium questions until you've done at least 50 easy questions because with that, you'll learn like reverse a string. You'll learn the basic linked list stuff. You'll learn even the basic graph traversals. You'll learn stuff like flood fill. You should not be doing like super hard graph traversal problems, something like this, before you've done the trivial ones. You'd be surprised how many people make that mistake. That's why I made this site and maybe even this site n could iio. I could make it even better. Maybe I should add more easy problems. I don't know. Maybe it could be more guided that

was how I mainly interviewed people. I didn't even necessarily expect them to give the perfect answer. I was willing to give people hints. I was willing to, like, tell people, Hey, can you just walk through this code, check if there's any bugs, and stuff like that. I was very much like helping people, and almost nobody passed the interviews that I gave. I think my interview tried to help so much during the interview, and that was an issue. Every time that I was in line of thought, he pushed me to another direction. I couldn't follow up. Yeah, I think that's fair. I think I've had a similar interview. The interviewer talks too much, and I think that can kind of get annoying and distracting. I don't think I did that, though. I didn't really talk a lot during the interview. I would just mostly be silent, and if there was a long silence or if the person asked me a question, I would try to help them out. But yeah, you'd be surprised how little interview training there is. You go through one course where they tell

you okay like do this for an interview, and then you like Shadow an interview, you watch somebody, another Google employee interview somebody, and then after that, you just start interviewing people. So if you ever get an interviewer that's really bad, don't feel bad because it's probably not your fault. The interviewer might just suck, they might just be new. I think when I started interviewing people, I was more nervous interviewing somebody than I was getting interviewed, at least the first few times that I did. I felt so nervous, I didn't want to like mess anything up. After a while, I learned that most people fail anyway within the first 10 minutes. If somebody's like struggling really hard to write a for Loop, it was kind of obvious that they weren't going to pass. And so I would be listening to them, seeing their code, and it just felt so bad 'cause you sympathize with somebody 'cause you've obviously been in the same position, but it's like the interview is like 45 minutes long, we're 10 minutes in.

this person doesn't know how to write a loop, and so it's going to be a long 35 minutes.

How I Interviewed Candidates at Google

NeetCodeIO

Google의 면접 프로세스에 대한 인사이트

Google의 면접 절차는 어렵기로 유명하며, 일반적으로 LeetCode에서 볼 수 없는 독특한 질문이 등장합니다.

면접관의 피드백은 채용 위원회에 전달되어 고위 경영진이 최종 결정을 내립니다.

면접관은 긴장감을 느낄 수 있으며, 지원자가 처음 10분 동안 어려움을 겪는 경우가 많아 합격 여부가 불투명해지는 경우가 흔합니다.

응시자들은 알고리즘과 데이터 구조를 잘 이해하고 있음에도 불구하고 기본적인 코딩 작업에 어려움을 겪으며 사소한 오류를 범하는 경우가 많습니다.

명확한 질문을 했는데도 긴장한 탓에 실수를 저지르는 경우도 있습니다.

면접관은 지원자에게 버그를 파악하기 위해 코드를 직접 실행해 보라고 제안하며 가이드를 제공하려고 노력합니다.

LeetCode 문제 마스터하기: 단계별 접근 방식

동적 프로그래밍과 같은 가장 복잡한 문제에 바로 집중하는 것은 효과적이지 않습니다.

쉬운 문제와 문자열 반전, 그래프 순회와 같은 기본 개념을 먼저 익히는 것이 중요합니다.

더 복잡한 문제를 풀기 전에 제어 흐름과 조건문에서 탄탄한 기초를 다지는 것이 중요합니다.

면접관이 지원자를 효과적으로 돕지 못해 합격률이 낮았습니다.

힌트와 안내를 제공했지만 계속 방향을 바꿔 혼란을 야기했습니다.

면접 교육이 부족하여 최소한의 안내만 제공하는 교육 과정도 흔한 문제였습니다.