Ask HN: Devs who passed whiteboarding at FAANG: how do you feel about it?
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
145 comments
[ 3.2 ms ] story [ 207 ms ] threadIt 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.
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.
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.
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.
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...
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.
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.
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
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
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".
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.
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.
I think maybe some people are mistaking job interviews for university exams.
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
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).
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 ?
You want production grade code delivered on the spot? AUTOMATED TESTS?!? I wouldn't want to work for you.
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.
Nowadays with the virtual interviews it can be hard to visualize, describe and explore some problems with virtual drawing tools..
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.
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.
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).
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.
The notion that you figure out "if the person applying is actually really smart" is a 'just so story'.
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?
Yes, it's a form of hazing.
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.
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.
> 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
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.
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.
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.
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?
> 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.
What do you mean by possible?
The difference between possible and actual is actually what determines whether it's a contrived imagining.
It was not an expectation that you would transfer between such dissimilar areas, but that you could - that a successful hire could be given any problem, in any part of the company, and find a way to get useful work done there. Thus there was no point wasting interview time on questions about specific tools or frameworks: what's relevant is your ability to solve engineering problems.
I did in fact know someone at Google who went from some kind of big-data map-reduce oriented thing to an embedded device project. (Long time ago, details are hazy.) It wasn't "management roulette", he just wanted to work on something different, so he did.
I myself had been doing bare-metal embedded systems firmware before I went to work at Google, but the project I got assigned to work on was Millwheel, a large-scale streaming data processor framework. shrug
I understand that there are some employee-initiated internal transfers. Though I suspect those aren't necessarily automatically granted. What I don't see, though, is company management acting as if the engineers were all replaceable cogs who can be assigned to any project whatsoever at any time. That would be insanity, I think, because there actually is a great deal of value in experience and domain-specific knowledge and skill. Would you really want a company based on dilettantism? It sounds like — "Long time ago, details are hazy" — extreme jumps are the exception rather than the norm.
Can smart engineers learn pretty much anything given the time? Probably yes. I've learned many things over my career, and I'm sure I could learn more and different things if I were given the economic opportunity to do so. Nonetheless, I dispute the notions that generalists are somehow smarter than specialists or that BigCo assembly-line hiring identifies the smartest people. The advantage of known specialists is that they've already taken the time to learn what they are assigned to do, so the time between hire and high quality work is much shorter, maybe years shorter than throwing a smart generalist into an unfamiliar specialty.
Obviously if you're creating a new technology from scratch, there's less value in experience. But how many BigCo employees are actually doing that, as opposed to maintaining existing tech? Probably too many of the employees aspire to create new tech and don't want to maintain existing tech. Google in particular is infamous for starting new projects and then later abandoning them. (Google has the luxury of this wastefulness because it still has ye old search monopoly. Though that too seems poorly maintained, and many people complain that Google Search is worse now than in the past.)
I would say a big part of this is that BigCos such as Google are selling an ideology to current and potential employees. "We are the best of the best. Any one of us could design a whole new operating system." Yadda yadda. The ideology is part of the attraction of working there, even though the daily reality of working there doesn't necessarily match the ideal.
It's not about transitioning between skillsets now, it's about future proofing.
I went from doing corporate enterprise applications on Windows NT to embedded systems when the PocketPC came out. Mobile computers didn't exist when I interviewed but because I was a generalist they had confidence that I could pick up the manuals and figure it out.
Note - I didn't work for FAANG because F and N didn't exist and A was a bookstore and G was a search engine :)
I refer you to the guidelines: https://news.ycombinator.com/newsguidelines.html
> because I was a generalist they had confidence that I could pick up the manuals and figure it out
Why you though? That's the point I'm making. Of course a smaller company with limited resources may have to repurpose existing employees. But when a BigCo with a massive budget needs to do something new, they can assign existing employees with the closest expertise, hire new employees with relevant expertise, or acquire other companies. It's unclear why a generalist with no domain expertise would be preferable.
When GDPR came out, some companies employed experts to deal with it but I expect most companies just gave the job to some unlucky employee.
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?
“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.
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.
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.
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
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.
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
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.
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.
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.
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.
(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.
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.
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.
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?
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.
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.
(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.
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.
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.
If anything, I'd rather know that your side projects/hobbies aren't work-related :: it signifies breadth of character and intellectual curiosity
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"
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-...
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.
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.