The weird thing is that it’s been this way for decades, but the enormous product-market fit of the FAANGs’ core products have masked this.

I read a new book about Android development, mostly built around interviews of the original team. Several times it was mentioned that after the Google acquisition, Android was unable to hire the people they needed — experienced Be/Palm/Danger devs from their network — because they were unable or unwilling to pass the Google interview bar. High-level exceptions had to be made to bring in these people Google absolutely needed to build the new OS.

That suggests that other teams inside Google (and other companies imitating their interview process) have been in a similar quandary, but without the C-level exception to hire the experienced people they wanted. And I think that explains some of the product struggles these companies have had. Android is clearly the exception as a long-term success.

I reluctantly obliged, and had a couple of phone screenings where they said they were looking for experienced embedded systems developers for low-level hardware development. I was specializing in 8-bit microcontroller firmware and Linux kernel drivers, and the recruiter said it was exactly what they wanted.

When I took the first technical interview, they grilled me on MapReduce and cluster storage, and then asked me to design a collaborative text editor for the web. The interviewer didn't have a copy of my resume, hadn't seen it, didn't know what position he was interviewing for, and didn't know anything about hardware. We had a really awkward moment when I explicitly said, "there must be some mistake, I'm supposed to be interviewing for an embedded role." I bombed the hell out of that interview, and never heard back from them again.

If my experience was typical, then no wonder the Android team had trouble with staffing.

This is a clear and unambiguous downside.

But the presence of downsides is not always a reason to reject a process. A huge upside of the process is that Google enables fluid transition of people within teams around the company. This among my favorite things here and it makes it so that good people with shit managers are not just automatically flung out of the company because their particular team is a toxic mess.

If you're lucky, you'll get an interviewer who thinks that if you can solve a case insensitive palindrome, it means you should be hired with strong confidence.

But if you're unlucky, you'll end up with a person who will squeeze the last ounce of blood out of you, and even if you solve 99% of the questions correctly, he will still think you're low confident or even a no-hire because you missed that one edge case...

Depending on where you live you likely have a legal right to the interviewer's written feedback. I've never tried it (US) but I've heard of many other people (US) that were successful but you probably need to know w/e relevant law it is as I assume by default you won't get it.

That's a sure fire way to get blacklist from a company. No US company likes to deal with high maintenance candidates/ employees. The risk is too high to just move on and let it go. The best course of action is usually to come back in 6 months to a year and interview with another team.

I think respecting a red flag of any member of a team to stop a hire is a good practice.

I have encountered my fair share of bad interviewers. You don't even need to take my word, go on Blind and read all the horror stories from both the interviewer and interviewee.

I think the statement to be too generalized and doesn't address the power dynamics of the interview process. You assume they are good judges of character from a 60 minute interview.

all interviewers are subjective - it's part and parcel of the process...which is why you need to excise the trivia questions from the process

This is sound logic, but it seems to only be a problem with SWE positions. I've done a few other jobs in the past, many of them very technical themselves (and around the same kind of pay, though perhaps not quite as high), and the interview process for those don't get anywhere near that of a SWE. At most, you might have some very high level technical talk, but most of the time its just a standard job interview as you'd expect for any other job.

Of course those positions do have a problem of hiring people who don't actually know how to do the job, but so does SWE. I wouldn't be able to tell you how much more effective SWE interviews are at picking the right person, but clearly its not enough of an issue for other positions to the point that interviews are having the change.

What's the definition of "pass"? I've done around 4-5 rounds of these interviews over my career, without prep - Microsoft, Google (several times because I keep thinking they'll give a reasonable offer), and my current company. In exactly none of them did I have all the answers right away. In some of them, I even failed to come up with 'the right answer' in the allotted time. After exactly all of them I got an offer.

I don't think people arguing about these even understand what the goal is; or they fail the behaviorals or whatever and then blame it on "failed" interview questions.

Maybe you're a genius. In any case, your experience is not particularly useful to the rest of us.

Failing behaviorals is also usually a result of poor preparation.

What if — and hear me out on this one — the people passing these interviews consistently understand them better than you do? I know, it's a nigh incomprehensible concept, but if you really struggle with it for a while maybe it will make some sense.

But what do I know, I've never even looked at leetcode so maybe I'm missing some trick to extrapolate from anecdote to data accurately.

I think maybe some people are mistaking job interviews for university exams.

Look, I spent a nontrivial amount of time on study. Was it worth it? Yes, because I was able to achieve my goal. Did it have any relevance whatsoever to my actual performance? None. at. all. I would've done the exact same job as prior to the prep. I also know for 100% that I wouldn't have passed without it. That is why I argue about this process - it doesn't convey any real signal about me as an employee, it's all theater.

Focusing on CS topics is something that should work for junior as well as senior developers. You can't ask someone junior how they solved some previous team issue, but you can ask a senior to reverse a linked list, because it's something basic that doesn't require experience. It's not the only thing you ask a senior developer, though.

The actual answer is less interesting than how you interact with me. That said, interviewers should be flexible, good listeners and not have a bad day.

You can ... but no one actually does that once they get past about sophomore/junior year in college

Thankfully those are usually junior hires and can often be mentored into a good or excellent engineer.

It’s just a bad test, why are people so hung up in it? Cause Google does it?

Also, because there isn't really a "good" option for interviewing (especially at scale), the door is always left open for endless circular debates on the topic.

I do think there's something of an obsession to minimise false positives at the expense of false negatives. The companies are succeeding at this, which I find foolhardy as they lose the opportunity to hire even more of the high performers who can't or won't jump through the hoops.

Do you think that this process actually selects for the best programmers? Like, is it too rigorous, or is it instead measuring something adjacent but distinct from the best developer? If they can’t use it to hire senior talent, then that doesn’t sound like "hiring the best".

There's a common vocabulary and it doesn't matter where someone went to school, binary trees are the same at Stanford, IIT or some regional unknown school. And the textbook they used were probably the same as well!

And yet most people I know, when they're told they may have to do one of these inane whiteboard sessions, turns-down the potential employer because it's a moronic hoop to jump through