6 ms·

> (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way. Because every method of hiring has its own biases a

by jasode 11y ago

> (ie, work sample tests), I do not understand why any tech company does developer hiring in any other way. Because every method of hiring has its own biases and tradeoffs. Requiring work samples biases against programmers who aren't interested in doing a "homework assignment". For example, I don't enjoy whiteboard interviews but I'd rather write some fragments in front of the interviewer and "think out loud" instead of working on a multi-hour (or multi-day) coding project. Writing on a whiteboard is just not that big of a pressure cooker to me. One could argue that the majority would prefer self-paced work samples instead of whiteboard interviews and you're optimizing for a wider candidate pool. That's fine but it's still a tradeoff. I think you're running a smaller scale boutique firm so work samples makes sense for you. For a company like Google Inc who is more selective[1] than Harvard University, I don't see a compelling need for them to rely on work samples. That company is so desirable for programmers that any "work samples" Google tries to standardize on would get leaked and endlessly discussed on stackoverflow (see FizzBuzz for precedence.) If Google has to keep changing out the work samples to stay ahead of the street knowledge, you've lost the ability to compare work samples over the years which was one of the motivations to use that method in the first place. At their scale and selectivity, the "study your algorithms book and prepare to be grilled on the whiteboard" seems to work best for them. Yes, they reject a lot of false-negatives but it's offset by ... their scale and selectivity. They can afford to reject false-negatives. If their screening methods were truly terrible, I don't see how the label "ex-Googler" would have the currency it does in the marketplace. [1]http://thenextweb.com/google/2010/09/14/one-half-of-one-percent-of-google-applicants-get-hired-heres-how-it-works/#gref http://thenextweb.com/google/2010/09/14/one-half-of-one-perc...

kasey_junk 11y ago
> For a company like Google Inc who is more selecitve than Harvard University Nitpick, but I'd love to see a citation on that. Google, like every technology company on the planet (modulo a small error value) goes to great lengths to recruit and hires lots and lots of people.
- jasode 11y ago
  See my previous footnote about them receiving 1 million resumes to fill 1,000 slots. If that's true, it is more selective than any Ivy League university. Here's another one showing 75,000 resumes received in one week: http://www.sfgate.com/business/article/Google-gets-record-75-000-resumes-in-a-week-2460557.php http://www.sfgate.com/business/article/Google-gets-record-75... When you have the luxury to pick the best, from the best of the best, you don't have to follow the advice given by HN armchair quarterbacks like us.
  - tptacek 11y ago
    No. That's not how a market works. Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it. And engineer headcount costs are a huge component of their business --- so much so that they've been accused of breaking the law to collude with other companies to avoid competition in hiring! Google is succeeding in spite of the waste and unreliability of their hiring processes, not because of them.
    - vonmoltke 11y ago
      Finally, some validation that my interpretation of their process is not insane. One thing that really rustles my jimmies is the constant assertion that "false negatives are (effectively) free". I think Google and the companies who hire like them seriously underestimate how much this costs them, both the direct costs of spending so much to ultimately reject people and the indirect costs from the work that is not getting done or being foisted on another overloaded engineer.
      - JoeAltmaier 11y ago
        The root issue is that, the costs of bad hiring are even higher than that. For a rapidly-growing company bad hires can snowball into a bad organization.
        11y ago
hibikir 11y ago
It's easy to be selective. I can ask all comers with a degree to roll three dice, and if they don't roll three sixes, I consider them unworthy. Only about 0.5% of candidates will pass. That's a pretty selective first screening, isn't it? Selectivity is only good if it selects for traits you want, and, in practice, what you want is not a uniform skillset. So being selective for one trait, any trait, is already a bad idea. Even the basics of the interview format make a difference. At other companies, all coding interviews are timed at 45 minutes or so, including the problem statement. It's a bit like going to an episode of Chopped. It's certainly selecting for 'can you think under pressure' along with 'are you friendly enough that your interviewer will help you when you are getting something wrong without docking your score'. But that's not good for a careful candidate that is trying to build sturdy, reliable code. So guess what: The company's codebase has few tests, things fail often when deployed to production, and reliability is a problem. It's not that they are willingly selecting against careful programmers, but it's a consequence of the interview process. The moment you are hiring a lot of people, and you think you have a single model that works, you are hiring from a cookie cutter, and you'll get gingerbread men.
tptacek 11y ago
The "no homework" thing is such a red herring. Companies that do work samples minimize on-site coding interviews, because the whole point of offsite work sample testing is that most candidates can't provide an accurate picture of their aptitude in an on-site coding interview. No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission. Nobody wants to do homework that goes into a black hole, only to find out 6 months later that they were in consideration for the role. That's a problem with all hiring companies, and it is orthogonal to the structure of the interview itself.
- jasode 11y ago
  >No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. Sure, Google/Microsoft have the legendary "6 hour" marathon interviews with multiple teams with lunch in the middle but for smaller scale of companies, they don't have bandwidth to mess around with all-day interviews. It's ~2 hours. In this thread, it shows I'm not the only one who prefers onsite whiteboard over homework projects so the "no developer prefers" claim is too absolutist. >The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission. Regardless if the feedback is received within 10 minutes or 10 days of submission, if I apply to 4 companies, I don't want to do 4 homework projects. I simply don't. At least with 4 onsite interviews, I see glimpses of the office and meet the interviewers.
  - tptacek 11y ago
    This is just not true. I talk to interviewing developers every day, and very few of them are interviewing at Google. The final round of on-site interviews usually eats a whole day, and is preceded by a whole battery of time-wasting phone interviews, which themselves eat as much time as a coding challenge and often involve coding with someone else over the phone or Skype. There are companies that are not Google that have multiple rounds of on-site interviews.

by jasode 11y ago

kasey_junk 11y ago

> For a company like Google Inc who is more selecitve than Harvard University Nitpick, but I'd love to see a citation on that. Google, like every technology company on the planet (modulo a small error value) goes to great lengths to recruit and hires lots and lots of people.

jasode 11y ago
See my previous footnote about them receiving 1 million resumes to fill 1,000 slots. If that's true, it is more selective than any Ivy League university. Here's another one showing 75,000 resumes received in one week: http://www.sfgate.com/business/article/Google-gets-record-75-000-resumes-in-a-week-2460557.php http://www.sfgate.com/business/article/Google-gets-record-75... When you have the luxury to pick the best, from the best of the best, you don't have to follow the advice given by HN armchair quarterbacks like us.
- tptacek 11y ago
  No. That's not how a market works. Google can in fact maintain high and consistent standards for incoming developers. But because their processes are so dysfunctional, they overpay to do it. And engineer headcount costs are a huge component of their business --- so much so that they've been accused of breaking the law to collude with other companies to avoid competition in hiring! Google is succeeding in spite of the waste and unreliability of their hiring processes, not because of them.
  - vonmoltke 11y ago
    Finally, some validation that my interpretation of their process is not insane. One thing that really rustles my jimmies is the constant assertion that "false negatives are (effectively) free". I think Google and the companies who hire like them seriously underestimate how much this costs them, both the direct costs of spending so much to ultimately reject people and the indirect costs from the work that is not getting done or being foisted on another overloaded engineer.
    - JoeAltmaier 11y ago
      The root issue is that, the costs of bad hiring are even higher than that. For a rapidly-growing company bad hires can snowball into a bad organization.
      - 11y ago

hibikir 11y ago

It's easy to be selective. I can ask all comers with a degree to roll three dice, and if they don't roll three sixes, I consider them unworthy. Only about 0.5% of candidates will pass. That's a pretty selective first screening, isn't it? Selectivity is only good if it selects for traits you want, and, in practice, what you want is not a uniform skillset. So being selective for one trait, any trait, is already a bad idea. Even the basics of the interview format make a difference. At other companies, all coding interviews are timed at 45 minutes or so, including the problem statement. It's a bit like going to an episode of Chopped. It's certainly selecting for 'can you think under pressure' along with 'are you friendly enough that your interviewer will help you when you are getting something wrong without docking your score'. But that's not good for a careful candidate that is trying to build sturdy, reliable code. So guess what: The company's codebase has few tests, things fail often when deployed to production, and reliability is a problem. It's not that they are willingly selecting against careful programmers, but it's a consequence of the interview process. The moment you are hiring a lot of people, and you think you have a single model that works, you are hiring from a cookie cutter, and you'll get gingerbread men.

tptacek 11y ago

The "no homework" thing is such a red herring. Companies that do work samples minimize on-site coding interviews, because the whole point of offsite work sample testing is that most candidates can't provide an accurate picture of their aptitude in an on-site coding interview. No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission. Nobody wants to do homework that goes into a black hole, only to find out 6 months later that they were in consideration for the role. That's a problem with all hiring companies, and it is orthogonal to the structure of the interview itself.

jasode 11y ago
>No interviewing software developer prefers an extra 6 hours of on-site interview to an off-site coding challenge. Sure, Google/Microsoft have the legendary "6 hour" marathon interviews with multiple teams with lunch in the middle but for smaller scale of companies, they don't have bandwidth to mess around with all-day interviews. It's ~2 hours. In this thread, it shows I'm not the only one who prefers onsite whiteboard over homework projects so the "no developer prefers" claim is too absolutist. >The problem developers have with "homework problems" is really a problem with bullshit companies that won't provide timely feedback on their submission. Regardless if the feedback is received within 10 minutes or 10 days of submission, if I apply to 4 companies, I don't want to do 4 homework projects. I simply don't. At least with 4 onsite interviews, I see glimpses of the office and meet the interviewers.
- tptacek 11y ago
  This is just not true. I talk to interviewing developers every day, and very few of them are interviewing at Google. The final round of on-site interviews usually eats a whole day, and is preceded by a whole battery of time-wasting phone interviews, which themselves eat as much time as a coding challenge and often involve coding with someone else over the phone or Skype. There are companies that are not Google that have multiple rounds of on-site interviews.