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.

12 of 227 comments (clear)

  1. One kind of employee by drinkypoo · · Score: 3, Insightful

    Google is making sure they only have employees that think a certain way by using their hiring process. But is that the only kind of employee they need to be healthy long-term?

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:One kind of employee by TheRaven64 · · Score: 4, Insightful

      Google's process is very much geared towards finding problem solvers, ignoring the need of finding the people who can identify the correct problems to solve. Their interview process isn't too bad with that goal in mind. The real problem is what happens afterwards. They make you wait a few months while they make a decision, and then they want you to start the following week. The only people who are still looking for a job by the time Google decides that they actually want them are PhD students who applied during their final year. Everyone else has already taken a good offer somewhere else.

      --
      I am TheRaven on Soylent News
    2. Re:One kind of employee by JustBoo · · Score: 3, Insightful

      Google is making sure they only have employees that think a certain way by using their hiring process. But is that the only kind of employee they need to be healthy long-term?

      Yep, it's the kind of "engineer" (ha!) that has replaced engineering principles with religion. The kind that has to worship Google first and foremost. I learned long ago just because someone has a PhD. or a fancy degree from an Ivy league college, does NOT mean they are smart or talented.

      Given people who work for Google really work for an Advertising Company and everything they do is driven by and for that, kind of proves the above. Add in the fact most of them think they are doing humankind some kind of favor by working for an Advertising Company and we come back to Religion.

  2. Interview "Grilling" or "Testing" is Poppycock by brunes69 · · Score: 5, Insightful

    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)

    1. Re:Interview "Grilling" or "Testing" is Poppycock by drinkypoo · · Score: 3, Insightful

      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)

      Perhaps it's the special snowflake effect that comes from hiring all these ostensible geniuses that makes gapps and google web apps so shit. I can't think of a single one that didn't start out more usable than it is today. Inbox barely works; it eats mouse clicks left and right, just completely ignores them. I have to click 2-3 times just to get an email to open and the menu buttons on the emails themselves only work without actually opening the email maybe one load in ten. (One load of the site, that is.) And what's sad is that most of these sites perform badly in Firefox, but they perform worse in Chrome! They can't even make a webapp work properly in their own browser.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Interview "Grilling" or "Testing" is Poppycock by shawn2772 · · Score: 5, Interesting

      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.

    3. Re:Interview "Grilling" or "Testing" is Poppycock by Feral+Nerd · · Score: 4, Informative

      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.

    4. Re:Interview "Grilling" or "Testing" is Poppycock by Alomex · · Score: 4, Informative

      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.

    5. Re:Interview "Grilling" or "Testing" is Poppycock by shawn2772 · · Score: 5, Informative

      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

    6. Re:Interview "Grilling" or "Testing" is Poppycock by ErichTheRed · · Score: 5, Insightful

      "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.

  3. Worst? by nospam007 · · Score: 5, Funny

    " but Twitter's is perceived as the worst"

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

  4. Mine is actually the toughest by EmagGeek · · Score: 5, Interesting

    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.