4 ms·
The best book I've read on hiring is "Who: The A Method for Hiring." It's so good in fact that I feel kind of bad sharing it, almost as if I were giving away a
by elbasti 5y ago
The best book I've read on hiring is "Who: The A Method for Hiring." It's so good in fact that I feel kind of bad sharing it, almost as if I were giving away a competitive advantage.
It makes a very simple point that runs counter to most silicon valley talk about "hire for slope not Y intercept" or "hire hustle" or whatever:
Hire people that have the skills necessary for the job that needs to be done. That's it! It sounds simple to the point of ridiculousness, but the truth is that most job descriptions/roles in an organization are written in a lazy way, in which the org has not actually done the work to figure out what specific skills are required by the organization to complete it's mission.
So instead, they hire for generalists, or for "people they like" or for people that fit a pattern--all because they haven't actually done the work to figure out what skills are actually needed.
Examples. A small startup puts up a job description for "senior ruby engineer." If the org is bottlenecked because they are working on very tricky code they should be interviewing for a very different engineer than if they are bottlenecked because they actually need someone who can ship simple CRUD features fast. "oh, but see we only hire senior engineers because {reasons}." Balderdash! Think about the problems you actually have, the skills and experience required to guarantee (or as close to it) that a candidate can Do The Job, and go.
- UnpossibleJim 5y agoWait, are you saying the STE job I saw at Amazon might not need a master's degree in CS? Preposterous! =P
- BlueDingo 5y agoIn that scenario, is everyone hired on a contract basis? Do good workers get dumped after successful projects simply because the requirement they were desired for is complete? I think companies hire for general skills not just because they aren't clear about goals, but because they're dealing with people. I get why you like the idea but you can't just malloc and delete people, they need some stability. And since the company probably won't be dropping their tech stack with each new project, hiring for knowledge in an area rather than knowledge of a narrower task seems reasonable?
- anon9001 5y agoCorollary: Have your interviewers be experts in the specific are you're trying to hire. If you need a ruby engineer, don't submit them to a generic hiring panel. Have them spend an hour or two talking shop and doing some pair programming with one of your most expert rubyists. Master craftsmen can pick each other out in a second, but a whole hiring panel can fail to spot both bullshit and greatness.
- HWR_14 5y agoHave at least one interview stage with experts in something specific. Having someone else filter out "cannot program" is fine to prevent the Sr. Ruby Engineer from looking at 95% "cannot program" candidates. But that whole thing fails because often a skill needed is new. The easiest example I can think of is when a startup goes from 0 to 1 in the HR/legal/accounting areas.