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.