Coding interviews are stupid (ish)

> Can we stop calling it "failing" when a company decides you're not a good fit? If you go on a date and don't get asked for a 2nd, did you fail the date? You're not just what they're looking for right now; not everything has to be a failure.

Fair point.

> I'm sorry, what? He thinks it takes one hour to teach someone data structures? We sure are wasting our time with those multiple college courses and hundreds of textbooks on the subject then. We should just get this guy to spend one hour imparting all necessary knowledge into everyone.

There's a difference between understanding how to implement one and just knowing how to use one that's already been written by someone and when to use it.

> Human biases are much more likely to work against you if the interviewers have not spent time trying to come up with a consistent test that they give everyone. Does the author think human bias is absent from non-technical interviews? The less standard your hiring methods are, the more bias you'll have.

Fair, but alas I don't know the rigors they have put their hiring process through. If I were a betting man, I'd still say that if we measured all processes using programming tests, the majority of successful candidates had working output by the end.

> I don't know who Darren Kopp is, so maybe I'm about to get an army of replies saying he's their coding role model

I've been told this by everyone who knows me

> but this is an article about whether code interviews work or not, and he's basically saying "if they don't hire me, who will definitely become one of the best employees they've ever had, then their coding interview process must suck". The other possibility is that Darren Kopp just isn't actually tremendously more stellar than everyone else and coding interviews are actually kinda working. For his argument to work, he has to be one of the best possible candidates for every job he's applying for. I just kinda doubt that.

Actually the only conclusion I have after writing the post is that I am not talented at interviewing. I do believe coding interviews have flaws for how they are used, but that doesn't necessarily make them wrong or right. I agree with your first statement, maybe I'm just not a good fit.

Perhaps both of us are correct as I consider coding interviews more of an audition than anything else. If Tom Cruise auditions for a part and doesn't get it, does that mean he's a bad actor? Likely not.

(I'm Tom Cruise here, btw).

I think it's a lot easier to get a staff role than being a Hollywood actor. Staff+ comprises around 7-10% of a company's engineering team.

A quick Google leads me to believe there's usually about 15-20 A-list actors at any given time and 130,000 members of SAG-AFTRA.

I think it's certainly achievable if you put in the time and effort (and of course if you're good at your job) -- the question is do you want to or not. It can be incredibly demanding and may not be intrinsically rewarding to you. It seems folks generally believe "senior" is an achievable level -- they should, it's usually the first "terminal" level at which it's ok to remain for the rest of your career -- then you shouldn't view staff as intrinsically out of reach.

Actually there's another job before that, I just don't list my full employment history. Before that was VP of Engineering. That's just my final title, however. I started that as a normal engineer. And then as a senior engineer before CTO.

Small companies, so not the same as being VPE or CTO at Amazon. You see those as title downgrades, but I don't. I have a lot of talent, so people want to promote me and put me in charge. I don't want to be a manager/leader currently, I want to be a strong IC.

> Why is the software engineering interview wildly different from the traditional engineering interview

I have my personal theory.

1) Top companies receive way more applications than the positions they have open. Thus they standardised around very technical interview as ways to eliminate false positives. I think these companies know this method produces several false negatives, but the ratio between those (eliminating candidates that wouldn't make it and missing on great candidates) is wide enough that it's fine. It does leads to some absurd results (such as people interviewed to maintain a library not being qualified despite being the very author) though.

2) Most of these top companies grew at such rates and hiring so aggressively from top colleges that eventually the interview was built by somewhat fresh grads for other fresh grads.

3) Many companies thought that replicating the brilliant results of these unicorns implied copying them. So you get OKR non sense or such interviews.

> Interviewing should be more about avoiding bad candidates than finding the best candidate.

> This guy fails coding interviews. Then he gives coding interviews, but the people he selects based on these interviews are a mixed bag. Because he's failing the interview from both directions.

Good points, but I should say that the people that didn't work out weren't always because of technical abilities. The company that had the worst success rate was fully remote, but I don't know if there's any interview process that can help with that.