It sucks. And its not just the candidates out there. Its also the way we find them.
- Recruiter or ad
- Phone interview
- Written questions or code samples
- In person interview
- Meetings with other team members
- References, background checks, drug tests, security clearance, street fighter challenge
I think of finding a new team member as a process of filtering:
- The process is a series of filters each more fine than its predecessor
- A filter should have definite output
- Good people are difficult to find. Too fine a filter early in the process is a risk
- Most filters have manual steps. Filters that filter too little are a risk.
- Finding the right person is personal to the team, so any filter that does not involve a team member is less accurate
- A good fit is unique to a team, so rarely will the same sequence of filters fit multiple jobs.
- Some criteria may give someone a pass around filters -- personal recommendations, proven methodology expertise and already working for company are a few examples
Once we know what is important, we need to figure out how to filter this behavior. We must also look at a persons ability to grow into a goal and the team's desire to teach (which will be biased depending on the person).
- Goal: We want someone who is an enjoyable pair programmer
- Importance: We only pair so friction here is best avoided
- Ability to Learn: Developers, like all humans, are known to be stubborn in changing their personality. Though people can come around.
- Ideal Filter: Spend a day pairing with them, switching people so at least a few team members weigh in
We can dig deeper into this goal:
- What kind of traits make someone a good pair?
- Are there ways we can define questions that will clue us in on these traits? Do any of these questions have answers that we can entrust an outside party to interpret?
- Can we use their past work experience to help?
We may not care about individual answers to pass judgment, though a combination of answers is sure to give us something.
How we find people to review is also a filter. If we want someone who is involved in the community, we can use those channels to find people either passively (twitter we're looking, ads on blogs we like) or more actively (read blogs and tweets to find people, find people working on open source projects).
Remember, its not just what you want, its what they want. Make sure your job description includes things that will attract the good fits (or have some people running to the hills), like weekly book readings or Star Trek Fridays.
Finally, there are unique things at every environment. What attracted the team there? What are team member strengths and weaknesses and what is the state of the project -- how can a new team member help most? Do we need another good pair or is it more important we get someone who can help us fix our data layer and quick.
Finding a good fit is a lot of work. If we spend the time to figure out what we want, we can figure out better questions and ways to find them. I'd say its a good exercise, even if its not quite possible to create a systematic filtering process.
Off topic, I'm in favor of speed dating style of interviewing: open house at your company, each team member gets 7 min with each person who shows up. Anyone with all yays moves on to the real interviewing. It may waste a day of everyone's time, but I bet it would be fun and if it worked, it would save a lot of money on recruiters, ads, phone interviews, code reviews and spending time figuring out what "questions" will help us find the best fit.