5 ms·

Is the advice here just to take risk in hiring? Yes, that's exactly what we should all be doing more of. Hiring is always a risk, and the "accepted" risk-miti

Is the advice here just to take risk in hiring? Yes, that's exactly what we should all be doing more of. Hiring is always a risk, and the "accepted" risk-mitigation strategies (hiring by keyword, brainteasers, etc.) have been shown to be stubbornly non-predictive. At best they apply a misleading veneer of certainty on an inherently uncertain process, and if I'm going to take a risk I'd at least prefer that I not fool myself about it. So yes, accept more risk in hiring. You're already taking risk, but by accepting the feeling of more risk you'll at least be more deliberate about it.

wheaties 10y ago
To add to this, tasks risks in hiring but fire fast. Seriously as a hiring manager my best hires have been, on paper, the least qualified for the position. And when we've hired bad people, removing them within the span of 6months have been incredibly helpful. The corollary, not firing them fast enough has really hurt.
- underwater 10y ago
  Do the people you're hiring know that this is your playbook?
  - vonmoltke 10y ago
    Since high school I have been under the impression that was how all businesses work. It wasn't until I got into the working world that I realized some organizations are so imbued with CYA that it can take literally years to fire a shitty worker.
  - dpark 10y ago
    This is my concern with the fast-fire strategy. If you do a poor job with the interview process and hire someone who cannot do the job and have to fire them, you're messing up that person's life. They probably had a job before they accepted your offer. Now they're unemployed and it's your fault. Firing people frequently is also expensive and it's demoralizing for the team. You also don't earn loyalty by showing that you have none yourself.
    - BurningFrog 10y ago
      Depends who you fire and why. There are few things more demoralizing for a team than keeping jerks around. Unfortunately, jerks are an overrepresented demographic in programming.
      - dpark 10y ago
        I'm talking specifically about the "tasks risks in hiring but fire fast" strategy above. If your strategy is to hire without due diligence because you'll just fire later, that's extremely inconsiderate and also demoralizing. Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.
        tracker1 10y ago
        The only thing that makes this hard, is when you spend a month looking for a viable candidate, and need work done, and have to pick someone... The person isn't your ideal choice, but the best of those available. It'll work out, or it won't. In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.
        dpark 10y ago
        Sure. You're going to have to hire someone and there's always some risk that it won't work out.
        BurningFrog 10y ago
        I think of it more as a continuum that either full due diligence or hire most anyone who seems decent. I agree that the latter version is wrong, but there is room to adjust how much you work on predicting future performance. How much of a jerk people are is one of the harder things to predict in interviews. I get the feeling we're both speaking with previous unfortunate experiences in mind :)
      - tracker1 10y ago
  - wheaties 10y ago
    I am very clear with how things progress. You have to be: 3mth evaluation, 6mnth evaluation if 3mnth wasn't going well. A clear onboarding process and written docs to get people up to speed. A pairing with another developer. Several story tickets which aren't designed to produce results fast but rather to educate. That said, you also have to have an understanding of your interview process: no brain teasers, no language lawyer questions, etc. A peer reviewed collection of interview questions and a rigid methodology to make sure time pressure/stress/etc. are not part of the interview.
- johan_larson 10y ago
  Yup. Or if not firing, then some other action like redesigning the job around the skills the employee actually has or transferring them to something they can actually do. I've seen this from the other side, when I accepted a job that turned out to require skills I didn't have. It was an unbelievably crappy experience. Prompt action -- within the first six months, maybe -- would have saved a lot of grief.
