Google's interview system: it's not about solving the problem

Currently interviewing. Super excited at first, but now excitement is mostly dying down. We’ll see how it goes.

Thanks for the heads up. ^^

I have recently interviewed at most of these companies, eventually managed to get some good offers at some of them, but let's be honest, I had to invest months in getting prep for the tech screening, whiteboard coding exercise and the whole non-sense jazz. I am sick of reading this blog posts because everyone knows, that is not how the majority of these interviews are conducted. I have more than 10 years of experience on the field, I earned my degree in computer science years ago, but I had to go back and brush up on trie, tree, etc to convince the interviewers that I was worth working at company XYZ. The interview process is pretty much broken and very much biased towards fresh out of college eng. Unfortunately, if you really want to work at any of these companies you need to play their game and make them happy. Once you get the job, you will discover that most of your teammates are not as smart as they want you to believe they are and often you will be wondering how the hell did they manage to get a job at company XYZ. Well, they simply invested months prepping for the interview, plus they come from some well known university. Unfortunately when it comes to real work, they have no idea on how to get things done. What make things even worse is that often the tech screening is done by junior eng that have no idea and experience on how to conduct an interview and they expect the answers by the book. A positive note: I also noticed that some companies are now giving take home exercise that are much closer to the day-to-day job. So maybe there is still hope.

I'm not sure what you are asking. Each interviewer on the interview panel writes up a large amount of notes on their interview. The C++/Java/C/Python code written by the interviewee, what hints were given, what blind alleys the candidate might have wandered by, how the candidate tested the code, how long did it take for candidate to find a bug (with or without hints, etc.)

For a design question, the interviewer will write up a sketch of the design, what tradeoffs were identified by the interviewee; what hints, if any, were needed, etc.

Then the interviewer will rate candidate on various technical dimensions (coding efficiency, design, etc.) and non-technical dimensions (communication, leadership, etc.) For each of these ratings the interviewer has to justify the rating, by pointing at examples from the interview notes.

Finally, the interviewer will be asked to score the candidate along a dimension of "strong hire" to "strong no-hire" and again, the score must be justified with a paragraph. For people on the hiring committee, the justification for the scores are often far more important than the actual rating given by the interviewer.

The hire/no-hire decision is not up to the interviewers; the hiring committee is composed of a different panel of engineers who review the interview reports from the interview panel; and the members of the interview panel write their interview reports without getting to see or hear from the other members of the interview panel.

There aren't millions of high IQ people applying and vying to work at Google.

Hiring continues to be a favourite whipping boy on HN and honestly I kind of wish it would die because it's the same arguments every time:

- Inconsistent interviews

- Luck of the draw questions

- "I don't do well coding on a whiteboard" (often framed as "coding on a whiteboard proves nothing")

- Bad experience with the process

- Etc

Personally I don't mind coding on a whiteboard but only if you understand why you're asking a candidate to do it and what you hope to gain. Unfortunately many (IMHO) get this part wrong.

Obviously FizzBuzz was influential here. And I honestly think FizzBuzz is the right way to think about live coding tests because it's simple. It's deceptively simple such that anyone competent easily falls into the trap of thinking the question needs to be harder and this is a problem with many FAAMG interviewers.

On the other side I think there are people who don't realize how many people are masquerading as programmers who can't program a for loop in their language of choice. It's actually hard to believe for anyone semi-competent unless you've witnessed it but it's true.

FizzBuzz is a simple problem aimed at providing an early negative signal on a candidate. Every word of that was deliberate and important. It's simple so anyone remotely competent will pass it within minutes and you can move on.

This doesn't mean that if you ace it you're a good engineer ie there is ZERO positive signal here. The negative signal is if you can't solve this simple problem in your language of choice because then you almost certainly aren't a good engineer and you (the interviewer/employer) can stop wasting your time.

This is why it's so important it's a simple problem because a hard problem adds very little positive signal and greatly reduces the negative signal. Some people are bad under pressure with hard problems. Some questions are a matter of knowing the trick. Finding cycles in a graph is trivial if you are familiar with the tortoise and hare algorithm. If not you may figure it out from first principles but if you don't it doesn't mean you're a bad programmer or you shouldn't be hired. That's the problem.

On the other side some like to lambast interview processes if they have a nonzero false negative rate. These stories usually go "I referred excellent engineer X and they bombed out on a random coding question" or similar. This happens but getting a false negative doesn't invalidate the system.

It's important to remember to that the goals of the employer and the candidate are different. The candidate's goals are to try to get a positive signal to the employer. The employer's goals are to minimize time spent per candidate (since this is expensive) while hiring a sufficient number of qualified candidates with a minimum of false positives.

Again, every word of that is important. False positives are expensive. If you have a pool of 100 people to fill 10 roles and 20 are will work out then, as the employer, you don't often care which of those 20 you get, as long as you get 10 of them. There's an effort-reward curve between getting 10/20 qualified candidates vs the best 10.

Lastly, this is also why there is an interview slate of 4+ interviews. A single bad interview does not kill your chances.

I'd say Google's biggest problem is interviewer dead wood. These are people who have their pet questions, which were banned years ago (as either being too well known and/or just being a bad question) but they keep asking it anyway. Or they know and then force the candidate to use it and then mark them down for not knowing it (when the candidate never claimed to know it). Part of the delays in Google hiring too are some people will do an interview and won't submit feedback for 1 or even 2 weeks, a process I personally found inexcusable and infuriating.

But interviewing is one of those things that everyone is expected to do, which needs to change as many people are either bad at it or just don't really care.

I would also say, if anything, Google (and this probably applies to most if not all big tech companies) doesn't filter often and early enough. I saw candidates who never should've made it passed a phone screen. In some cases I saw the phone screen feedback (as part of the whole packet) and I honestly don't know why it didn't end there. My own theory was that recruiters largely controlled this and they had quotas to meet of phone screens, onsite interviews and hires and this just ended up wasting a lot of interviewers' time. But that was just a theory.

Disclaimer: Xoogler