Ask HN: Devs who passed whiteboarding at FAANG: how do you feel about it?

[user0x1d]

Most of the blogs I read about whiteboarding and leetcode style questions come together with hate. “It doesn’t test real world scenarios” or “not proof of how well I’m gonna do at the job”.

Do you agree with those? Or is it just the case that the tests are designed to see if the person applying is actually really smart and interviewers want to work with really smart people, and those complaining about these types of questions are just not good enough?

Honest question and I’m not taking any side although I admit it I tried to phrase it more towards getting favourable FAANG responses

[romanhn]

Ex-FAANG here and I am firmly in the former camp. These interviews most definitely don't test anything you will be doing on the job. Thing is - that's not the point. These companies need a repeatable, trainable process that can scale reasonably well to thousands of interviewers and hundreds of thousands of applicants. Unless you have individual teams running their own processes (and I believe Netflix does this), real world scenarios no longer fit the constraints. Furthermore, given the extreme volume of applications, the companies feel that they can afford to "hire the best" by adopting particularly rigorous processes.

It took me years to internalize this and get over the aversion to studying for these interviews. At the end of the day, many reasonably competent people could do the day-to-day work just fine. Interviews, however, are their own separate thing and without prep, it's quite unlikely to pass the interviews at these tech giants (yes, there are people who have done it, they are the minority). Might as well make peace with it. Personally, I think this is a hell of a feedback loop companies got themselves into, as they all, as far as I can tell, struggle with hiring senior talent, yet are unable to let go of these hazing processes.

I do reserve a certain amount of ire for companies/startups that copy these interview styles without having the same constraints or pipelines. Knocking out a great portion of candidates that would have likely done just fine on the job, because the hiring teams didn't bother to build an interviewee-friendly process boggles the mind, given how desperate many of these companies are to hire.

[pavlov]

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

[mrmekon]

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.

[warrenm]

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"

[UncleMeat]

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.

[romanhn]

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.

[yieldcrv]

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

[alefnula]

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

[nowherebeen]

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.

[lesuorac]

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.

[nowherebeen]

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

[brianwawok]

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.

[nowherebeen]

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.

[warrenm]

>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

[itsmemattchung]

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.

[zBard]

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.

[bodge5000]

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

[puffoflogic]

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

[pilgrimfff]

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.

[puffoflogic]

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.

[swores]

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.

[marssaxman]

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.

[romanhn]

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.

[tommiegannert]

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.

[warrenm]

>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

[nightski]

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.

[wffurr]

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.

[mountainriver]

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?

[Icathian]

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.

[romanhn]

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.

[nightski]

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.

[mcphage]

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

[romanhn]

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.

[908B64B197]

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!

[warrenm]

>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

[throwaway9191aa]

Current FAANG. Most of the folks I work with give terrible interviews. You really can do these questions correctly, but most don't.

My AWS interviewer (I got super lucky) asked me a really basic question about linked lists. Then expanded to a double linked list. Then we talked about inheritance. Only then did we attempt to find the nearest parent of two nodes in a tree. It was a great example of determining knowledge, and whether that knowledge can be applied to problem solving.

