Hacker News Reader

> “they all, as far as I can tell, struggle with hiring senior talent, yet are unable to let go of these hazing processes”

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.

Huh, that's interesting. The Android team was absolutely hounding me for an interview back in ~2009, to the degree of finding my parents' home phone number and asking them to convince me to take an interview.

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.

Your interview experience is typical - I've interviewed 4 or 5 times at Google (never once after applying), and each time I've "failed" some portion of the prescreen script interview that's done by incompetent "recruiters"

Yes this has happened to other people, I believe it was the homebrew developer that couldnt pass the hazing and found it ironic

It really is odd, and I think it shows how processes have inertia of their own, the bigger the company, the bigger is inertia. Too big to stop at this point. After our struggles to hire senior folks as a Bay Area startup I was expecting something different at a big tech company.... and it just wasn't.

I have experienced this. My team works in a niche domain and finding people who both have the relevant domain expertise and pass the interviews is hard. I think this is less because of people being unwilling to do interviews and more just inherent noise in the process. It makes hiring especially brutal when 95% of candidates the system throws my way are completely unqualified because they don't have the domain background.

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.

My biggest bone to pick with this interview process (I was also interviewed, passed the interview and then trained to do interviews) is that the calibration is all over the place.

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...

What I have seen is that many interviewers are actually subjective. I've had interviews which I passed and then to be told I was rejected without explanation. I knew I failed though because 1 of the interviewers didn't like me. This interview process is really a facade to not get sued. 9/10 of the team may like you, but it only takes 1. And from my experience, its usually the ones with lower EQ that make face-value assumptions about a person they are interviewing. You have no recourse to fight for your role because of the power dynamics of the interview process. They will simply say they don't want to hire false positives.

Is the alternative that the bosses pushes ahead and hires people that have objections? Then the team risks losing a known good member who quits for spite, for a maybe good new hire.

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

That assumes all interviewers are a) good members and b) good interviewers.

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.

Not sure which FAANG does 10 interviews but anecdotally I've seen people get hired with 2 out of the 5 ratings being negative (i.e. no-hire).

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.

> Depending on where you live you likely have a legal right to the interviewer's written feedback.

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.

>many interviewers are actually subjective

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

Even with the training I had received at FAANG, there's still (and will always be) a level of subjectivity. I've seen colleagues hire candidates that didn't meet the "bar" but because the interviewer really "liked" that person, they went to bat for the candidate. Ironically that same interviewer would click "no hire" despite the candidate meeting the bar, all because the interviewee every-so-slightly rubbed them the wrong way.

Yegge called this the anti-loop - http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... - back in 2008 hah. Still holds true.

> These companies need a repeatable, trainable process that can scale reasonably well to thousands of interviewers and hundreds of thousands of applicants

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.

> without prep, it's quite unlikely to pass the interviews at these tech giants

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.

If you're passing FAANG interviews without prep, you're in a very small minority.

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.

This is very clever reasoning. "Of course I understand how these interviews work; of course I understand what it means to pass them. Hmm? No, I have a lot of trouble passing them. Oh, you don't? Well your experience is irrelevant."

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.

Surely the answer is found in data of how many people do and don't need to prep, not in you being as confident as the other side that you know best based on your personal experience?

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.

Right, you left out the next part from the quote - "(yes, there are people who have done it, they are the minority)". Congrats on being able to consistently pass without prep - I stand by my words that most passing candidates are not in the same boat. I've heard enough comments from folks on the inside about the factor that luck played, and how they would be unlikely to pass again.

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.

My experience has been like yours. I don't prep, I don't memorize, and I don't worry about the answers, because they don't matter. I just put my engineering hat on, work my way through the problems, and communicate as I go. Maybe I find a solution right away, and they throw me a twist to take it further; maybe I struggle, and they have to give me a hint; maybe I work at it for a while and explore a couple different approaches, but never actually get there. So what? The process is the point, and I show them how I work. I almost always get an offer.

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

To add to this, there are many situations where the thing asked is less important than the fact that any question was posed. E.g. the customs agent who want to see if you are nervous, or the emergency services that want to see how conscious you are. In interviews, it creates a path forward and pacing.

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 ask a senior to reverse a linked list

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

Your comment focuses on false negatives as if that is the only downfall, but I can't help to imagine false positives happen quite a bit.

The stereotypical false positive is a competition programmer who aces whiteboard puzzles and leetcode type problems but isn't actually a good software engineer. They fall down at all the other parts that aren't clever programming.

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

There are also lots of people who are just bad engineers but memorize Leetcode problems. Most of Leetcode is memorization, and most of the people I see get hired at Leetcode establishments aren’t good engineers.

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

People are hung up on it because it's the gate to making ridiculous amounts of money doing what we all enjoy.

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.

False positives surely exist, but in my experience the challenges are rigorous enough and preparation requires enough patience, that there's a certain competency floor here that makes this less of a problem for the company. Every single engineer I met there ranged from competent to "10x", contrary to a neighboring comment.

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.

To be fair FAANG are probably large enough now that they can get by with a mix of average engineers at this point as well. They really don't need the best of the best. It's all at scale now and there isn't time for individual attention.

> Furthermore, given the extreme volume of applications, the companies feel that they can afford to "hire the best" by adopting particularly rigorous processes.

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".

I most certainly do not, hence the quotes :-) In fact, I think it actively selects _against_ the best candidates. Basically, it's optimized to quickly cut out the long tail of subpar employees (per whatever definition they might have), which happens at the expense of those that are unable to pass but would still be awesome (lack of prep, lack of opportunities, anxiety issues, etc) and those that can't be bothered (a lot of experienced folks fall in here). The process might work for the mid-to-upper band of candidates, but anyone outside of that, on either end, is left behind (with exceptions of course). Companies are totally cool with that, because the long tail is quite a problem at that scale.

For college hires it's also something they know everyone will have studied (algo and data structures) no matter where they are from.

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!

>the companies feel that they can afford to "hire the best" by adopting particularly rigorous processes

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