Ask HN: Can engineers from Google or Facebook solve whiteboard questions easily?

I work for Google and have never been good at the "Here's an NP-hard problem you haven't heard of, write correct code for nlogn solution on whiteboard in language of choice" question. I had to train extensively (reading CLR, practicing) to be able to pass.

However, large numbers of engineers at Google are very good at solving whiteboard questions. A lot of it comes from practice, a lot comes from knowing the common problems and solutions, and a lot comes from knowing the algorithmic primitives from which modern algorithms are born.

For many, whiteboard questions are "fun"- in the same way my parents like to do crossword puzzles for the intellectual exercise, Googlers like to discuss challenging, abstract-but-related-to-ads-or-search questions.

I work at Google and no it's not easy for us either. I've heard many of my coworkers joke that if they went through the interview process again they'd probably fail.

That said I see two kinds of interviewers. One kind (the good kind) takes a medium difficulty question and uses it to explore the candidate's coding, algorithms, communication, and problem solving skills.

The other kind has a super hard question with a single algorithmic solution that tells you nothing about what kind of engineer the person would be. This kind of interviewer takes too much pleasure in being a gatekeeper to Google.

I often do, both for fun and to prepare myself to give a question I'd like to use in an interview. The thing about interview questions at Google is there's a very fine line they need to walk: if they're too easy they give no useful information about the candidate, and if they're too hard they can never be solved in 45 minutes, again yielding no useful information. You also need to be able to provide some hints, because the vast majority of candidates need a prod in the right direction now and then.

As someone with access to the entire canon of Google interview questions, I've gone through the 20 or 30 with the highest rating, and none of them are ridiculously hard. The general pattern is either 1. a coding problem, meaning a relatively easy algorithm with plenty of opportunities to screw up the implementation so we can see how well you code and how well you catch your own errors, test your code, etc and 2. an algorithms problem that's really just a dressed-up version of some basic algorithm like BFS or dynamic programming so we can see if you can make the leap from theory to application.

Obviously I'm at an advantage here because I've seen most of the questions in use today, but whenever I encounter a new one I can intuit what's being asked and what it'll take to solve. I'm sure other companies have different sorts of questions that optimize for different things, but for our questions once you do enough of them you can sort of do any of them.

--

By the way, in my experience, those seem to be the biggest pitfalls for both job candidates at Google and programmers I meet in the real world. Sure, you crammed algorithms before you came here, but can you apply them in any real-world way? Sure you know your web/mobile app framework back to front, but will you hit a wall when asked to do something novel? Sure you can write a for loop to iterate over a data set, but will you fall on your face when that data set is petabytes in size?

I've become good at Google's questions because they generally test for those two things: nitty-gritty coding skills and an ability to generalize basic algorithms. The best candidates are those who know their algorithms inside and out, have the ability to break down and transform a problem until they can apply something in their toolkit, and have the coding chops to translate their concept into an implementation. All skills which, you may notice, make for a good engineer.

If you've ever wondered why we still do whiteboard interviews, that's why. Except you can use a chromebook now if you prefer, but you get the point.

