Friday, September 18, 2009

Test Driven Recruiting (TDR) v0.1

Would love your thoughts on how to improve and refine this idea. Please send feedback here.

Test Driven Recruiting (TDR) is THE wave of the future in hiring, starting right now (I jut made it up). I got this idea from the idea of Test Driven Development, which has really helped me in learning to write software. This idea is going to need some work, but here's what it means...

  • To kick start the hiring process, define the problem you're trying to solve. Don't worry about being arbitrary. Create the most ridiculous wish list imaginable.

    "I need to hire software engineer with 15 years of Ruby on Rails experience. This person must have a PhD in Computer Science from MIT, work for equity only, and also run errands such as dropping off my dry cleaning and washing my car."

  • Next, you must TEST your hiring requirements to see if they are based in reality. In order to pass the test, you must get three people you'd love to hire to answer one question: "Does this person exist?" If those three people all say "yes", your job description is valid. If you get even one no, your job description needs to be refactored.

    You might come up with something like this as a realistic job description...

    "I need to hire a extremely bright software engineer. The person must have a working knowledge of Ruby on Rails, an excellent track record of learning new programming languages, and I'd strongly prefer to see a college degree in computer science or similar field."

  • The next step is to develop a test for how you can identify a candidate who can do the job. First, don't forget that you always need to hire someone you can get along with. Don't get caught up in buzzwords on a resume while forgetting to decide if you like the person. You'll have to put some thought into what is actually a valid test, but here's a basic example...

    This past July I helped a client hire an extremely bright JavaScript programmer, a hot skill to have here in San Francisco. The client and I developed a reasonable job description, they wrote a simple but effective test to demonstrate JavaScript proficiency, and we gave that test to all reasonably qualified applicants before even a phone interview.

    At first the client and I thought testing so early would be a little impersonal, but the vast majority of applicants embraced the chance to prove themselves. The applicants who were not committed to the test didn't complete it, the applicants who didn't pass invested less time than an in person interview would have taken, and those who passed were interviewed. The person who got the job would not have been our first choice on paper, but turned out to be an excellent programmer.

Would love your thoughts on how to improve and refine this idea. Please send feedback here.

No comments:

Post a Comment