5 ms·

the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interv

the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interviewees have. It will _only_ pass candidates who are unusually good at algorithm puzzles, on whiteboards, under time pressure.

codazoda 10y ago
This seems to be the type of employee Google is looking for, in which case, it works great.
- pmontra 10y ago
  Maybe it's not what they are looking for. Maybe it's only the easiest test, like looking for the keys under the lamp post. It could also be that this way of hiring people turned the company into a specific direction, more attention to the sw and less to the customers.
  - lallysingh 10y ago
    Or visa-versa, that the company always cared more about the sw than the customers, and the hiring methodology reflects that.
  - maverick_iceman 10y ago
    It seems to be working fine for them.
    - Apocryphon 10y ago
      Is it?
      - maverick_iceman 10y ago
        https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=goog https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...
Adverblessly 10y ago
When I was interviewed for a job at Google I was told there would be 5 different interviews measuring 5 different things: Pure Algo (which I view as "let's see that your CS grades were earned and not bought") Pure Coding (let's see if you have a reasonable coding style and design and are proficient with at least one language) Algo & Coding (a bit of both that makes sure you can solve a simple problem and code it [i.e. work entirely through a problem]) Software Design (so more on your skill in designing code - finding the right abstractions and interfaces etc.) Systems Design (your ability to design complete, large scale systems at a very high level) And this is more or less what I got, which seemed fair and logical to me. I agree that it is not tailored to the interviewee's individual skills (for example, your special training in cyber security is unlikely to give you an extra edge), but it makes sense for "good overall software engineer", and if you aren't also a good overall software engineer in addition to your special training in cyber security, then you are probably not what Google is trying to find. Also, it does look at your skills in coding and design which are both non-algorithmic. Now whether or not this experience is shared with other interviewees, or matches what you are looking for is something else :X
munificent 10y ago
> it is not sensitive to non-algorithmic skills and talents that interviewees have. I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms. A good question: 1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out. 2. Has a high enough ceiling that a strong candidate doesn't blow through it in five minutes. 3. Has a smooth ramp between those points. 4. Doesn't rely on too much domain-specific knowledge so that a candidate who happens to have a random gap in their background that leaves them totally hosed. 5. Is concrete enough that the interviewer can capture that feedback in a way that the hiring committee can easily understand. 6. Isn't well-known outside of Google as stock interview question so that candidates can game us by just learning the answer. 7. Isn't asked by any of the other interviewers the candidates sees. 8. Can be explained and worked through in about twenty minutes. In case it isn't obvious, it is really really hard to find good questions that pass that gauntlet. Questions do tend to skew towards smaller-scale algorithm coding questions because I think those tend to survive that gauntlet better than most other questions. > unusually good at algorithm puzzles Interviewers are trained to not ask "puzzle" or "trick" questions. Not only are trick questions a shitty experience for the candidate, they are a shitty experience for the interviewer too. My job in an interview is to get as much data as I can about a candidate in order to provide information to the hiring committee. If I ask you a trick question, I get about one bit—in the binary sense—of data from you: did you find the trick or not? I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through. That time was incredibly well-spent. Since then, I have relied on that algorithm knowledge way more than I expected too, and have since spent more time learning algorithms and data structures because I can clearly see it's made me a better programmer. > on whiteboards, That part is hard. We allow candidates to use a laptop too, if they prefer, or both. My experience is that candidates who use the whiteboard, at least for the earlier "design" parts of the question tend to do better than the ones that go straight to typing. We need to learn how you think, and putting a screen in front of people tends to make them clam up. If all I see is the code you write and you don't explain your thinking behind it, I don't get much data. > under time pressure. That part is really hard too. The reality is that interviewers and candidates have a limited amount of time they can put into this process. Keep in mind that most candidates are currently employed and don't want their job to know they are interviewing. Many of them travel to interview. There are only so many hours.

codazoda 10y ago

This seems to be the type of employee Google is looking for, in which case, it works great.

pmontra 10y ago
Maybe it's not what they are looking for. Maybe it's only the easiest test, like looking for the keys under the lamp post. It could also be that this way of hiring people turned the company into a specific direction, more attention to the sw and less to the customers.
- lallysingh 10y ago
  Or visa-versa, that the company always cared more about the sw than the customers, and the hiring methodology reflects that.
- maverick_iceman 10y ago
  It seems to be working fine for them.
  - Apocryphon 10y ago
    Is it?
    - maverick_iceman 10y ago
      https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=goog https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...

Adverblessly 10y ago

When I was interviewed for a job at Google I was told there would be 5 different interviews measuring 5 different things: Pure Algo (which I view as "let's see that your CS grades were earned and not bought") Pure Coding (let's see if you have a reasonable coding style and design and are proficient with at least one language) Algo & Coding (a bit of both that makes sure you can solve a simple problem and code it [i.e. work entirely through a problem]) Software Design (so more on your skill in designing code - finding the right abstractions and interfaces etc.) Systems Design (your ability to design complete, large scale systems at a very high level) And this is more or less what I got, which seemed fair and logical to me. I agree that it is not tailored to the interviewee's individual skills (for example, your special training in cyber security is unlikely to give you an extra edge), but it makes sense for "good overall software engineer", and if you aren't also a good overall software engineer in addition to your special training in cyber security, then you are probably not what Google is trying to find. Also, it does look at your skills in coding and design which are both non-algorithmic. Now whether or not this experience is shared with other interviewees, or matches what you are looking for is something else :X

munificent 10y ago

> it is not sensitive to non-algorithmic skills and talents that interviewees have. I work at Google and do interviews (though I don't enjoy them). We do ask questions around domain expertise, software design, etc. It's not all just coding and algorithms. A good question: 1. Has a low enough floor that a poor candidate can still make some progress and not feel like they are doing poorly and get stressed out. 2. Has a high enough ceiling that a strong candidate doesn't blow through it in five minutes. 3. Has a smooth ramp between those points. 4. Doesn't rely on too much domain-specific knowledge so that a candidate who happens to have a random gap in their background that leaves them totally hosed. 5. Is concrete enough that the interviewer can capture that feedback in a way that the hiring committee can easily understand. 6. Isn't well-known outside of Google as stock interview question so that candidates can game us by just learning the answer. 7. Isn't asked by any of the other interviewers the candidates sees. 8. Can be explained and worked through in about twenty minutes. In case it isn't obvious, it is really really hard to find good questions that pass that gauntlet. Questions do tend to skew towards smaller-scale algorithm coding questions because I think those tend to survive that gauntlet better than most other questions. > unusually good at algorithm puzzles Interviewers are trained to not ask "puzzle" or "trick" questions. Not only are trick questions a shitty experience for the candidate, they are a shitty experience for the interviewer too. My job in an interview is to get as much data as I can about a candidate in order to provide information to the hiring committee. If I ask you a trick question, I get about one bit—in the binary sense—of data from you: did you find the trick or not? I don't think you have to be unusually good at algorithms. I basically read some Wikipedia articles and spent a few hours in the hotel cramming Algorithms in a Nutshell, and I managed to squeak through. That time was incredibly well-spent. Since then, I have relied on that algorithm knowledge way more than I expected too, and have since spent more time learning algorithms and data structures because I can clearly see it's made me a better programmer. > on whiteboards, That part is hard. We allow candidates to use a laptop too, if they prefer, or both. My experience is that candidates who use the whiteboard, at least for the earlier "design" parts of the question tend to do better than the ones that go straight to typing. We need to learn how you think, and putting a screen in front of people tends to make them clam up. If all I see is the code you write and you don't explain your thinking behind it, I don't get much data. > under time pressure. That part is really hard too. The reality is that interviewers and candidates have a limited amount of time they can put into this process. Keep in mind that most candidates are currently employed and don't want their job to know they are interviewing. Many of them travel to interview. There are only so many hours.