4 ms·
> 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 q
by 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 agoThis 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 agoThis 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.