Hiring Technical People

Screening and Speed

In his post, Scary - For Real!, Hank discusses a change in the hiring climate. Turns out, there is competition, at least in some places, for technical folks. (Good news to lots of great people.) He mentions some organizations’ troubles finding people and waiting too long to make an offer (and waiting too long for people to start).

I’m not a recruiter, so I don’t know enough about the competition for certain people. But I do know that too many hiring managers are screening out otherwise great candidates because the hiring managers don’t know how to see what’s in front of them.

Make sure you’re not screening out people who could perform the work:

• If you’re a hiring manager still using puzzles, cut that out! Puzzles don’t tell you a think about how people work at work. They tell you whether this person likes to do puzzles — not a predictor of great job performance.
• If you still think you need some number of years of some language or environment, stop using shorthand and describe what deep knowledge you’re looking for. Maybe you can find it some other way. Maybe you don’t need some number of years, but you need some kind of application context.
• If you think you need someone with a degree, stop right there. (Unfortunately, the comments from a previous post about this are gone.) I realize that things may be different across the world. But certainly, in the US, a degree is not a predictor of job success.

The other part of Hank’s article deals with speed of getting people to start. Speed comes from paying attention to all parts of hiring every day: screening resumes, using multiple sourcing schemes, using a group interview and limited consensus to make hiring decisions, knowing what kind of an offer would make a candidate say yes, making an offer promptly, checking references quickly, and making a start date that’s relatively soon.

Make sure you’re screening people on what really matters — things that predict their ability to do their jobs. And make sure that you make time for your hiring activities.

1 comment March 3rd, 2005

No Cog Positions

Set Godin, in his The ever-worsening curse of the cog says something profound:

The end result is that it’s essentially impossible to become successful or well off doing a job that is described and measured by someone else.

I still think managers can describe parts of a useful, non-cog job. But jobs where a person’s qualities, preferences, and non-technical skills don’t matter are going to be outsourced or automated. Here’s an example: If you’re looking for a manual black box tester, why? If that person has to wait until the product exists to test, what value does that person add to development of the product? That’s a cog position, unless you can articulate some specific value that this person will add, that can’t be automated or outsourced. Another example: if you’re looking for a fill-in-the-blank language (Cobol, Java, C#, any language) programmer, what value is that person supposed to add? Why aren’t you looking for people who live to break software in various ways, if you’re looking for testers? Why aren’t you looking for people who solve a variety of problems using a variety of functional skill expertise? (If you’re hiring for other positions, think about the variety of functional skills required by the position.) The more varied the required functional skills, the more valuable your position is, and the less cog-like it is. The less cog-like, the less of a commodity it is. So it’s clear why candidates want not-cog positions. But why should employers care? Because you’re in business to deliver results and build capacity. You can’t deliver results without people who can adapt their skills to your context. You can’t build capacity without people who can learn new things. Two very un-cog-like reasons. Without delivering results and building capacity, the organization dies, eventually. It’s very expensive in the medium- and long-term to hire for cog positions. It’s cheaper to higher fewer non-cogs, but people who can deliver for you.

Add comment March 3rd, 2005