4 ms·

As someone who occasionally has hiring responsibility I sympathise with both interviewer and interviewee. It is extremely tricky to determine if the person you

As someone who occasionally has hiring responsibility I sympathise with both interviewer and interviewee. It is extremely tricky to determine if the person you have interviewed is going to fit the bill. I've hired people who I thought would be a great fit for permanent roles but turned out to be the worst kind of procrastinating, one trick ponies who caused more problems than they fixed. In a recent situation I had a very specific set of requirements for very specific reasons. The company is .net all the way and has a couple of permanent developers who know only VB and have no C# experience. Because of a large influx of work, these developers needed some additional resource for a short period of time. I wanted to try and increase the skill level of the permanent developers as they are not very familiar with design patterns and 'modern' techniques. To this end, I wanted C# developers with familiarity with design patterns and modern best practice to come in and develop in VB. I didn't care if they hadn't used VB recently at all. But I did care that they knew .net. I don't have time for them to learn .net. So I can't have someone from the Java world, it would just take too long. But at the same time, I'd rather not have a VB only person, as they tend (and I am generalising, I know) to not understand much about design patterns and they don't tend to have broad programming knowledge. When interviewing for a specific role, you have to think very hard about what it is you are trying to do - and don't just fall back on generic cut and paste questions.

jasonwocky 12y ago
> When interviewing for a specific role, you have to think very hard about what it is you are trying to do - and don't just fall back on generic cut and paste questions. I think this is true, but it raises a question about "hiring for a specific role." I find that when companies do this, they're in a reactive mode. Which of course is going to happen from time to time, but the reason memes like the OP get born is because many companies are habitually reactive when it comes to hiring. I don't follow a lot of sports, but I follow NFL football. Each year, the teams get to "draft" (a/k/a hire) incoming players from college. When it comes to the NFL draft, there are two prevailing philosophies: "Draft for Need" and "Draft Best Player Available". Without question, teams that stick to more of a BPA approach tend to have longer term success. Teams that draft for need sometimes get that player that helps them get over the hump and win a championship, but more often they're trading away long-term greatness for some short-term pain relief. I think hiring for software teams (and just about anything where there is a lot of variance in depth and breadth of skill) follows the same pattern. Hiring for a specific role is an antipattern (albeit sometimes a necessary one). If you have a very specific role to fill, perhaps a freelancer or a consultant might be a better fit for easing the short-term pain. Then you let them go as soon as they're no longer needed.
- andkon 12y ago
  This is a really, really cool idea. I think the danger with BPA is that if you're hiring them way too early (like... a year before they'd be firing on all cylinders), then you risk them disengaging and churning out. NFL teams have a constant amount and kind of work that's predictable every season that prevents them from misallocating investments like this - and prevents players from misallocating their labour. Software teams, on the other hand, risk building the wrong thing, and hiring people for problems that won't come about until they build the right thing. Which usually means that those people get antsy (I definitely had this experience, but in a marketing role, which is even more stage-dependent than working dev positions, so I'm probably a little more sensitive to the chance and impact of being hired too early).
  - jasonwocky 12y ago
    This sounds reasonable, though if you hire the Best-Programmer-Available regardless of the presence of a specific technical skill, I'd be surprised if they really take a year to get firing on all cylinders. Maybe a month or two at most would be what I would expect in the sorts of places I've worked. Sure, some places (especially in startup land) can't even afford to wait even a month, but that doesn't make the dynamic any less of an antipattern. Instead it's just one of the painful tradeoffs people make while they need to manage their runway extra closely.

jasonwocky 12y ago

> When interviewing for a specific role, you have to think very hard about what it is you are trying to do - and don't just fall back on generic cut and paste questions. I think this is true, but it raises a question about "hiring for a specific role." I find that when companies do this, they're in a reactive mode. Which of course is going to happen from time to time, but the reason memes like the OP get born is because many companies are habitually reactive when it comes to hiring. I don't follow a lot of sports, but I follow NFL football. Each year, the teams get to "draft" (a/k/a hire) incoming players from college. When it comes to the NFL draft, there are two prevailing philosophies: "Draft for Need" and "Draft Best Player Available". Without question, teams that stick to more of a BPA approach tend to have longer term success. Teams that draft for need sometimes get that player that helps them get over the hump and win a championship, but more often they're trading away long-term greatness for some short-term pain relief. I think hiring for software teams (and just about anything where there is a lot of variance in depth and breadth of skill) follows the same pattern. Hiring for a specific role is an antipattern (albeit sometimes a necessary one). If you have a very specific role to fill, perhaps a freelancer or a consultant might be a better fit for easing the short-term pain. Then you let them go as soon as they're no longer needed.

andkon 12y ago
This is a really, really cool idea. I think the danger with BPA is that if you're hiring them way too early (like... a year before they'd be firing on all cylinders), then you risk them disengaging and churning out. NFL teams have a constant amount and kind of work that's predictable every season that prevents them from misallocating investments like this - and prevents players from misallocating their labour. Software teams, on the other hand, risk building the wrong thing, and hiring people for problems that won't come about until they build the right thing. Which usually means that those people get antsy (I definitely had this experience, but in a marketing role, which is even more stage-dependent than working dev positions, so I'm probably a little more sensitive to the chance and impact of being hired too early).
- jasonwocky 12y ago
  This sounds reasonable, though if you hire the Best-Programmer-Available regardless of the presence of a specific technical skill, I'd be surprised if they really take a year to get firing on all cylinders. Maybe a month or two at most would be what I would expect in the sorts of places I've worked. Sure, some places (especially in startup land) can't even afford to wait even a month, but that doesn't make the dynamic any less of an antipattern. Instead it's just one of the painful tradeoffs people make while they need to manage their runway extra closely.