Slashdot Mirror
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.
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)
I agree with that. I got invited by a headhunter to one of those famous Google job interviews for a position in either the UK or Switzerland of all places. I wasn't really about to uproot my entire existence and move to another country (never mind learning how to drive on the wrong side of the road since Switzerland was not an option) but the opportunity of going through the world famous interviewing process of the Google genius recruitment team was too tempting to turn down. Needless to say I failed this interview which I take it is the first hurdle in Google's long and painful interview process. The reason I flopped was probably because of my poor attitude since I concluded about 3 minutes into the interview that even if I had been interested in moving to the UK when the interview started this interviewer was a wasting my and Google company time. The interview consisted of a teleconference where a Google employee quizzed me about various really technical issues with most of the interview revolving around the nitty gritty details of how command piping is implemented in different *nix versions. I have been asked by employers to solve all kinds of programmatic and system administration related problems in my two decades as a programmer but why on earth would I be an expert in the command/data piping mechanism in *nix type operating systems and why would I be a bad developer if I don't know that? Another typical task that I have been presented with at various times during interviews is solving some math puzzle to which I usually reply that I can knock you together a *nix daemon and client capable of network communications in about 5 minutes with a basic toolkit I developed years ago and keep on a USB stick on my keychain. Or perhaps you'd like me to put together a web service in C/C++? ... but please don't ask me to solve differential equations programmatically off the top of my head. That is not something I have ever been asked to do by an employer in 20 years of programming and it's something I'm not likely to ever be asked to do judging from the job advertisement I responded to.
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.
Except that Google keeps track of this and has the data to back it up. So on the one have you have your single anecdotal experience and on the other hand we have 10 years of Google hiring experiences.
Of course it is not perfect and they end up hiring some duds and letting some jewels go, but that is not the threshold sought, they simply aim to hire better than the average company.
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