The idea behind algorithm-style coding interview questions is they are very hard on purpose and they help filter down the number of candidates that you actually have to the most dedicated ones that are the cream of the crop. And this works great for FAANG companies, which are super highly sought after and

they have hundreds of candidates that are all super qualified and they can afford to be picky. The problem is when we have the rest of the tech industry copying FAANG, and we have freaking Home Depot asking me to invert a binary tree to figure out if

I'm qualified or not to change the background color of their landing page from #FFF to #FAFAFA. And I'm not trying to make a specific point about Home Depot particularly. I don't know actually how they do their interviews. I was just the first random

company that came to mind. My main point is that what you actually do on the job as a software engineer is very different than what they are actually asking you in algorithm-style interview questions. So much so that you actually need to study for weeks if not months before you

even do an interview. And then when you actually go into the interview, you can just as easily be asked a question that you didn't study for, or God forbid you forgot that one algorithm under the pressure of the moment that you needed to answer for this particular problem.

And you just screwed up. GG, you're not getting the job. It's over. And this is extremely ridiculous when it's happening for interviews of intermediate or senior level engineers. Like imagine being a software engineer for several years, you're successful, you're good at your job, and then you go to switch jobs and

You actually need to study for several weeks, grinding LeetCode questions because you are not going to be quizzed on the knowledge you've accumulated the last three years you've been working. And to drive this point home, we are going to compare what an average Google phone interview is like compared to what you will actually be doing on the job. First off, you're going to be asked to code in a Google Doc, whereas on the job, you're going to be able to use an IDE or a code editor where you know you get all that

fun stuff like syntax highlighting and auto-complete checking. But you know that stuff doesn't really matter. The big grievous sin that Google's making here is it's forcing developers to interview while using a light-themed editor. You would think a company like Google would know

that software engineers can't think using a light-themed editor like Google Docs, but I guess they don't. Secondly, when you're in an interview like this, you're going to feel a lot of pressure and it's very hard to code under pressure. Whereas when you're on the job, you're

given, you know, maybe a deadline, but it's not the same type of pressure. You know, it's usually spaced out and you can usually work under a more relaxed atmosphere. Like, no one is going to start a 30-minute timer and command you to center that div. They're going to give you a

week for hard stuff like that. Thirdly, the problem they're going to ask you is going to need to be solved with some sort of algorithm. And this would really be another story if software engineers just on a daily basis use these algorithms, but the problem is they just

don't. And even if we want to pretend that you do use algorithms on a daily basis, it's still different. You are not reciting or coding extras algorithms from memory. You're either one using an existing library because you know it's been tested and optimized and all that

other junk or - you are pulling up the extras algorithm as a reference while you're actually coding it to make sure you're not doing anything wrong. And this leads me into my next point, which is Google does not let you use Google on a Google interview. The heck you were

expected from memory to recall the algorithm that you need to use to solve the particular problem that they ask, which I think is just silly when we live in 2020 and it's actually a very important skill to be able to Google things well as a software engineer.

So the result of having interviews like that, which are so different from the actual job that software engineers do, is you have candidates which are not going to pass these interviews that are qualified for the job, would be great at the job, but they fail the interview and

therefore are not going to get hired. So you may ask, well what's the solution then? And I think the solution is very simple. You just need to close the gap. If I was going to interview candidates, I would make that process as close as I possibly can to the actual job that they

are going to be performing. So let's say that the person that you're hiring, what they will actually be doing on the job is fixing a lot of React bugs that you have in your codebase or whatever. So take the last bug your team encountered, give it to the candidate, have them you

know, spend the next 30 minutes trying to debug it, give them all the tools that they would use on the job, let them use Google and, you know, watch what they do, watch the process of how they think and, you know, solve that sort of thing and I

think that would be a much better way to do it. The main thing I am advocating for here is to have more domain-specific questions that are specific to what you're actually going to be doing on the job. I just think it's silly to have

software engineers study and memorize stuff just for an interview that they're then not even use that often when they're actually on the job. It reminds me kind of like when I was in college where I would just cram for stuff right before a test just to get that grade and

it's just not a good system at all. And I'll just end this video by saying I would much rather have someone on my team who can actually debug and find error messages and fixes on Google rather than Chad who has Dijkstra's and Prim's algorithm memorized.

Coding Interviews are Broken

I'm a software developer who makes videos about React, React Native, GraphQL, Typescript, Node.js, PostgreSQL, Python, and all things coding.

Ben Awad

알고리즘 방식의 면접은 FAANG 기업에 적합한 후보자를 걸러내도록 어렵게 설계되었습니다.

문제는 다른 기술 회사에서 이 모델을 모방하여 덜 까다로운 역할에 복잡한 알고리즘을 사용할 때 발생합니다.

직무는 면접 질문과 크게 다르므로 광범위한 준비가 필요합니다.

이는 수년간의 경력에도 불구하고 몇 주 동안 공부해야 하는 중급/고급 엔지니어에게 특히 문제가 됩니다.

구문 강조 표시 및 자동 완성 같은 기능이 있는 IDE를 사용하는 것과 Google 문서 도구에서 코딩하는 것을 비교해 보세요.

현업 업무의 편안한 분위기에 비해 면접 환경은 긴장감이 높습니다.

면접에서 알고리즘에 집중하는 것과 일상 업무에서 알고리즘을 자주 사용하지 않는 것.

온라인 조사 기술의 중요성에도 불구하고 Google 면접 시 Google 사용을 금지합니다.

자격을 갖춘 지원자가 면접과 직무 간의 단절로 인해 불합격하는 경우가 많습니다.

해결책은 면접 프로세스를 실제 직무 요구사항에 맞추는 것입니다.

예: 실제 버그 사용, 필요한 도구 제공, Google 검색 허용.

실제 직무에 초점을 맞춘 도메인별 질문을 옹호합니다.

알고리즘을 암기하는 것보다 실용적인 디버깅 기술을 우선시합니다.