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 have worked at Google for 7 years. I am a SWE and mostly agree with the parent.
I am, I think objectively, a pretty good software engineer and often couldn't solve my peers interview questions in the time allotted. I try to do my part by conducting interviews with questions that I think demonstrate the ability to actually code and think abstractly as opposed to regurgitating some random algorithm that has been memorized. I ask a simple CS 100-200 level, one-word-answer question about an algorithm and then move on to a coding question.
Despite the difficulty of some of the questions that others ask, often the interviewer wants the interviewee to pass and so will throw a hint. It's important to keep commicating because that is how those hints will be delivered.
Ironically, I never interviewed because I came in from an acquisition. Yes, I was very lucky.
Here's my real question: How often do you solve those kind of whiteboard problems in your daily work? Obviously, you'd never be forced to solve them in 45 minutes while being judged, but how often are you actually solving computer sciency kind of problems in general as opposed to solving more software engineering type of problems?
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've heard many of my coworkers joke that if they went through the interview process again they'd probably fail.
I’ve heard this joke at a lot of tech companies. Also, “the hardest thing I’ve ever done at my job was pass the interview.” Just shows how divorced from day-to-day work skills interviewing has become.
I think most tech companies severely overestimate the cost of false positives, particularly in the USA where it’s trivially easy to fire someone who turns out to be a dud.
Also think it represents an opportunity: if you could reliably figure out who made it to the interview stage at these top companies but did not get an offer, you could forego your recruiting expense, simply hire all those people and likely end up with a well above average team, minus the few false positives.
> I've heard many of my coworkers joke that if they went through the interview process again they'd probably fail.
I don't see how companies that claim it's hard to find talent can be OK with a system that would reject more than a small portion (<5%) of their current productive engineers.
I also work at Google and what mystifies me when I do interviews is just how consistently people manage to screw up even the medium difficulty questions. I used to love asking this question until it was banned:
This is a great question because it has several levels of solutions:
1. A recursive solution that iterates over all sequences, exponential time and logarithmic in space. Interviewing for T3 (entry level, think college grad), getting only this far in 45 minutes earns a "leaning no hire" in my book.
2. The above solution except with memoization, which reduces the runtime to linear but requires linear space. This one earns a "leaning hire" from me.
3. A dynamic programming solution that takes linear time and constant space. This one gets a "hire" to a "strong hire," depending on the elegance of the implementation and the strength of the discussion we have around it.
4. A logarithmic time solution involving adjacency matrices, matrix multiplication, and binary decomposition of numbers. I've never seen anyone get this and I only learned about it after months of asking this question.
It's shocking how few candidates actually got as far as solution 1. I kinda want to open this up to the HN comments section, because this does not strike me as a brutally difficult problem, but the rate at which people fell on their faces when presented with this question suggests either something about our interview process or about the candidates we interview.
EDIT: A clarification about “getting as far as” a particular solution: I’m not sitting there stone faced taking notes, I provide hints and prods and suggestions to push candidates toward more optimal solutions. I want the candidate to get as far as possible because it feels good to watch someone succeed, but oftentimes they run out of steam or take forever to implement their solution. In particular with respect to solution 1, if that’s as far as a candidate can get despite my recommendations, that’s not a good sign for their algorithmic ability.
Personally I find that I can get a lot more useful signal from simple practical problems (eg "take a .txt file as input, modify all the words which contain the letter 'q' to be uppercase, write the results to a new file") which have a lot of room for expansion (What if we instead want to capitalise each word where the word after it contains a 'q'? What if we only want to modify the third instance of each word? What if the .txt file is too large for RAM? What if a single 'word' is too large for ram and the letter q is right at the end of the word?) -- starting out with something that any programmer should be able to solve in one or two minutes, and then cranking up the difficulty; adding in bits where a strong algorithmic coder has an opportunity to come up with a more efficient solution, but it isn't just a binary "has the candidate memorised the appropriate algorithm yes/no?".
(Example question made up off the top of my head because NDA, I haven't actually given much throught as to if it's a good question or not, just giving an example of "question which starts simple and then you can add complexity on top")
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 kinda agree but think that you are overselling the signal generated. We have internal data that we can't discuss here that throws some doubt on the signal from whiteboard interviews of the type described above.
> if they're too hard they can never be solved in 45 minutes, again yielding no useful information
I strongly disagree with the assertion that you get no useful information from an unsolved problem. The goal of giving a candidate a problem should not be to have them solve it. The goal should be to learn how they approach a problem, think it through, and work on solving it. Actually coming up with a solution is the least important part.
As an interviewer I've intentionally given people problems that would take more time than they have. I'm always upfront about it, making sure they know they may not solve it and that they should get as far as possible while explaining their choices.
As an interviewee I've been dinged for not solving problems. The reason why was because I spent most of my time talking through my approach and planning how I'd solve it. Without proper planning you get sloppy code, technical debt, and miss deadlines. Planning seems to be greatly undervalued in tech, especially in small startups.
> 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 also asked a question in HN yesterday. It looks like there are more questions on data structure and algorithm for big data. However, books I read don't focus much in this area. As I haven't worked on big data before, that would also be a challenge for me.
> 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.
I mean, I guess, but in the many hiring discussions I've been on I found that the interviewers who asked those questions and based their feedback on them had very noisy signals. They frequently gave "lean no hire" feedback on our best hires. The interviewers who actually asked questions relevant to the work had much better signals.
>>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 understand what you are trying to say here. But how many candidates are capable of inventing path breaking algorithms in 45 minutes, just to crack a job interview? I guess only a countable people in the world could achieve a feat that amazing, where they could invent a totally new novel algorithms from the scratch in 45 minutes. If I'm not wrong the very people who invented these algorithms went through years of research to publish them.
Now if you are not testing this, and just testing if the person knows an existing algorithm. Then really this a scaled version of testing the ability to memorize multiplication tables.
There is nothing novel in merely knowing an algorithm. And you also have not tested a person's ability in inventing an algorithm either.
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...)
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.
That’s because the FB process explicitly optimizes for speed. I recently finished a loop where I solved 2 problems optimally in 2 interviews and 1 in the last one and I was rejected.
The speed required makes me skeptical many people can solve these problems in the required time without luck of having seen similar problems before.
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.
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.
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.
And there are people who just find these stuff boring/mundane and also don't think it is worth to allocate months for preps. There are lots of other great opportunities so why bother?
I am a SWE at Google, and yes, most Googlers are pretty good at solving whiteboard problems. It's not like we are born with those solutions in our heads, but we enjoy solving those questions especially with other people. It's a lot of fun to "explore" answers to these questions, and that's what I think interviews are all about.
I know HN hates whiteboard problems, but just like anything, you get good with it if you're having fun solving them.
We don't hate whiteboard problems because they aren't fun. They're obviously fun for some people.
We hate them for interviews because they're a terrible signal for hiring, they're often poorly administered, they're humiliating, they discriminate against introverts, and they've become frustratingly common.
They unfairly mess with people's livelihoods. It is a really big, life-altering issue for some people.
I also want to see how you guys solve these problems. People on youtube videos already know the answer. They just told you how to solve it. But I can't see how they approach to get the answer. I think that part is the most interesting and valuable part for non-talent like me.
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.
I have no info about whether Google/Facebook programmers can solve whiteboard questions easily so I expect this comment to be down voted but ...
I'm consistently surprised by the fact that, despite hiring programmers who are the world's most elite, Google's products and services are just kind of ... plain/average/boring. The products and services are far less amazing than Google's engineers.
It's like Google takes in geniuses but outputs kind of boring, standard, average quality products and services with a surprising number of problems and deficiencies.
I worked with a guy, Bob, in our college computer room. Bob had returned to get his BS after many years in industry. He had great stories. He also had great advice. He taught me that you can learn a lot about how a company will treat their employees by paying attention to the way they treat you during the interview. He suggested several sign that indicated it was best to just "walk away".
If you go into a restaurant for a professional lunch meeting and they have a ball-pit / swing set /etc. it might not be the most professional place to hold the meeting. Just walk away.
If you go to a 5 star restaurant and they want you to wear a clown nose (Everybody Does It!) Just walk away.
The big scam is "We hire the best and the brightest". "We mandate a whiteboard test (Everybody Does It)". It is my opinion (based on experience) that companies that insist on a whiteboard test, despite years of programming on your resume and open source code, are either Ball-Pit companies (who don't know what it means to be a professional) or Clown-Nose companies (who know what it means to be a professional but still treat you like a commodity). Just walk away.
When you object, please reference one study in a journal that shows that whiteboard tests are effective in any measure when used during interviews.
I understand why Google does it. I've even interviewed there. They get thousands of resumes (which they never read, at least nobody did at my interviews). They have to weed out the "learn coding in 6 weeks" crowd. But you're a professional. You should expect to be treated like one. You don't ask your surgeon to cut up hams in an interview. You don't ask your builder to nail two boards together. Professional accountants are not interviewd by bank tellers and ask to count change.
Google, like Microsoft before it (remember the "why are manholes round? quizes?"), have combined the marketing claim "We hire the best and brightest" with the ball-pit mentality of whiteboarding. Google HR (sorry, People Resource?) SHOULD be embarrassed but apparently they, and upper management, LIKE ball-pits.
A real professional interview involves a discussion about what the company does, what it current problems are (aka why are they hiring), and a discussion of if you, as a professional, have the skills to solve the problem. What do they need? How can you contribute? It is likely that your interviewer has no idea what you are being interviewed for and cannot answer these basic questions.
We, as professionals, should consider whiteboarding as an insult.
I'd have to "just walk away" from the entire industry, since I've never once in over twenty years had an interview which did not involve a demonstration of my ability to reason through a problem and communicate a proposed solution using conversation and a whiteboard. I am a professional, yes, and thinking about problems and communicating about solutions is my job; why should I be offended that someone wants me to show them how I work?
Why would I ever want to hire someone incapable of demonstrating their skills in such a simple, straightforward way? If you can't solve a toy problem and explain your solution, or at least have a conversation about the constraints and tradeoffs as you work on it, how am I to imagine there is any chance you could be a productive teammate?
[+] [-] dekhn|7 years ago|reply
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.
[+] [-] jasondclinton|7 years ago|reply
I am, I think objectively, a pretty good software engineer and often couldn't solve my peers interview questions in the time allotted. I try to do my part by conducting interviews with questions that I think demonstrate the ability to actually code and think abstractly as opposed to regurgitating some random algorithm that has been memorized. I ask a simple CS 100-200 level, one-word-answer question about an algorithm and then move on to a coding question.
Despite the difficulty of some of the questions that others ask, often the interviewer wants the interviewee to pass and so will throw a hint. It's important to keep commicating because that is how those hints will be delivered.
Ironically, I never interviewed because I came in from an acquisition. Yes, I was very lucky.
[+] [-] wyldfire|7 years ago|reply
I didn't know what "CLR" was, so I searched around: Cormen, Leiserson, Rivest's "Introduction to Algorithms" [1].
[1] https://en.wikipedia.org/wiki/Introduction_to_Algorithms
[+] [-] amelius|7 years ago|reply
I guess that would be a trick-question then, as nobody ever solved an NP-hard problem in linearithmic time.
[+] [-] TomMarius|7 years ago|reply
What is a good way to learn more about these?
[+] [-] tootie|7 years ago|reply
[+] [-] habosa|7 years ago|reply
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.
[+] [-] ryandrake|7 years ago|reply
I’ve heard this joke at a lot of tech companies. Also, “the hardest thing I’ve ever done at my job was pass the interview.” Just shows how divorced from day-to-day work skills interviewing has become.
I think most tech companies severely overestimate the cost of false positives, particularly in the USA where it’s trivially easy to fire someone who turns out to be a dud.
Also think it represents an opportunity: if you could reliably figure out who made it to the interview stage at these top companies but did not get an offer, you could forego your recruiting expense, simply hire all those people and likely end up with a well above average team, minus the few false positives.
[+] [-] vonmoltke|7 years ago|reply
I don't see how companies that claim it's hard to find talent can be OK with a system that would reject more than a small portion (<5%) of their current productive engineers.
Edit: fixed word sense ambiguity
[+] [-] Spoom|7 years ago|reply
FWIW my understanding is that the Hiring Committee tends to discard feedback from interviewers like your latter type here.
[+] [-] jfasi|7 years ago|reply
https://programmingpraxis.com/2012/01/20/knights-on-a-keypad...
This is a great question because it has several levels of solutions:
1. A recursive solution that iterates over all sequences, exponential time and logarithmic in space. Interviewing for T3 (entry level, think college grad), getting only this far in 45 minutes earns a "leaning no hire" in my book.
2. The above solution except with memoization, which reduces the runtime to linear but requires linear space. This one earns a "leaning hire" from me.
3. A dynamic programming solution that takes linear time and constant space. This one gets a "hire" to a "strong hire," depending on the elegance of the implementation and the strength of the discussion we have around it.
4. A logarithmic time solution involving adjacency matrices, matrix multiplication, and binary decomposition of numbers. I've never seen anyone get this and I only learned about it after months of asking this question.
It's shocking how few candidates actually got as far as solution 1. I kinda want to open this up to the HN comments section, because this does not strike me as a brutally difficult problem, but the rate at which people fell on their faces when presented with this question suggests either something about our interview process or about the candidates we interview.
EDIT: A clarification about “getting as far as” a particular solution: I’m not sitting there stone faced taking notes, I provide hints and prods and suggestions to push candidates toward more optimal solutions. I want the candidate to get as far as possible because it feels good to watch someone succeed, but oftentimes they run out of steam or take forever to implement their solution. In particular with respect to solution 1, if that’s as far as a candidate can get despite my recommendations, that’s not a good sign for their algorithmic ability.
[+] [-] Shish2k|7 years ago|reply
Personally I find that I can get a lot more useful signal from simple practical problems (eg "take a .txt file as input, modify all the words which contain the letter 'q' to be uppercase, write the results to a new file") which have a lot of room for expansion (What if we instead want to capitalise each word where the word after it contains a 'q'? What if we only want to modify the third instance of each word? What if the .txt file is too large for RAM? What if a single 'word' is too large for ram and the letter q is right at the end of the word?) -- starting out with something that any programmer should be able to solve in one or two minutes, and then cranking up the difficulty; adding in bits where a strong algorithmic coder has an opportunity to come up with a more efficient solution, but it isn't just a binary "has the candidate memorised the appropriate algorithm yes/no?".
(Example question made up off the top of my head because NDA, I haven't actually given much throught as to if it's a good question or not, just giving an example of "question which starts simple and then you can add complexity on top")
[+] [-] jfasi|7 years ago|reply
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.
[+] [-] jasondclinton|7 years ago|reply
[+] [-] driverdan|7 years ago|reply
I strongly disagree with the assertion that you get no useful information from an unsolved problem. The goal of giving a candidate a problem should not be to have them solve it. The goal should be to learn how they approach a problem, think it through, and work on solving it. Actually coming up with a solution is the least important part.
As an interviewer I've intentionally given people problems that would take more time than they have. I'm always upfront about it, making sure they know they may not solve it and that they should get as far as possible while explaining their choices.
As an interviewee I've been dinged for not solving problems. The reason why was because I spent most of my time talking through my approach and planning how I'd solve it. Without proper planning you get sloppy code, technical debt, and miss deadlines. Planning seems to be greatly undervalued in tech, especially in small startups.
[+] [-] franzwong|7 years ago|reply
I also asked a question in HN yesterday. It looks like there are more questions on data structure and algorithm for big data. However, books I read don't focus much in this area. As I haven't worked on big data before, that would also be a challenge for me.
[+] [-] pcwalton|7 years ago|reply
I mean, I guess, but in the many hiring discussions I've been on I found that the interviewers who asked those questions and based their feedback on them had very noisy signals. They frequently gave "lean no hire" feedback on our best hires. The interviewers who actually asked questions relevant to the work had much better signals.
[+] [-] kamaal|7 years ago|reply
I understand what you are trying to say here. But how many candidates are capable of inventing path breaking algorithms in 45 minutes, just to crack a job interview? I guess only a countable people in the world could achieve a feat that amazing, where they could invent a totally new novel algorithms from the scratch in 45 minutes. If I'm not wrong the very people who invented these algorithms went through years of research to publish them.
Now if you are not testing this, and just testing if the person knows an existing algorithm. Then really this a scaled version of testing the ability to memorize multiplication tables.
There is nothing novel in merely knowing an algorithm. And you also have not tested a person's ability in inventing an algorithm either.
[+] [-] gerbercj|7 years ago|reply
[+] [-] pdpi|7 years ago|reply
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.
[+] [-] sadamznintern|7 years ago|reply
The speed required makes me skeptical many people can solve these problems in the required time without luck of having seen similar problems before.
[+] [-] kjeetgill|7 years ago|reply
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.
[+] [-] Aardappel|7 years ago|reply
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.
[+] [-] hzay|7 years ago|reply
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.
[+] [-] zerr|7 years ago|reply
[+] [-] tinderliker|7 years ago|reply
I know HN hates whiteboard problems, but just like anything, you get good with it if you're having fun solving them.
[+] [-] smt88|7 years ago|reply
We hate them for interviews because they're a terrible signal for hiring, they're often poorly administered, they're humiliating, they discriminate against introverts, and they've become frustratingly common.
They unfairly mess with people's livelihoods. It is a really big, life-altering issue for some people.
[+] [-] franzwong|7 years ago|reply
[+] [-] sadamznintern|7 years ago|reply
[+] [-] mattm|7 years ago|reply
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.
[+] [-] plasticchris|7 years ago|reply
[+] [-] morazow|7 years ago|reply
[+] [-] HillaryBriss|7 years ago|reply
I'm consistently surprised by the fact that, despite hiring programmers who are the world's most elite, Google's products and services are just kind of ... plain/average/boring. The products and services are far less amazing than Google's engineers.
It's like Google takes in geniuses but outputs kind of boring, standard, average quality products and services with a surprising number of problems and deficiencies.
[+] [-] franzwong|7 years ago|reply
[+] [-] mathattack|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] daly|7 years ago|reply
I worked with a guy, Bob, in our college computer room. Bob had returned to get his BS after many years in industry. He had great stories. He also had great advice. He taught me that you can learn a lot about how a company will treat their employees by paying attention to the way they treat you during the interview. He suggested several sign that indicated it was best to just "walk away".
If you go into a restaurant for a professional lunch meeting and they have a ball-pit / swing set /etc. it might not be the most professional place to hold the meeting. Just walk away.
If you go to a 5 star restaurant and they want you to wear a clown nose (Everybody Does It!) Just walk away.
The big scam is "We hire the best and the brightest". "We mandate a whiteboard test (Everybody Does It)". It is my opinion (based on experience) that companies that insist on a whiteboard test, despite years of programming on your resume and open source code, are either Ball-Pit companies (who don't know what it means to be a professional) or Clown-Nose companies (who know what it means to be a professional but still treat you like a commodity). Just walk away.
When you object, please reference one study in a journal that shows that whiteboard tests are effective in any measure when used during interviews.
I understand why Google does it. I've even interviewed there. They get thousands of resumes (which they never read, at least nobody did at my interviews). They have to weed out the "learn coding in 6 weeks" crowd. But you're a professional. You should expect to be treated like one. You don't ask your surgeon to cut up hams in an interview. You don't ask your builder to nail two boards together. Professional accountants are not interviewd by bank tellers and ask to count change.
Google, like Microsoft before it (remember the "why are manholes round? quizes?"), have combined the marketing claim "We hire the best and brightest" with the ball-pit mentality of whiteboarding. Google HR (sorry, People Resource?) SHOULD be embarrassed but apparently they, and upper management, LIKE ball-pits.
A real professional interview involves a discussion about what the company does, what it current problems are (aka why are they hiring), and a discussion of if you, as a professional, have the skills to solve the problem. What do they need? How can you contribute? It is likely that your interviewer has no idea what you are being interviewed for and cannot answer these basic questions.
We, as professionals, should consider whiteboarding as an insult.
Just walk away.
[+] [-] marssaxman|7 years ago|reply
Why would I ever want to hire someone incapable of demonstrating their skills in such a simple, straightforward way? If you can't solve a toy problem and explain your solution, or at least have a conversation about the constraints and tradeoffs as you work on it, how am I to imagine there is any chance you could be a productive teammate?
[+] [-] Eridrus|7 years ago|reply
[+] [-] social_quotient|7 years ago|reply
[+] [-] pps43|7 years ago|reply
[+] [-] franzwong|7 years ago|reply
[+] [-] sadamznintern|7 years ago|reply
[+] [-] smt88|7 years ago|reply
Also, solving them in an interview is radically different from solving them for fun.
[+] [-] HugoDaniel|7 years ago|reply
[+] [-] sadamznintern|7 years ago|reply