- CM30 10y ago
  But is this legal in all countries and states? Because in some places, you can definitely take risks in hiring and fire fast, because employment is basically 'at will'. In certain other areas, there are all kinds of restrictions on how/when/why you can fire someone. This might be why a lot of companies use these tests. Because in some places, you need to filter out 'bad' hires before it becomes difficult to dismiss them.
  - nucleardog 10y ago
    Obviously can't speak to everywhere, but the statutes around here (right to work) specifically allow for an initial probationary period. Within the first few months of employment (or less/longer, as set out in a contract), the employee can be easily fired. They want similar reasons to a normal firing (underperforming, inappropriate behaviour, etc) but the information I can find says that the bar is set much lower and they're more just worried about you "acting in good faith". I've rarely (if ever) seen it used. Usually people want to take the time to try and develop the employee, but they end up shooting themselves in the foot. If you hire someone that's not working out you can let them go pretty quickly. Once their probation is up you're stuck with them. So fire fast, don't dick around.
Retric 10y ago
Thresholds seems to be a huge missing component to this stuff. Syntax, obscure trivia, brainteasers, etc are generally terrible predictors. However, if you ask someone to find say the average (mean) value in an array and they can't even get close that's a problem. IMO, this comes from the mistaken assumption that you want to most technically competent person possible. Instead basic competence is a minimum barrier and everything else combined is more important.
- peterbonney 10y ago
  Totally agreed. "Fizzbuzz" has become a bitter joke among good developers, but it tests something (sadly) important: can you write a basic loop and conditional statements? Or more cynically, are you a total fraud? You don't have to ask Fizzbuzz to test that, but you do have to ask something. For me, if you pass the test of basic competence, and you can demonstrate evidence of accomplishment in any language, and you seem to pick things up quickly, then you're probably a risk worth taking. (Actually, ignore everything I'm saying. I don't want the rest of the market to catch on. :)
  - white-flame 10y ago
    If you're hiring a HR manager, do you have them take a basic English skills test? If you hire an electrical engineer, do you test them on understanding Ohm's law? If you hire a window washer, do you test them on cable strength integrity questions?
    - swsieber 10y ago
      I'm not sure about the point of your post, but to respond: 1) No - you screen those out with spelling mistakes in their resume 2) Maybe? I'm not sure - I'm not an electrical engineer. Then again, credentialing an EE is probably easier than a programmer. 3) This one's not even a good analogy - of course not. What makes programming a little different is that it's turtles all the way down. While you might not need to find the average of an array, you will need the ability to reason about such things. You'll be reducing a collection of items, or mapping them or summing them. You basically must deal with abstraction as a computer programmer. (And I'd argue that yes, assembly deals with abstraction)

wheaties 10y ago

To add to this, tasks risks in hiring but fire fast. Seriously as a hiring manager my best hires have been, on paper, the least qualified for the position. And when we've hired bad people, removing them within the span of 6months have been incredibly helpful. The corollary, not firing them fast enough has really hurt.

underwater 10y ago
Do the people you're hiring know that this is your playbook?
- vonmoltke 10y ago
  Since high school I have been under the impression that was how all businesses work. It wasn't until I got into the working world that I realized some organizations are so imbued with CYA that it can take literally years to fire a shitty worker.
- dpark 10y ago
  This is my concern with the fast-fire strategy. If you do a poor job with the interview process and hire someone who cannot do the job and have to fire them, you're messing up that person's life. They probably had a job before they accepted your offer. Now they're unemployed and it's your fault. Firing people frequently is also expensive and it's demoralizing for the team. You also don't earn loyalty by showing that you have none yourself.
  - BurningFrog 10y ago
    Depends who you fire and why. There are few things more demoralizing for a team than keeping jerks around. Unfortunately, jerks are an overrepresented demographic in programming.
    - dpark 10y ago
      I'm talking specifically about the "tasks risks in hiring but fire fast" strategy above. If your strategy is to hire without due diligence because you'll just fire later, that's extremely inconsiderate and also demoralizing. Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.
      - tracker1 10y ago
        The only thing that makes this hard, is when you spend a month looking for a viable candidate, and need work done, and have to pick someone... The person isn't your ideal choice, but the best of those available. It'll work out, or it won't. In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.
        dpark 10y ago
        Sure. You're going to have to hire someone and there's always some risk that it won't work out.
      - BurningFrog 10y ago
        I think of it more as a continuum that either full due diligence or hire most anyone who seems decent. I agree that the latter version is wrong, but there is room to adjust how much you work on predicting future performance. How much of a jerk people are is one of the harder things to predict in interviews. I get the feeling we're both speaking with previous unfortunate experiences in mind :)
    - tracker1 10y ago
- wheaties 10y ago
  I am very clear with how things progress. You have to be: 3mth evaluation, 6mnth evaluation if 3mnth wasn't going well. A clear onboarding process and written docs to get people up to speed. A pairing with another developer. Several story tickets which aren't designed to produce results fast but rather to educate. That said, you also have to have an understanding of your interview process: no brain teasers, no language lawyer questions, etc. A peer reviewed collection of interview questions and a rigid methodology to make sure time pressure/stress/etc. are not part of the interview.
johan_larson 10y ago
Yup. Or if not firing, then some other action like redesigning the job around the skills the employee actually has or transferring them to something they can actually do. I've seen this from the other side, when I accepted a job that turned out to require skills I didn't have. It was an unbelievably crappy experience. Prompt action -- within the first six months, maybe -- would have saved a lot of grief.
CM30 10y ago
But is this legal in all countries and states? Because in some places, you can definitely take risks in hiring and fire fast, because employment is basically 'at will'. In certain other areas, there are all kinds of restrictions on how/when/why you can fire someone. This might be why a lot of companies use these tests. Because in some places, you need to filter out 'bad' hires before it becomes difficult to dismiss them.
- nucleardog 10y ago
  Obviously can't speak to everywhere, but the statutes around here (right to work) specifically allow for an initial probationary period. Within the first few months of employment (or less/longer, as set out in a contract), the employee can be easily fired. They want similar reasons to a normal firing (underperforming, inappropriate behaviour, etc) but the information I can find says that the bar is set much lower and they're more just worried about you "acting in good faith". I've rarely (if ever) seen it used. Usually people want to take the time to try and develop the employee, but they end up shooting themselves in the foot. If you hire someone that's not working out you can let them go pretty quickly. Once their probation is up you're stuck with them. So fire fast, don't dick around.

Retric 10y ago

Thresholds seems to be a huge missing component to this stuff. Syntax, obscure trivia, brainteasers, etc are generally terrible predictors. However, if you ask someone to find say the average (mean) value in an array and they can't even get close that's a problem. IMO, this comes from the mistaken assumption that you want to most technically competent person possible. Instead basic competence is a minimum barrier and everything else combined is more important.

peterbonney 10y ago
Totally agreed. "Fizzbuzz" has become a bitter joke among good developers, but it tests something (sadly) important: can you write a basic loop and conditional statements? Or more cynically, are you a total fraud? You don't have to ask Fizzbuzz to test that, but you do have to ask something. For me, if you pass the test of basic competence, and you can demonstrate evidence of accomplishment in any language, and you seem to pick things up quickly, then you're probably a risk worth taking. (Actually, ignore everything I'm saying. I don't want the rest of the market to catch on. :)
- white-flame 10y ago
  If you're hiring a HR manager, do you have them take a basic English skills test? If you hire an electrical engineer, do you test them on understanding Ohm's law? If you hire a window washer, do you test them on cable strength integrity questions?
  - swsieber 10y ago
    I'm not sure about the point of your post, but to respond: 1) No - you screen those out with spelling mistakes in their resume 2) Maybe? I'm not sure - I'm not an electrical engineer. Then again, credentialing an EE is probably easier than a programmer. 3) This one's not even a good analogy - of course not. What makes programming a little different is that it's turtles all the way down. While you might not need to find the average of an array, you will need the ability to reason about such things. You'll be reducing a collection of items, or mapping them or summing them. You basically must deal with abstraction as a computer programmer. (And I'd argue that yes, assembly deals with abstraction)