I can't speak to other companies, but I do know my [unofficial] experience interviewing (on both sides) at Google.
As an interviewee, you know that you're going to have a handful of different interviewers. What you don't know is how much of an effect each of those interviewers is going to have on the hire/no hire decision. Is one bad interviewer enough to torpedo you? Two? And you have no idea what kind of questions each interviewer will ask. So, let's say only 10% of interviewers ask these kinds of questions (I'm guessing that's low). That's a ~41% chance that you're going to have to answer this, and if one bad interviewer is all you need, then you'd be foolish not to prepare just in case.
As an interviewer, we're given surprisingly few guidelines on how to interview. You take a one day class, then shadow half a dozen interviews, and that's it. We aren't given specific questions to ask, and specific questions get banned all the time (any time they're "leaked" as a Google interview question).
Once someone is hired it's really hard to force them out, so approving someone who talks a smooth game but can't back it up is extremely costly. I've seen teams get stuck with multiple people for well over a year because it takes a long time to get them out, they won't leave willingly. Meanwhile they're taking up headcount and letting them actually touch code is dangerous. In fact, I've seen teams spend an additional engineer training them to the point where they are productive, just because that's cheaper.
So you want people to actually prove themselves with some kind of an algorithm question, but you get no real guidance on how to provide these and you constantly have to come up with new ones, but they have to be the kind of question that take less than 45 minutes to explain and solve. I have no doubt that some people fall back on these kinds of questions.
Yeah, I get that these questions suck, and I try not to be that interviewer. But as an interviewee I would consider it extremely foolish to not brush up on it, just in case.
You said it yourself "they're taking up headcount and letting them actually touch code is dangerous". My question is, how did they managed to get into Google if they apparently don't know how to write code? The only way to get into google is to go through a huge set of 45-min whiteborad crap. Not once, not twice, we're talking about 7-8 times! Going over the same stupid 45-min "technical screen" where only the original question varies. You need to know all the CS basic stuff + ability to scale (if possible). Like they all say in Silicon Valley - the only way for us to know if you're a rockstar is if you manage to crack a few meaningless problems on a whiteboard. Oh... and make sure to pick your favorite language. Your Resume tells us you have a MS in CS but we don't believe it. So we're gonna put you back into a college-like exam to make sure your degree isn't fake.
To me, that's step zero. I still can't believe companies like Google, etc get stuck at step 0. They don't seem to care about step 1, 2, 3, 4. It doesn't matter if you have 1 year or 10 years of experience, we all go through step zero (again, even though we got an MS in CS a few years back).
So, if Google ends up in a situation where "teams get stuck with multiple people for well over a year because it takes a long time to get them out", it's because the hiring process at Google sucks. If it is that costly and painful to hire the wrong people, then why Google hasn't put more resources to actually innovate and think beyond college-like evaluations. It is OK for people with zero experience, it is not OK for people with at least one work experience (which I call step 1). Of course, if you have 10 years of experience they need to use a different language in order to interact with you. So, unless someone just graduated from college looking for a job, you can't hire someone exclusively based on step 0 because it simply doesn't tell you if a candidate knows how to write code, build features, work in a collaborative environment, deal with requirements from product team, reuse exiting code, handle code reviews and feedback from peers, create frameworks or adopt new frameworks. All it tells you is if your CS degree is fake or not...
> The only way to get into google is to go through a huge set of 45-min whiteborad crap.
This is not the only way to get into Google.
> Not once, not twice, we're talking about 7-8 times!
When I interviewed I had one 15 minute phone screen, and one round of in-person interviews. The in-person set was 5 people. Of those I think I cratered on one of them, did adequate on two, and stellar on the last two.
> Like they all say in Silicon Valley - the only way for us to know if you're a rockstar is if you manage to crack a few meaningless problems on a whiteboard.
Very few people get hired as a "rockstar", and the ones that do tend to be hired for non-coding roles.
> Oh... and make sure to pick your favorite language.
Yeah, the point is for you to answer the question and not get hung up on language semantics that you aren't comfortable with. I interviewed in C# despite ~0.1% of code at Google being C#. I had a very in depth conversation about contract differences between C# and Java that I think impressed the interviewer, despite me not knowing a single line of Java and him not knowing a single line of C#. If you pick the language and still struggle with the semantics of it, that's a huge red flag.
> Your Resume tells us you have a MS in CS but we don't believe it. So we're gonna put you back into a college-like exam to make sure your degree isn't fake.
An MS in CS doesn't, by itself, qualify you for a role at Google. I have plenty of friends who have the degree who I like very much, but I wouldn't want them on my team.
> I still can't believe companies like Google, etc get stuck at step 0. They don't seem to care about step 1, 2, 3, 4. It doesn't matter if you have 1 year or 10 years of experience
Yeah, I came in with 15 years of experience across 7 different firms. And I went through the same thing. I've also worked with people who have been in the industry for all kinds of timeframes, up to 35 years, and I've seen little to no correlation between "experience" and ability.
A higher-touch process with more "describe what you did at company X" would be nice. But it also feels easier to game. I read design docs for projects at all levels at prior roles, including rationale, alternatives, etc. If I wanted to pass one of those project off as my own through an interview I don't think it'd be very hard. I also don't see any other companies that hire at the rate that Google does (well over 100 software engineers per week) that manages to do that.
> So, if Google ends up in a situation where "teams get stuck with multiple people for well over a year because it takes a long time to get them out", it's because the hiring process at Google sucks.
So now you're arguing for a more stringent review process, but one that doesn't require actually demonstrating any abilities? Also, this is less of an issue with hiring, and more of an issue with staff management.
> you can't hire someone exclusively based on step 0
I'm not sure why you think that Google is "stuck" at step 0, or that we stop there. There is generally no feedback to a candidate about why an offer isn't extended. You're assuming that it's because of a whiteboard coding issue when it might be that your experience doesn't really mesh with what's needed.
There are a wide variety of factors that candidates are scored on, and there are plenty of them that have nothing to do with the code that's written on the board. I've had plenty of candidates that have gotten a "hire" recommendation despite not having an optimal, or even a correct answer on the board. I was confident in their abilities because they demonstrated that they recognized there was a problem, usually due to running through test cases, and that given enough time they would solve it. I've had candidates that have gotten a "no hire" because, despite have a correct and nearly optimal answer, they refused to listen when told that "result &= true;" is a no-op in Java.
Is the interview process perfect? Of course not. Perfection isn't achievable. And I'm happy to listen to suggestions on how to improve the process. But your suggestions seem to be: 1.) Don't ask whiteboard questions at all (which I have yet to be convinced of), 2.) Don't stop at asking whiteboard questions (which we don't).
Just wondering, do you mean the range of questions covered is too narrow? If "10% of interviewers" ask these kinds of questions, what would the other 90% of interviewers do. Other types of common data structures/algorithms, DS/A questions thought up by themselves, or something in entirely different directions?
As an interviewee, you know that you're going to have a handful of different interviewers. What you don't know is how much of an effect each of those interviewers is going to have on the hire/no hire decision. Is one bad interviewer enough to torpedo you? Two? And you have no idea what kind of questions each interviewer will ask. So, let's say only 10% of interviewers ask these kinds of questions (I'm guessing that's low). That's a ~41% chance that you're going to have to answer this, and if one bad interviewer is all you need, then you'd be foolish not to prepare just in case.
As an interviewer, we're given surprisingly few guidelines on how to interview. You take a one day class, then shadow half a dozen interviews, and that's it. We aren't given specific questions to ask, and specific questions get banned all the time (any time they're "leaked" as a Google interview question).
Once someone is hired it's really hard to force them out, so approving someone who talks a smooth game but can't back it up is extremely costly. I've seen teams get stuck with multiple people for well over a year because it takes a long time to get them out, they won't leave willingly. Meanwhile they're taking up headcount and letting them actually touch code is dangerous. In fact, I've seen teams spend an additional engineer training them to the point where they are productive, just because that's cheaper.
So you want people to actually prove themselves with some kind of an algorithm question, but you get no real guidance on how to provide these and you constantly have to come up with new ones, but they have to be the kind of question that take less than 45 minutes to explain and solve. I have no doubt that some people fall back on these kinds of questions.
Yeah, I get that these questions suck, and I try not to be that interviewer. But as an interviewee I would consider it extremely foolish to not brush up on it, just in case.