I currently work for Google, and enjoy whiteboard interview questions. When the questions are well designed there should be a relatively trivial, brute-force solution. As that solution is explored, it should highlight a bottleneck (time, space, etc.) that leads naturally to a more elegant solution. I really enjoy the excitement of finding the inflection point between the two. In addition, be aware that Google now offers Chromebooks for interviews at many locations, in case folks are more comfortable typing than writing. A recruiter can confirm if that option will be available. (See https://careers.google.com/how-we-hire/interview/#onsite-int...)

From the average skill level of Google engineers I know, I would say yes, most would do a very solid job on the average interview question.

However, you probably wanted to know if that means that they would all get back in if re-interviewed, and the answer is no. Google is famous for tolerating huge numbers of false negatives in exchange for a small reduction in false positives. So, by definition, many would fail, even if they are capable Google engineers.

When I interviewed, I knew nothing of this process. Which was probably good, it would have made me a lot more nervous if I had know what lottery I was about to enter. In fact, I was pretty arrogant, seeing that typical questions were "just CS", and thinking my CS knowledge was pretty solid, I didn't even do any prep work. So I was probably pretty lucky to get in.

My own assessment of the 5 interviews I had were that 3 of them went very well. 1 went so-so (the interviewer assumed I was a webdev and ask me all sorts of specific server balancing questions, whereas I have worked mostly on compilers and game engines.. I managed to do ok-ish since I do know distributed systems). The final one I felt went badly since there I actually didn't manage to solve the problem the interviewer asked (it was one of those more puzzle-y questions), but I guess I somehow did ok, since I did what you're supposed to do in such a situation: show that you're a good communicator and problem solver even when you don't know the answer.

I was dissapointed in all these interviews since I was hoping for interesting questions specific to me (how did you implement this type inference algorithm?) which never came.

Of all the interviews I've conducted for Google since, I've only had a 1:40 ratio of seeing people being accepted, even though plenty seemed highly capable to me. Usually some other interviewer didn't have quite as good a time with them as I did. You really need to make all of them happy to pass.

To other answers that joke that these interviews are the hardest thing you'll do at Google, I'd like to disagree. At least in the teams I've worked, I've done things that thoroughly stretched my abilities, way beyond the level of interview questions. Of course they're of a very different nature, but that is the point: interview questions are very distilled, idealized, and problem solving in the real world is very messy, and to my mind at least, much more interesting.

What do you mean by "whiteboard questions"?

The ones I had at my FB interviews are questions I would describe as "any competent engineer should be able to solve most of these in an interview slot" sort of questions — Simple data structures (sometimes explicit, sometimes implicit as part of the problem statement), simple strategies (breadth first, depth first), and a basic understanding of time (and space!) complexity.

Of course, you can hike up the difficulty a tonne (e.g. by replacing plain binary trees with red/black trees) and progressively fewer people will be able to solve those, but in my experience that's not common in an interview environment at FB.

Ultimately, the fact that the interview process includes whiteboard questions means that people at those companies _do_ perform decently (for some definition of decently) at those problems — that's how people are selected.

The question I recently got that I found annoying was this: Given input (4, 2, 3, -1, 5) and output (-30, -60, -40, 120, -24) what's the function between them?

I don't actually mind doing whiteboard interviews even on minimal prep. I've gotten a few of the "flagship" company offers and failed a few. I think part of it is internalising that nothing is going to guarantee you anything. You can always hit a question you bomb on and have an interviewer that will move on or bury you for it.

Phone screens are 2-4 questions and on-sites can add another 6-10. A 5% bomb rate for an on-site question will put you into the 60-70% pass rate.

I'm confident that if I do all the interviews I'll land atleast one offer but if you're putting all your eggs in one basket you're going to have a rough go of it.

I worked for FB. I like the whiteboard problems and many other engineers like them too, and I enjoyed discussing or solving similar problems over lunch. That's probably why they're so prevalent in interviews -- I don't believe they actually predict a candidate's success in a company. Btw in college, I used to compete on websites like topcoder, spoj, etc for fun. The interview processes of many companies drastically favor ppl who did that in college, at least while hiring in the <10 year experience range.

edit: also worked for google, same story

edit2: I believe most people can learn to solve these problems because a lot of it is mixing and matching algorithms/techniques that you've practiced. It just takes time and practice and exposure to a wide variety of problems and crucially, confidence. I've seen people who somehow strongly believe that they're not the "algorithmic type" and will never be able to solve these even if they spend months working on it. :( I've tried and failed multiple times to convince those ppl that this is a very learnable skill.

I came across a guy on Reddit a while back who was currently employed at Facebook. He thought he'd try making a video of him doing one of Facebook's interview questions thinking it'd be easy for him to do. He stumbled through the problem and didn't end up solving it in the timeframe that would have been allowed.

It was good of him to still post it but it showed that someone currently employed at Facebook would have been screened out at the phone call stage had he applied again without any preparation.

There is a great video lecture where a guy talks about how tough his committee was, and they denied a series of packets only to be told that the packets were theirs! Very reassuring.