Saturday, April 19, 2008

Hiring technique: "the blitz"

So I like to think that I have become good at hiring people. I'm definitely not bad at it. Over the past couple years I have generally been good at hiring people who are way smarter than me. That's what you do when you are a Lean manager and you aren't stupid or insecure.

My techniques are not magic, but they seem to be quite different than how I see lots of managers/companies operating.

If you have determined that you truly need to hire someone, that generally means that your team is hurting - it needs resources that it doesn't have - at some level you are already failing. Your #1 mission as a Lean manager is to protect the team and to get it the stuff it needs to be successful. Once you are in this position, barring a crisis, you have no task that is more important than filling the position with the most qualified person you can find as quickly as possible.

So my co-worker Ed termed what I do yesterday, "the blitz". Here is generally how it works:

Step 1: Collect Qualified Peeps
  • Check your network for a trusted person.
  • If FAIL, post job to the places the kewl kids are. Examples here and here
  • If FAIL, post job to craigslist and batten down the hatches - you are going to get inundated with qualified and unqualified people contacting you. DO NOT put your phone number on these job postings.
  • If FAIL, do WHATEVER YOU NEED TO DO to find qualified candidates. Get creative, clocks tickn'.
Step 2: Quick Vetting
  • Pick the ones that look like they are truly talented and passionate.
  • Schedule in person interview for today or tomorrow
  • Short list.
Step 3. Homework Torture Test
  • Give the short list candidates a homework assignment. Something they can do in a couple of hours that will make it abundantly clear who is the most talented & the best fit.
Step 4. Second Opinion
  • Define decision making rules so everybody on the team understands how the decision will be made (e.g., unanimous vote, majority, or defer decision to manager for expediency and efficiency)
  • Depending on the position, pick one, more, or all people from the team to interview the finalists after they have reviewed the homework results for fit, talent, and passion.
  • Gather feedback
Step 5. Pick, yer done or Rinse and Repeat if FAIL

I think the only major difference compared to typical hiring practices is in how I do this. I go all in. It's a blitz. When I'm in this mode, I generally do it 8-12 hours a day until I'm done. I can generally wrap up hiring someone in <= 2 weeks from start to finish. And the results generally speak for themselves. This technique works great for me as the "hiring manager" and for job candidates.

Hiring people can be quick and painless or can drag on and on for weeks and months if you don't make it priority #1. While you have unfilled positions, you are continuing to fail (at some level). Your team is continuing to feel pain. Distraction grows and grows. Before you know it, your project is failing.

Anyway, this way works for me. Your mileage may vary.

Now next week I can get back to job #2 of a Lean manager: empowering the team/sharing leadership, staying out of the way, & adding real value off the critical path.

19-APR 9:30 PT: Updated with links to Lean SW Dev.


Anonymous said...

I think it's different for contractors, but I doubt I'd ever take a job that gave me a homework assignment. It's busy-work that doesn't really tell you anything about how I'll do over the long-haul or as part of a team.

fuzzy said...

erm, I disagree. It isn't anything stupid, its just another form of interviewing. It gives people a chance to think. An interview is generally just a big spaz out for everybody anyway. A homework assignment let's the person actually think. You can't see how a person thinks anyway. IMHO, if you do not do this you will not know what you are hiring until the first task they complete. Your results may vary. Our assignments are totally legit. They aren't stupid programming puzzles or anything :)

Anonymous said...

I love you Fuzzy.

The Town of Russia, Ohio

steve said...

The technique I used to use when doing hiring was what I liked to call "sink or swim". It was easy enough to find people who had the "book learning" that we needed... but we found that it was much harder to find people who were fast enough learners and flexible-minded enough to get by in our absurdly chaotic and fast-paced work environment. So, whenever an interview seemed to be going pretty well, I'd take them back to my desk, describe what I'd been working on when I got up to go to their interview, and tell them to jump on in.

Obviously, nobody can just start hacking on a brand-new codebase without any context or background, and that's not what I expected to happen. The purpose of this was to see how they would react when put in a situation of extreme uncertainty and pressure. I found that there were two sorts of programmer. One sort- which, unfortunately, made up most of our candidates- froze up or got frustrated when presented with a completely unfamiliar codebase. This was a perfectly reasonable reaction, given the circumstances, but not what I was looking for. I call these guys "type one" programmers.

The other sort of programmer started exploring the code, asked me questions about our data model and our development process, asked to see the bug tracker, and generally displayed initiative and confidence. This let me see first-hand how they thought and worked. If we asked them to learn some completely new technology tomorrow, would they freak out? Or would they take the ball and run with it? Programmers that did well on this test were "type two" programmers, who not only can handle these sorts of situations, but thrive on them.

Forget contrived programming puzzles- those are fine for a first line of screening, but for people who I'll be working with on a small team for long periods of time, I need to know that they'll be able to pick up whatever random technology or domain knowledge becomes necessary. When I started in that job, I didn't know anything about audio codecs or telephony; then, one day, the bosses decided that we needed to extend our VOIP system's functionality. Guess what I got to spend the next week learning about?

At one point, while I was still developing this hiring philosophy, we hired two new programmers around the same time. One was a guy who didn't actually know much about some of the specific technologies that we were using, but had really strong programming chops in other unrelated areas and passed sink-or-swim with flying colors. The other guy had a seemingly-strong background in some of the specific stuff we were working with, but didn't do nearly as well when confronted with ambiguity. Guess who was productively fixing bugs within a matter of days vs. who still needed baby-sitting after a month?

MWesty said...

I agree on the homework. I wish I had done it more. You could argue that it is a more accurate depiction of their work output than answering interview questions.

I once had an all day interview with a consulting group. 7 interviews back to back. I did great in all of them. The one I bombed was a PhD in finance who was best buddies with 4 or 5 Nobel prize winners in Economics. Not the one bomb.

We both knew I bombed so I asked him if I could do some homework. He said yes, but he needed it by 3:00 PM the next day (Ouch!). I wrote a quick paper that better explained what I was trying to get across. He liked it and I was hired.

Somewhat hypocritically, I'm not sure I would give someone that completely blew an interview like I did a chance, but I would certainly give a homework assignment to someone who people in the group felt strongly about, but I did not, or vice versa.