Google Has Toughest Interview Process For Developers, But Not the Worst (getvoip.com)

An anonymous reader writes: A casual survey of candidates' reactions to the interview processes of the biggest tech companies in the world shows Google as having one of the most grueling hiring gauntlets in the sector — but Twitter's is perceived as the worst. The survey measured the amount of time candidature took, as well as the number of stages and the methods involved at each stage, and additionally estimated whether the job-seekers felt positive or negative about the procedure.

Comments

Interview "Grilling" or "Testing" is Poppycock

[brunes69]

I am a dev, and for a long time was a hiring manager. The idea that grilling, testing, or creating "challenging" interview questions for candidates, and thinking that it will give you ANY introspective on how they will perform on the job, is complete and total poppycock.

Honestly, I feel kind of bad for silicon valley companies that have gotten this strange idea that if you hire a whole bunch of "smart" developers who can answer a bunch of esoteric interview questions, and/or complete silly coding assignments in under an hour, that it will somehow magically enable those developers to coalesce as a team, work hard, solve difficult problems together, and release a viable product.

Raw intelligence is not everything. In fact, it is not even in the most important facet when hiring a software developer. Much more important are experience problem-solving and collaborate in a team environment. I have zero interest in the zen guru who sits at his desk all day churning out algorithms without involving his other team members in what he is doing - because other people need to understand what he is doing and contribute to it as well, if you want to create a successful organization (which will result in a successful product)

Re:Interview "Grilling" or "Testing" is Poppycock

[shawn2772]

I am a dev, and for a long time was a hiring manager. The idea that grilling, testing, or creating "challenging" interview questions for candidates, and thinking that it will give you ANY introspective on how they will perform on the job, is complete and total poppycock.

I'd actually really like to agree with you, because there is a huge amount of error in any hiring process that tries to evaluate engineers in anything less than a few months of focused work.

But, I don't, for the very simple reason that I have seen the outcome of Google's hiring process firsthand, after 20 years of work in the industry to provide context... and I can state with absolute certainty that the average Google engineer would be a star virtually anywhere else in the industry. So, whatever errors there are in the process it actually works, in the sense that it effectively ensures that vanishingly few candidates who aren't highly capable get hired. Even better, Google's process seems to do an excellent job of weeding out prima donnas who can't work well with others.

So, while in the abstract I agree that it's extremely difficult to figure out who's good and who's not in a 45-minute interview with a coding problem or two... Google's process actually works very well. Google HR even has empirical data to back that up: they've found that while there is no correlation between the scores that any individual interviewer gives candidates and the job performance post-hire, there is a strong correlation between the mean scores given by the four to five interviewers who interview a candidate and post-hire performance.

Of course, that evaluation can only consider the candidates who were hired, and it's widely believed at Google that therein lies the major flaw in the hiring process: It's great at excluding unqualified candidates but does so only by also excluding lots of qualified candidates. My first tech lead at Google put it this way: If you take any successful Google engineer and run them through the hiring process anonymously, they've got a roughly 50% chance of being hired. I wonder if it's even that high.

Re:Interview "Grilling" or "Testing" is Poppycock

[shawn2772]

Genuine question, because I occasionally have to interview people: how do you interview people, and what sort of questions do you ask to try and work out if they are the right kind of person?

I'll give you Google's answer to this question, if you like.

Google does a series of four interviews, each with a different interviewer. All interviewers submit their responses to a hiring committee in writing. Each gives a hire/no-hire recommendation as well as scoring the candidate on a 1-4 scale (0 == if you hire this person, I'll quit; 2.5 == I have no opinion[1]; 4 == if you don't hire this person, I'll quit). Each interviewer also provides a detailed account of what they asked, how the candidate responded and what conclusions the interviewer drew. If the interview included writing code, the code is included in the feedback. The hiring committee, which includes no one who interviewed the candidate, takes the feedback from the interviewers and comes to a hire/no-hire consensus decision.

Each interview is nominally 45 minutes long, scheduled one hour apart, leaving 15 minutes between interviews for bio breaks, logistics, etc. Between the second and third interviews an additional "interviewer" takes the candidate to lunch. The "lunch interviewer" submits no feedback and answers the candidate's questions about the company, as well as giving them a break (and food).

For the actual interviews, each interviewer is instructed to focus on evaluating how smart the candidate is and how well they solve problems, not on how much they know. Basic CS knowledge is necessary because that's the language of the interview, and the candidate must know some programming language, but it doesn't matter which one.

Interviewers select their own questions to ask, but there are some criteria. First, the answers should not depend upon having some particular bit of knowledge. Other than basic CS knowledge, it's expected that the interviewer can provide the candidate with whatever information is required, though not necessarily all at once. It's good to provide partial information and see how the candidate goes about determining what else is needed, and obtaining the missing information. Similarly, answers should not depend on the candidate having some flash of insight. Such "aha!" questions say little about ability. The best questions are also progressive in nature; they start simple and build in difficulty and complexity as they're explored. This has a lot of benefits, not least that it allows weak candidates to feel like they had some success and walk away feeling like it was a good experience... even as the question showed the interviewer that the candidate isn't qualified.

Interview questions must also be calibrated. That is, the interviewer must know before going into the interview how well different kinds of candidates respond to the question, and must have a pretty deep understanding of the solution space. The calibration process begins by running peers through the question in a mock interview. That allows the interviewer to get a feel for what Google-caliber engineers do and do not see when looking at the problem and potential solutions. Different people are different, so it's recommended to have at least three or four peers help with initial calibration. Calibration is further refined by using the same question with many candidates. Google engineers have a small handful of questions they always use. They should always enter an interview armed with a well-calibrated question, plus a backup question or two in case the candidate is really outstanding and flies through the first question, or in case the first one turns out to be unsuitable in this particular case.

The interview begins with a few minutes of introductions/small talk to help the candidate relax. Most interviews consist of a single problem. The candidate is asked to devise an algorithm to solve it, describing the algorithm first verbally/pictorially, and then implementing the algorithm either on a w

Re:Interview "Grilling" or "Testing" is Poppycock

[ErichTheRed]

"the new age programmer, the Web 2.0 guy"

Agreed mostly. The thing I'm seeing is that developers write for the abstraction layer they're using, not really understanding all the magic that goes on under the hood. That wrapper on top of a framework on top of a client-side language runtime running in a Docker container running on a virtual machine running on an IaaS platform of choice eventually talks to a final operating system, and eventually to real, physical hardware. If a developer doesn't have at least some CS background that touches on how the magic happens at a low enough level, solving performance problems becomes difficult. No one should be coding in assembler unless there's no other choice, but assuming the OS or runtime is going to do everything for you really limits what you can do.

Worst?

[nospam007]

" but Twitter's is perceived as the worst"

It's just because your answers have to be 140 characters or less.

Mine is actually the toughest

[EmagGeek]

I have a very rigorous hiring process. First of all, you cannot apply. I don't post job openings anywhere. There is no official mechanism to approach me for a job.

When I decide I need to hire someone, I seek out applicants on my own, based on reputation in industry, published works, patents, and other factors. When I identify someone I want to hire, I send my talent team to make contact in person (i.e. stalk them haha), often literally with a tap on the shoulder.

The process works. In 15 years, I've never had anyone leave (except to retire), and I've never had to let anyone go.