3 ms·

Yes. Unless you're not the only person we're looking at hiring. We're not going to pay 10 people for a week and hire just one. We'd rather we get a sample by se

Yes. Unless you're not the only person we're looking at hiring. We're not going to pay 10 people for a week and hire just one. We'd rather we get a sample by seeing you do some work on a whiteboard, and make some cuts right then and there. In other words: yes, that's a better way for you to prove yourself. No, we don't have the resources for this approach.

enraged_camel 10y ago
You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maximize the chances of hiring really good people, right? The latter will pay for themselves tenfold.
- EpicEng 10y ago
  I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one week eval (and they usually have a job already, so how are they going to get away for a week?). This is a time consuming and expensive proposition which would require buy in at multiple levels from multiple departments and would probably end up not working out so well.
  - richforrester 10y ago
    Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."
    - enraged_camel 10y ago
      It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates. If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.
      - TheCoelacanth 10y ago
        Admittedly, whiteboard exercises are not good, but what better alternative is there that will not take an order of magnitude more time?
      - efaref 10y ago
        If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it. I think if you approach them correctly (like the author suggests), then actually they're fine for their intended use. (Not perfect, but this is the real world, nothing's perfect). If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line."
        xentronium 10y ago
        > If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it. You are wrong. Just because it's most used currently doesn't mean it's better. And it is actually well documented. @tokenadult posted this numerous times: https://news.ycombinator.com/item?id=4879803 https://news.ycombinator.com/item?id=4879803
        vonmoltke 10y ago
        > If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line." First, "scrawling some pseudocode on a whiteboard" and "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" are not the same thing and it is fallacious to use performance on one to infer performance on the other. "Stress" is not some universal feeling that differs from situation to situation only in amount. It has types, which different people handle differently. Second, related to my response to a sibling comment, if "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" has a high enough probability of occurring that it is worthwhile to screen candidates for ability to handle this, your company is fundamentally broken and you are trying to use your hiring to compensate for the real problems.
  - p4wnc6 10y ago
    I've never worked in any company that was able to fill any position faster than 2.5 months. Everyone clamored that we needed to fill positions fast, but then endless, nauseating political debates about minutiae on resumes and tiny flaws during in-person interviews took over, and it would just drag on. I once was taken almost completely away from my engineering duties for a period of a whole month to help almost full time with what was a "critical" position that needed to be filled "now". A year and half later, when I decided to leave that company, they still had not hired for that position, and had an endless list of why every candidates didn't make the cut (and we had interviewed some excellent candidates who got thumbs up from all of the technical staff who had interviewed them). It's different everywhere, but in general for a competent tech worker with about 3+ years of experience, I'd say you're looking at at least 6 months to find someone, probably closer to a year, not because there fails to be a supply of good candidates, but because that's just the time penalty for internal politics. While this particular anecdote happened at an established firm, I experienced nearly the exact same thing in start-ups as well, literally the same political bullshit excuses used to reject otherwise great candidates even when we were "desperate" to hire someone.

enraged_camel 10y ago

You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maximize the chances of hiring really good people, right? The latter will pay for themselves tenfold.

EpicEng 10y ago
I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one week eval (and they usually have a job already, so how are they going to get away for a week?). This is a time consuming and expensive proposition which would require buy in at multiple levels from multiple departments and would probably end up not working out so well.
- richforrester 10y ago
  Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."
  - enraged_camel 10y ago
    It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates. If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.
    - TheCoelacanth 10y ago
      Admittedly, whiteboard exercises are not good, but what better alternative is there that will not take an order of magnitude more time?
    - efaref 10y ago
      If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it. I think if you approach them correctly (like the author suggests), then actually they're fine for their intended use. (Not perfect, but this is the real world, nothing's perfect). If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line."
      - xentronium 10y ago
        > If by "well documented" you mean "lots of people have whinged about it at great length", then I guess you're right. It's also a "tried and tested" method, too, so it's got that going for it. You are wrong. Just because it's most used currently doesn't mean it's better. And it is actually well documented. @tokenadult posted this numerous times: https://news.ycombinator.com/item?id=4879803 https://news.ycombinator.com/item?id=4879803
      - vonmoltke 10y ago
        > If you can't cope with scrawling some pseudocode on a whiteboard because that's "too much pressure" then you're going to really struggle when a deadline looms and we "absolutely must get this code out to the customer by Friday because a $50M contract is on the line." First, "scrawling some pseudocode on a whiteboard" and "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" are not the same thing and it is fallacious to use performance on one to infer performance on the other. "Stress" is not some universal feeling that differs from situation to situation only in amount. It has types, which different people handle differently. Second, related to my response to a sibling comment, if "we absolutely must get this code out to the customer by Friday because a $50M contract is on the line" has a high enough probability of occurring that it is worthwhile to screen candidates for ability to handle this, your company is fundamentally broken and you are trying to use your hiring to compensate for the real problems.
- p4wnc6 10y ago
  I've never worked in any company that was able to fill any position faster than 2.5 months. Everyone clamored that we needed to fill positions fast, but then endless, nauseating political debates about minutiae on resumes and tiny flaws during in-person interviews took over, and it would just drag on. I once was taken almost completely away from my engineering duties for a period of a whole month to help almost full time with what was a "critical" position that needed to be filled "now". A year and half later, when I decided to leave that company, they still had not hired for that position, and had an endless list of why every candidates didn't make the cut (and we had interviewed some excellent candidates who got thumbs up from all of the technical staff who had interviewed them). It's different everywhere, but in general for a competent tech worker with about 3+ years of experience, I'd say you're looking at at least 6 months to find someone, probably closer to a year, not because there fails to be a supply of good candidates, but because that's just the time penalty for internal politics. While this particular anecdote happened at an established firm, I experienced nearly the exact same thing in start-ups as well, literally the same political bullshit excuses used to reject otherwise great candidates even when we were "desperate" to hire someone.