When I shadow interviews I usually hear folks ask candidates something like "find repeating k-clusters in a string" and then just silently wait for the code. Or even worse, design a filesystem. Then critique the candidate for not thinking of weird symbolic link ownership edge cases. Unsurprisingly, this is just what it is like to work at AWS :(

The question needs to have multiple solutions that you can discuss with the candidate. The question needs to have some follow up like "What if you were writing this on an embedded device? How would that change your solution?". These situations DO arise every day. Here is a simple problem, with annoying institutional requirements. Can you still come up with something? Or did you just memorize the algorithm?

[__derek__]

I used to be an Amazon BR and agree with this.

[ggambetta]

Disclaimer 1: Opinions are my own, not Google's.

Disclaimer 2: I interviewed with Google twice, and I was hired twice. This might bias me.

Are we talking about interviews by FAANG, or interviews by startups that cargo-cult FAANG? In my experience as a candidate (twice) and as an interviewer (O(100) times), I was never asked, or asked, the kind of Leetcode question people love to hate.

The questions involve a whiteboard, yes; and they involve reasoning about algorithms and writing code, yes; and I don't see anything wrong with that. I see people putting down whiteboard interviews and people almost proudly saying their job consists of gluing together fragments of StackOverflow code they don't fully understand, and that just won't cut it at a FAANG, so you need to know what kind of candidate you're dealing with.

The most complex my go-to question gets is very basic recursion and very simple caching. A surprising fraction of the candidates I interview, who always have a nice-looking CV and have gone through recruiter and phone screening, can't do basic recursion and basic caching. I'm not asking a trick question, you don't need to remember an obscure factorial formula to find the optimal solution, none of that crap.

Recursion and caching. Table stakes, IMO. You can get away with not grokking recursion and caching for some kind of role where you can copy-and-paste StackOverflow answers and random tutorials, but you probably won't do well as a SWE in a FAANG where you're handed a vague feature request and you're expected to deliver a feature that will be used by a billion people by the end of the quarter.

Not saying that every feature requires recursion, caching, and complexity analysis, but these kind of skills are a good indicator of whether you're the copy-and-paste variety or the build-something-new variety, and it's important to know which one the candidate is.

Now if you're interviewing for a startup whose product serves a small number of users and you're asked the tricky gotcha Leetcode questions for no good reason, sure, that's dumb. But don't hate the good use cases just because the cargo-culters get it wrong.

[cdelsolar]

How often do you use recursion at work? I can count on one hand the number of times I’ve written a recursive algorithm in almost 20 years of coding for work.

[e63f67dd-065b]

Any kind of tree or graph traversal in a moderately functional language? If you’re a frontend dev trying to glue together something that works I can see it, but I would wager that you’ve come across some kind of tree or graph problem that would be best formulated in terms of a recursive algorithm in 20 years of professional work.

Maybe I just have a skewed perspective as a grad student working on filesystem stuff, but I can’t imagine going for years without having to solve some kind of graph problem.

[hnfong]

> If you’re a frontend dev trying to glue together something that works

(Not the GP) I mostly do "backend" work, my limited experience with the frontend (mostly javascript) is that you actually need to deal with (explicit) tree structures more in the frontend. The DOM tree is one, for example. Other UI elements can be modeled quite nicely with a tree structure too.

[ggambetta]

Very rarely, but the point is that I could use recursion if I had to (and perhaps more importantly, that I could recognize the need to use recursion).

[thomastjeffery]

I expect that has everything to do with what language your are using.

If it has tail call optimization and clean pattern matching syntax, then recursion tends to be the more readable (and equally performant) way to traverse data structures, especially anything more complicated than a 1-dimensional list.

These two features (tail call optimization and pattern matching) have seen a surge in popularity over the last decade, notably in Rust.

[steveklabnik]

Rust does not guarantee TCO, just to be clear.

[physicles]

I honestly don’t think that’s relevant.

A whiteboard interview tests your ability to do something you do constantly while writing code: you look at the code you wrote and run it in your head with enough fidelity that you can verify it to a first approximation. If you can’t do that, you’re going to be slower and you’re going to make more mistakes than someone who can.

Small contrived problems like recursion are useful for testing this specific skill. A program to calculate e.g. Fibonacci using recursion isn’t that complicated; to me it seems like table stakes for actually writing new software.

[nunez]

All the time

[pclmulqdq]

As an ex-FAANG developer, it does not test anything other than your ability to put up with BS and your ability to learn to play an arbitrary game. Ironically, those are skills you kind of need at a FAANG.

[wai1234]

The tests select for people that will put themselves through hell just to work for you. They don't measure anything else. See any of the many stories of gifted, senior, often well known devs who did not 'pass' because they refused to degrade themselves by spending months studying to pass an arbitrary process.

The notion that you figure out "if the person applying is actually really smart" is a 'just so story'.

[kypro]

> The tests select for people that will put themselves through hell just to work for you.

Assuming this is true, are you suggesting this is done knowingly and deliberately by those conducting the interview? I wonder if there is data suggesting the approach works (employees who undergo whiteboarding are more productive than those that don't), but perhaps the reason why it works is not understood?

[wai1234]

I'm not aware of any evidence the approach works. Seriously.

[wai1234]

I realized I didn't answer your question.

Yes, it's a form of hazing.

[Youden]

I think what most people miss is that a FAANG doesn't recruit for a specialized role. When you interview, you're not interviewing to be a full-stack developer for some web application, you're interviewing to be a generalist who might work on anything from embedded code in some smart home device to datacenter resource provisioning.

The FAANGs give you these weird tests because they're not really checking your programming ability so much as your general problem-solving ability, because problem-solving is the biggest part of what you're being hired for, code is just how you write down your solutions.

[lapcat]

> I think what most people miss is that a FAANG doesn't recruit for a specialized role.

I know this is false of Apple, for example.

> a generalist who might work on anything from embedded code in some smart home device to datacenter resource provisioning

Is this a real occurrence from your experience or just a hypothetical figment of your imagination?

[ggambetta]

> Is this a real occurrence from your experience or just a hypothetical figment of your imagination?

I have worked as an SRE bringing up and down services in data centers, as a SWE I've designed an instruction set for a VM and implemented an interpreter, written browser attestation code in JavaScript, did some consulting about 3D rendering with OpenGL for an internal prototype, and I'm currently writing web components for YouTube, all of this at Google. Hopefully that's close enough?

[Youden]

I don't have knowledge of Apple.

> Is this a real occurrence from your experience or just a hypothetical figment of your imagination?

I don't know of anybody executing this specific change but I do have first-hand knowledge of it being possible, it's not just a contrived imagining pulled from my arse.

[lapcat]

> I do have first-hand knowledge of it being possible

What do you mean by possible?

The difference between possible and actual is actually what determines whether it's a contrived imagining.

[marssaxman]

Are you looking for examples of people who have made such substantial transitions within a single span of employment, or are you skeptical that people can have such a span of experience at all?

[lapcat]

I am skeptical that a BigCo employer, who has thousands of engineers to choose from and countless more who could be hired, would move an engineer from embedded code in some smart home device to datacenter resource provisioning. It feels like the management equivalent of roulette.

[pharmakom]

The problem is many of these leetcode tests can be practiced - whether it’s spotting repeated problem structures or simply recycling questions. As a result they don’t really test problem solving ability but how much effort went into prep work. This makes it a really poor signal.

[thaumasiotes]

I actually see a worse problem than that. The idea of the leetcode interview is that you give someone an extremely hard problem and hope they solve it in 30 minutes. But the problem is much too difficult for any nontrivial number of candidates to solve it themselves in 30 minutes, so the intent of the process is that the candidate draws the answer out of the interviewer, who has prepared it in advance.

Then they're graded on how much help they appeared to need. But this grading is hopelessly contaminated by candidates' varying levels of charm and ability in cold reading. Cold reading isn't the skill companies want to test for, but it's the skill they actually are testing for. If you want to evaluate the candidates objectively, the goal would be to minimize interaction with the interviewer, not emphasize it.

[biztos]

TIL:[0]

> Cold reading is a set of techniques used by mentalists, psychics, fortune-tellers, and mediums. Without prior knowledge, a practiced cold-reader can quickly obtain a great deal of information by analyzing the person's body language, age, clothing or fashion, hairstyle, gender, sexual orientation, religion, ethnicity, level of education, manner of speech, place of origin, etc. during a line of questioning. Cold readings commonly employ high-probability guesses, quickly picking up on signals as to whether their guesses are in the right direction or not, then emphasizing and reinforcing chance connections and quickly moving on from missed guesses. Psychologists believe that this appears to work because of the Forer effect[1] and due to confirmation biases within people.

[0]: https://en.wikipedia.org/wiki/Cold_reading

[1]: https://en.wikipedia.org/wiki/Barnum_effect

[bambax]

> many of these leetcode tests can be practiced (...) This makes it a really poor signal

It signals dedication/motivation at the very least.

It seems the people complaining are people who can't leetcode and, for some reason, won't practice. But why?

You either can leetcode, and it's all good, or you can't, and you should simply practice.

People who can't be bothered to practice leetcode for a couple of weeks to get past the tech interview, probably don't want the job enough.

[pharmakom]

I’m actually quite good at leetcode (or so I like to think). The reason people are annoyed is that they must jump through hoops for something that is a poor signal of job performance so it feels like a waste of time.

[62951413]

Two weeks is not enough even to read something like https://www.amazon.com/Dynamic-Programming-Coding-Interviews... unless you are already unemployed. Also, some of us have practiced actually writing software for the last 20 years. And in my limited spare time I'd rather study something useful.

The world is full of people who have passed leetcode puzzles. But to this day somehow I see more JSON over HTTP than gRPC in the wild. Or developers (or is it their managers?) saying that Scala is too complicated. Comments in the code? Meaningful README files? Even descriptive commit messages are less common than HN would make you believe.

[bjourne]

Can you give an example of a leetcode test that can be "practiced"? I assume you actually mean "memorized" since leetcode tests are meant to be used for practice.

[rockinghigh]

Meta hires for a specific profile like ML specialist, ML generalist, SRE, backend engineer, mobile developer, ... Apple hires for specific teams with often a specialized role as well.

[avgDev]

Amazon and AWS both hire for specific roles and teams. Additionally. so does Microsoft. I was contacted by them in the last few weeks.

[yieldcrv]

Everyone knows why the companies think they need to do it this way.

“False negatives better than false positives”

“Need general set of skills”

That has nothing to do with their implementation being wrong and batshit crazy.

How about they go back to the whiteboard and think of something else.

[kamaal]

>>“False negatives better than false positives”

Nice idea, but doesn't work with underlying constraints. Nobody has infinite time and resources to interview and hire people. What that means is the more 'False Negatives' you do, less resources you have to hire 'True Positives'. Not just this, at this point you are inevitably likely to hire more 'False Positives' than 'True Positives'.

In fact the stated strategy seems to work, if and only if you are hiring 1 - 2 candidates for some very special positions. Otherwise its a bad strategy.

[myvoiceismypass]

Netflix interview process was not like this at all. They don’t hire generalists (at least in the past)

[TruthWillHurt]

That's incorrect. You interview for a specific role, and if you fail the interview you're done. No matter the promise they'll "look for other roles for you".

[hinoki]

It depends on the FAANG. In my experience:

Amazon hires for a specific team lead.

Google hires for a specific manager (one level higher than lead).

Facebook hires for a specific office. Boot camp is for team placement.

I don’t know about Apple or Netflix.

Of course, if you have very specific skills, you might get hired to a specific project, etc.

[Grustaf]

People who hate whiteboard interviews are probably the same kind of people that say things like "why do we have to learn multiplication in school, I can use the calculator app."

As others have pointed out, the idea is to provide a context where you can judge the candidates knowledge, intelligence and ability to explain their thinking. Whiteboard tasks happen to be a good way to do that.

When the interviewer asked me to implement a depth first search algorithm on the board (although he didn't call it that), it most definitely wasn't because he thought that I would ever need to do anything like that. That's why they accepted me even though I didn't quite nail it. That's why I never worry about memorising algorithms, that's really not the point.

[shaftway]

I see the whiteboard tests as similar to the skills test necessary to get a motorcycle license in California. To get your license you need to weave between a set of cones, go around a circle, and then come back through the set of cones, all without exceeding 5 mph or putting your foot down.

None of this tests real-world skills. You never have to weave as tight as the test requires, going that slow makes it painfully difficult, and if you have any balance issues at that speed you should put your foot down, even if it's just for a quick touch. But they keep the test as-is. The thinking is that if you're capable of doing the hard stuff in the test it demonstrates that you've had enough time on the bike to figure the rest of it out.

The leet-code interview questions are the same. I don't expect you to have read the problem before, or to give me a perfect answer, because the interview isn't the job. But how you handle a question like that gives me insights into roughly how much experience you have and how comfortable you are with code. If you can handle that question, even if you wobble a bit, you'll probably be fine on the job.

[shaftway]

FWIW, the question I asked when I interviewed was whether a group of stones on a Go board had any liberties. I don't play Go, and I don't explain it that way; instead I describe stones as trapped or not, and define what trapped means. Then I make sure that the candidate can identify whether a few stones are trapped to ensure they understand the question. The methods they used to solve it were very illuminating.

Beginner candidates tended to try to optimize for following paths. They'd move as far as they could in a single direction then turn and repeat. They'd miss branches and backtracking was very hard. They wouldn't realize they had to keep track of visited spaces and had to be spoon-fed that scenario. These candidates would not know how to write unit tests, or would say they'd test "edge cases" and literally only test the edges of the board.

Intermediate candidates tended to use BFS or DFS, sometimes using a stack or queue, sometimes with recursion. At first they wouldn't realize they needed to keep track of visited spaces, but they'd notice it themselves and have a solution for it. When asked for unit tests, these candidates would always start with a bunch of input validation, and end with few actual unit tests.

Advanced candidates would reason about the board as a whole. Often using BFS or DFS to build an answer key and then looking up the answer for that. Or maybe they'd use BFS or DFS to find the solution, but it was a nice clean implementation. These people had a good sense of what kind of unit tests the code needed and knew that input validation and unit tests were different.

I had candidates who didn't finish but still got a hire recommendation, and I had candidates who did finish, but it was such a dumpster fire that they didn't get a hire recommendation.

[elijaht]

Current Googler. I think these are reasonable standard for the vast majority of hires. For the most part The large FAANGs just need talented or high potential generalists. I don’t think leetcode has a direct correlation to what I do day to day but I think it is a reasonable way to hire for that at scale. Anecdotally I do think the talent here is quite high

I would agree with comments here saying leetcode isn’t appropriate for super senior roles. I am not privy to what hiring at these levels look like though. That being said I think most people overestimate how senior or deserving they truly are- for even staff engineering positions there are enough reasonable candidates that I think a more standard interview works

I will also note that for all but the lowest level there is some component of system design in an interview loop. This I think is a better test for most roles

I don’t think leetcode is perfect and at smaller companies doing it instead of a more bespoke interview is lazy and suboptimal

[lapcat]

> For the most part The large FAANGs just need talented or high potential generalists.

Is this actually true? It seems to me that BigCos have a huge number of very specialized roles, and a corresponding huge need for very specialized talent.

[notacoward]

In my experience outside knowledge can actually be a detriment at a FAANG (FB in my case but retired now). They want people who will learn their tools, their ways, etc. so yes, talented but "unformed" people are their ideal candidates in the great majority of cases. Specialists - such as myself - are brought in only as needed, and often find that trying to apply experience gained elsewhere gets them odd looks at best. The NIH is very strong.

[elijaht]

Not for the vast majority of software engineers, in my experience. Most teams do have some type of specialization (even CRUD apps often require some detailed knowledge of scale, localization/i18n, etc) but that just leads to the expectation that a generalist will need to spend some months onboarding. I do think our hiring process captures a lot of the skill needed to onboard and be successful in this situation

There definitely are a handful of roles that require more specialized backgrounds. I would say that leetcoding for something like that is a disservice to both parties, but I think that is a small fraction of the overall workforce

[lapcat]

The question, I think, is whether the quality of work of a generalist after some months of onboarding is going to be comparable to a specialist with years of domain-specific knowledge and experience.

[dave_sullivan]

I have no problem with programming questions during an interview for a programming position. Show me some issues from your issue tracker. What kind of stuff would I be working on?

But leet code questions are not that. And I don't appreciate the interviewer acting like I'm an idiot or lying because I don't do well at them. Just tell me about the job and let's talk about that. It's really not that complicated.

[devoutsalsa]

I’d love to tell you about the job. Right after you write a reversible weight balanced binary tree in Java (points deducted for verbosity).

[the_biot]

My personal pet theory is that they select for people willing to put up with completely pointless bullshit, since that's what you'll be faced with every day in gigantic companies like this.

[mountainriver]

Exactly

[conjecTech]

I'll voice an unpopular position: There are positions where you use all of these skills regularly (data structures, algorithms, system design), and they are some of the most satisfying, respected, and well-paying in tech. They are also uncommon.

For context: I've done 3-4 full job searches ranging from new grad to Staff+ that included FAANG companies, and received offers each time from some but not all of them. I've been fortunate to have other offers I preferred each time, though until recently this has meant accepting compensation below FAANG-levels.

One of the primary reasons I haven't taken a FAANG offer is because of the over-scoped nature of most of the work they offer. The positions at these companies often involve squeezing more profit out of existing successful business surfaces by fiddling with the knobs. If you're working on a surface that produces $10M in revenue each year, and you can improve it by 10% each year, you can justify a good wage. That kind of straightforward investment is exactly what middle managers like.

However, jobs like that will seldom see you architecting or changing systems at a sufficient scale where these skills become relevant. There are undoubtedly exceptions at these companies. I'm not making a universal statement. But having watched the careers of people smarter than myself both inside and outside of FAANG, I've seen a considerable gap emerge in the technical abilities and accomplishments in favor of those at leaner companies.

I think this explains the experience of most engineers going through this. To be Jeff Dean, you need all of these skills. Because of this, OG engineers like him made it part of the recruiting rubric. But you are unlikely to become Jeff Dean by joining Google now. If that is your goal, my advice is to seek out companies with the highest ratio of users to engineers. A value of 1e6/1 is a good target. These places probably look like dumpster fires because of their scaling problems. But they need these skills and have no alternative than to let you work on the problems that require them. Make sure there are a couple of people there who have done it before that you can learn from and hold on for as long as you can.

[throwaway81523]

I would say that you can be a good dev without being so hot at those sorts of problems. But if you very well at those problems, you are pretty certain to be a good dev. So the process gives false negatives but not very many false positives.

[notacoward]

I went through this process at 52, i.e. not with all the algorithms still fresh in my mind from college. Also, this was despite the fact that I already knew what team I was being hired into ("hard allocated" in FB lingo and very rare) and had already proven my relevant skills by being a maintainer for the open-source project the team was built around. I didn't prepare, and had no trouble passing.

The interviewers did a pretty decent job within the constraints they were given, but it really was an almost complete waste of time for all of the reasons others mention. Even for a junior developer - who the process is designed for - it barely seemed to touch on the skills they'd actually need to succeed there or anywhere. Maybe it also weeds out impostors among those with no searchable record, but if that's the purpose then such an interview should only be done in those cases and skipped for those who have plenty of evidence that they can do the work.

The design interviews were more useful IMO, and less skippable, but those don't seem to be the topic here.

[xiphias2]

As a person who was both working on the Ad Shopping backend at Google where we had to keep 25ms latency on the 99.9%-ile of requests, and a startup at some other point in my life, in my experience the job and the knowledge needed is quite different when serving billions of users and hundreds of users (understanding the interaction of complex code bases vs speed of execution at a startup).

[mettamage]

So do the leetcode-style interviews help in assessing that experience that you need for Google?

[xiphias2]

Maybe 5% of my work needs that experience, the rest is protobuffer data copying and following / writing documentation.

But what's more important that I loved to work with other people who had great mathematic and algorithmic background, and I trusted them not to make my code perform worse.

At the startup I had a colleague who was making a lot of mistakes (and dating multiple girls during work hours on his phone instead of focusing), and it was very frustrating to find out that I spent a lot of time debugging these mistakes.

[nunez]

On one hand, I think the problem space of the leetcode interviews is helpful, yeah. At that scale, implementing an exponential-time solution where a logarithmic-time solution would work can be costly. Knowing how to optimize the kernel and application call chains to get every ounce out of your resources instead of scaling out endlessly is also helpful, since at this scale scaling out would be incredibly expensive and likely limited by physical space.

On the other hand, a lot of these problems are solved at the FAANGs. For example, at Google, if you need a database that can span to petabytes of data with sub-second queries, you use Dremel and call it a day. If you need a super-fast library for sorting maps, there are probably handfuls of libraries to choose from. So there isn't a guarantee that you'll work on a team that requires this amount of knowledge.

That said, making interviews super difficult and all-encompassing upfront should make lateral transfers really easy, since theoretically you're capable of doing anything.

[xiphias2]

While you are right that these libraries are super optimized, even adding a few features to the machine learning model added significant latency to the ad serving system (about 0.1ms at 99%-ile, which was a blocker for getting into production).

What the more senior engineers showed me that the trick is to understand other parts of the request and find optimizations that I can apply at those stages, and put in the same experiment that I want to launch instead of hyperoptimizing my own code.

Of course you are right that I myself was looking for more technical projects (the only problem was that my team was the one working at night and weekends as well, which I refused to do at that point in my life, as I wasn't in my 20s anymore).

[taf2]

Interviewed 2007 at Google it was super fun. I believe there where 4 interviews back to back each was a super neat problem. The hardest one was a walking of the DOM without recursion - this was really hard to express on a whiteboard and even figure out. Interacting with the other engineers was amazing you could tell they were brilliant and it was just overall good energy. The lunch was really good and yeah. I probably would have accepted the offer if I didn’t get scared of the idea of relocating to CA… happy with my choice but still think it would have been pretty cool too… I don’t get why people knock this style interview… I think it’s pretty fun… if I recall at the time they just brought you a problem to work on that was related to what they are working on to see how it’d be like to work with you on the same problem… I hear googles changed a lot since then so maybe it’s not as good energy - but I think working problem solving style interviews are probably the best way to decide if you will be a good fit

[nojito]

I'm still convinced that whiteboarding is the only way to get a glimpse into how a dev thinks and communicates which for the most part are the two most difficult aspects of the job.

[nicoburns]

I don't think it's whiteboarding that's the problem. It's whiteboarding obscure leetcode algorithms. I've been asked to whiteboard a system architecture before, which was IMO much more reasonable as it's the sort of thing I would have been doing on the job.

[rtp4me]

Agreed. And, I would like to add, the act of white boarding implies you standing in front of strangers trying to think on your feet. Some people are not as comfortable talking to an audience like that. Maybe a suggestion is for everyone to sit down and draw out the problem/solution on a piece of paper.

Or, how about a reverse white-boarding session? Let the interviewer draw your info on the board while you sit down. Sounds odd, but this allows you to (a) verbalize the problem/solution for someone else to understand and write it down, and (b) gives you the opportunity to see the bigger picture without getting too close to the board (forest, trees, etc).

[shafyy]

Completely agree

[wiz21c]

When hiring, besides other things I asked for some test code. The test was to code a recursive ls from scratch but in a professional way. The candidate was put inside our team, had access to all our tools and the web and had 45 minutes to do the thing. We specifically told him that he can ask question whenever he wants. Admittedly, that test was not intended at PhD's in CompSci.

You'd be surprised at how many people fail that test.

Things we were looking at:

- is the code correct

- can the code be explained clearly

- does the code scale (memory / speed)

- is the code portable (Solaris was still at thing) ?

- how many external resources were used (copy pasting code from the web is a perfectly acceptable solution)

- unicode support ?

- automated tests ?

[TruthWillHurt]

I don't mind whiteboard tests, or tests in general, but that is an example of a terrible test.

You want production grade code delivered on the spot? AUTOMATED TESTS?!? I wouldn't want to work for you.

[wiz21c]

it's more like how far the guy goes. Admittedly, an auto test is quite above the average :-) I've never put someone aside because of that.

Production grade code is, in a big part, a matter of good habits. There's no reason those habits can't show up during a test. Especially when the test is very easy.

[devoutsalsa]

Is there a different way to say “see how I think”. You can’t see how I think. And even if you could, you’re only seeing how I think when you’re staring at me in a contrived setting while I exercise a skill I rarely practice.

[nojito]

There's nothing contrived about writing code and talking about it.

[warrenm]

It's absolutely "contrived" to write code in front of a group of strangers talking about whatever happens to be running through your mind at the moment in the 17.2 minutes that are left in the session before you break for water and a bathroom trip

[clintonwoo]

Whiteboarding was great before the pandemic. Especially if you are allowed to whiteboard first then code up on PC (which is easier than coding with a marker).

Nowadays with the virtual interviews it can be hard to visualize, describe and explore some problems with virtual drawing tools..

[mountainriver]

What if they have open source work? Can’t you look at that and the comments to see how they interact?

[nojito]

No because talking and writing are two separate skills.

[mountainriver]

except in remote environments where most things should happen async... and most dev work is remote...

[nojito]

Nope. We meet/touchbase/connect with our remote workers all the time. Not sure what you're talking about honestly.

[mountainriver]

Not sure what your talking about honestly, but I could chat with someone about their OSS work and get the same understanding of them as a developer

[marssaxman]

When I interviewed at Google back in 2011, it did not feel like I was being given "tests". They were just... interview problems. Sure, the process was more intense than it has been at some other places - I came away from the interview loop feeling like it had been the hardest day of engineering work I'd done in a long while - but there was nothing unreasonable about it. I wasn't being hazed; it wasn't adversarial; it was just a variety of problems to think about and work on.

I've never really understood the hate. Either I've consistently had a different experience with interviews, or the people complaining have a really different idea about what their job is supposed to be.

[nunez]

The whiteboarding questions are designed to test (a) whether people actually know how to code or whether they are crippled by their IDE for everything and (b) whether they can think through why they write the code that they write instead of using whatever code they can find to get to a solution.

The problem with whiteboarding (for me) is that it optimizes for people who are good at studying for and passing tests instead of people who are actually good for the job, which, ultimately, makes it a suboptimal determinant of how well the candidate will perform once they are hired.

I think that whiteboarding + delving into past experience is a great combination for screening. You can't bullshit experience.

[greatpostman]

This isn’t true. They test for memorization, willingness to study computer science at length, and if the above two aren’t present, intelligence

[tyleo]

It’s a double edged sword and can depend on the question. For example, I’ve gotten a few “brain teaser” questions which are just dumb. On the other hand I’ve also had an interviewer in one of these loops sit me at a computer and build a small game with a debugger. Building the game was the to most “work-like” experience I’ve had in an interview.

Edit: I’ve both worked at and interviewed others for Microsoft. On my team you could basically ask what you want. My sense was that bad questions were more a product of laziness on the interviewers part than corporate policy.

[ekleraki]

I am current in the process with FAANG for an MLE position.

One of the interviews today was focused on the task that I will be working with, we started from a simple instance of the problem, and saw how we could improve upon it. The task revolved around querying and identifying entities. We worked through multiple instances to see how we can improve on the initial approach, or how to handle odd cases.

After that some leetcode was included.

The other two interviews were more on general technical and ml stuff.

I found this approach to better than other kinds of interviews I have gone through.

[lynndotpy]

I tested and passed an intern whiteboarding for Google back in 2016.

The process involved a few automated algorithms questions, and then later, a whiteboard interview.

At the time, I was actively studying exams involving DS&A questions, so "find an algorithm that does X in O(Y) time" was a big chunk of what I was doing as a person.

If I wanted to pass now, I feel like I'd have to waste some time, say, remembering exactly how to implement a priority queue. That time could probably be better spent on learning other skills.

[blisterpeanuts]

I’m being recruited to interview at Amazon but I’m not great at timed tests; I do best when I can spend a few days thinking about a problem, researching best practices and proofing code snippets. I guess I’d likely bomb the interview, though I’ll still take a look at the preparatory materials.

Meta/Facebook has a hiring freeze right now, as do some units of Netflix and Amazon. Maybe it’s not a great time to be seeking a position in a FAANG anyway, except for a few elite positions. Feels like that ship has sailed.

[erulabs]

I interviewed at Facebook and knew the exact moment I was rejected. I was asked to whiteboard a bit of code, and feeling a bit of “when in Rome” I decided to use PHP - I mean - Facebook, right?

The interviewer loudly scoffed and pulled out his phone before I was finished writing. I was told later that he “would have preferred a systems language” - suppose I could have been told that - would have happily swapped to C! The only job I’ve ever been turned down for in my life!

[diehunde]

Big tech companies get so many applications that they struggle to find interviewers. Hence, it's pretty common to get random engineers from random teams to interview random candidates. This is a burden for most engineers that need to focus on their work instead of interviewing people several times a week. Do you think these engineers care about getting to know you or asking fair questions? For many of them, having a script is much easier.

[rychco]

If you’re applying for a generalist position, it makes sense I guess (but still absolutely sucks don’t get me wrong). If you’re applying for a more specific role / area of expertise and they still give you whiteboard interviews rather than examine your previous work or portfolio, this screams red flag to me.

[giaour]

The interview process sucks, but anything that provides a veneer of objectivity makes it less likely you'll get sued. I'm guessing the current system is as much a brainchild of staff attorneys as it is one of staff engineers.

[jmartin2683]

I would never work on a team full of people who got their jobs solving riddles. If someone wants to see more than my Github profile or a solution to a real problem they're actually facing, they're not my people.

[ctvo]

I feel the same way about whiteboarding as I do about capitalism: It's not perfect, but what's a viable alternative? And like capitalism, it's a spectrum. Most companies could cut back on pure leetcode style questions, but ask something more practical that can still be whiteboarded in ~40 minutes.

Take home assignments, deep dive chats, pair programming, temporary contracts all have their own drawbacks. I've tried everything but temporary contracts.

We're measuring along a few dimensions:

- Can someone fake this expertise?

- What's it like working with this person?

- What's their general intelligence?

- What's the depth of their prior knowledge in computer science?

- What's the scope of the problems they've solved previously?

For both the candidate and the company:

- How long does it take to conduct the interview?

- How much money does it cost?

- How much legal resources?

You can assign points to each interview type, and at scale, I'd take whiteboarding over the alternatives.

[mountainriver]

Here’s a better one, show us your open source work. Don’t have any? No problem you can create some in the same time you would study for Leetcode but it would actually matter

[ctvo]

> - How long does it take to conduct the interview?

(for the candidate)

You're excluding a slew of people who either don't have the time or inclination to start and possibly maintain an open source project. The assumption here is leetcode requires an equal time commitment, but that differs greatly from person to person. This is very similar to take home assignments, but even more of a time / commitment sink.

They'd also need to pick an appropriate project that demonstrated the technical depth and scope an interviewer would be interested in. You're also hoping the interviewer will do an appropriate deep dive into the code base to understand it and judge it correctly. Finally, you can't be sure the person actually wrote the code. I know it sounds ludicrous, but I've seen outrageous things people have attempted to know it's a legitimate concern.

[mountainriver]

> You're excluding a slew of people who either don't have the time or inclination to start and possibly maintain an open source project.

And leetcode isn't excluding a bunch of people who don't have time or inclination to memorize puzzles?

> They'd also need to pick an appropriate project that demonstrated the technical depth and scope an interviewer would be interested in.

Then build useful things, this is how the world actually works

> You're also hoping the interviewer will do an appropriate deep dive into the code base to understand it and judge it correctly

Thats always the case with every interview style

> Finally, you can't be sure the person actually wrote the code

You should be able to tell this easily by talking to them about it. If you're at all unsure, dig deeper on why they did things, someone who didn't write it wouldn't be able to answer hard questions.

[isbvhodnvemrwvn]

It's also impossible to compare candidates if you are hiring for dozens of openings at the same time.

[mountainriver]

Interviews are always biased, chances are dozens of candidates wouldn't get the same puzzle, and dozens would get different interviewers that help them in different ways, and the candidates may or may not have the puzzle memorized which has literally nothing to do with their actual skill.

Everywhere else in the world, when you hire someone, you ask to see their previous work. It is universally the best signal, you don't have a carpenter build a chair on site, you look at what they've built and talk to them about it. And you certainly don't ask them to build a chair in a style they have never done before, you just see if you like their style.

[ctvo]

> Everywhere else in the world, when you hire someone, you ask to see their previous work. It is universally the best signal, you don't have a carpenter build a chair on site, you look at what they've built and talk to them about it. And you certainly don't ask them to build a chair in a style they have never done before, you just see if you like their style.

This analogy is flawed. Software engineers work in teams on any project of worthwhile complexity, even open source ones. It's not simple to parse out what your contributions are.

To validate expertise, universally, everywhere else in the world, many professions have licenses, certifications, and governing bodies. They rarely take your word for it. See lawyers, doctors, civil engineers, dentists, architects, etc. etc.. Software engineering has none of these things, and until the field matures, we use adhoc methods. From prior experience, I disagree that the best method in finding competent engineers is to simply talk to them about projects. This is easy to fake, and you may even have colleagues you've suspected of doing so.

[warrenm]

sorry, but creating some open source work doesn't "matter"

If anything, I'd rather know that your side projects/hobbies aren't work-related :: it signifies breadth of character and intellectual curiosity

[mountainriver]

what? creating a useful project absolutely matters to the world a lot more than memorizing some leetcode problems

[warrenm]

Who said anything about a "useful project"?

Just because you spend 100s or 1000s of hours building something and releasing it on GitHub doesn't inherently make it "useful"

You might spend 30 minutes and it be "useful"

Or 10 years, and it be not "useful"

[aristofun]

Faangs won a lottery in their markets once.

Now all you have to do to work there is to win faang interview lottery :)

[Balgair]

Aside:

I wonder how FANNG execs feel about the answers here. Same for start-up execs.

[shetill]

seems like all high paying companies do whiteboarding. Don't know if it's good approach or not but that's the game they want us to play for money so we play it.

[hnfong]

I think there are a couple aspects.

Whiteboarding is a good proxy for general "intelligence" (similar to "IQ"). It doesn't test real world scenarios, but if you're looking for a smart person who knows how to implement code without having to rely on IDEs and autocompletion, this isn't a bad test.

That said, whether "smart" and "can code" translates to job performance really depends on what the job requires. For the FAANGs that does centralized hiring, this "job requirement" is basically the best they can do for software engineers, since more specific requirements run contrary to the centralized hiring process.

For the non-FAANG companies that cargo cult FAANG practices, it should be pointed out that it's really contrary to their interests to do it, since they're competing directly for the same pool people with less resources, even though they may not actually "need" the same people, and are in a position to hire more specifically for positions that they require. If I were hiring, I'd actually actively try to structure the interview process so that it will select for quality candidates that have a higher probability of being passed on by FAANG processes (or, in short, don't copy FAANG interview questions!).

I suspect there's also an element where salty interviewees overestimate the difficulty of the whiteboard questions they get asked. I'm not saying we should disbelieve them, but I've personally seen cases where the interviewee mis-interprets/mis-categorizes the question asked, and then complained about it. Also, Dunning–Kruger effect and that stuff.

That said, in general criticism of "FAANG-style" interviews is probably well grounded, but honestly, for the FAANGs that rely on these styles of interviews (as pointed out in some other comments, not all of them interview the same way), the inertia is so high that it's unlikely anything could change their practices, especially that it is in fact in a local optimum (there's nothing "better" if you do centralized hiring at scale). It's crucial that smaller companies don't cargo cult these practices though.

[lesuorac]

I think the theory and research [1] behind them is fine. You need a short question that will allow a candidate to demonstrate competency in many areas and that really restricts your options. A lot of the blogs posts I've seen really don't understand the process as there is a rubric the interview has to fill out that outlines and if the blogger thinks the whole interview is you get a problem and then you either give them an optimal solution or you don't then you're going to fail half the rubric. Also, I generally think that FAANG has done more time thinking about what makes for a good process than that w/e blogger has (teams of people do data analysis on this. I don't think I've seen a blogger even cite a paper).

I would argue it's mostly about filtering out somebody bad and not testing if somebody is actually really smart. This might sound the same but it's not. It's a Type1 vs Type2 error [2] situation and for the most part, FAANG is ok with a process that won't hire every qualified candidate as long as it doesn't hire unqualified candidates. But that's the ideal situation. A lot of people within FAANG do not like to do interviews but are pretty much forced to (or you get an arbitrarily lowered performance eval) so there's definitely going to be a lot of interviews done by a really disinterested interviewer and that's not going to be a good experience.

I do base my interview questions on a real problems and I've had a few interviewees ask me "if they'd ever use this at work" and I just ask them how they think X feature works and I've never gotten a response back from them after that ...

w.r.t. how long FAANG interview process takes (i.e. month+). No, this is outrageous but I don't have much visibility into where the problem is but it's not with the interviewers (average feedback is reported under 2 days for an entire slate).

Depending on when the blog was written they may also be very correct. Google was known for using rather un-job related questions [3].

[1]: https://www.semanticscholar.org/paper/The-Structured-Employm... [2]: https://en.wikipedia.org/wiki/Type_I_and_type_II_errors [3]: https://www.wired.com/2014/08/how-to-solve-crazy-open-ended-...