Adding to the team

We've all felt the pain of the interview process.

It sucks. And its not just the candidates out there. Its also the way we find them.

Typical Procedures:

1. Recruiter or ad
2. Phone interview
3. Written questions or code samples
4. In person interview
5. Meetings with other team members
6. References, background checks, drug tests, security clearance, street fighter challenge
   

There certainly is dysfunction here. Many interviews feel like a game and its not played well (or fair).

I think of finding a new team member as a process of filtering:

1. The process is a series of filters each more fine than its predecessor
2. A filter should have definite output
3. Good people are difficult to find. Too fine a filter early in the process is a risk
   
4. Most filters have manual steps. Filters that filter too little are a risk.
   
5. Finding the right person is personal to the team, so any filter that does not involve a team member is less accurate
6. A good fit is unique to a team, so rarely will the same sequence of filters fit multiple jobs.
7. Some criteria may give someone a pass around filters -- personal recommendations, proven methodology expertise and already working for company are a few examples

Before we can setup our filters, we need to know our goals for a candidate. This is a lot harder than it sounds. You may find you don't really know your "goals" beyond a "senior" developer who is a "team player" and "experienced" with our technology and methodologies.

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).

Example:

• 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

Clearly this is not a recommended starting point, unless you want to have a stranger on your team everyday poking around in some code in your project. Or maybe it would work if you have a lot of spikes?

Now what?

We can dig deeper into this goal:

1. What kind of traits make someone a good pair?
2. 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?
   
3. Can we use their past work experience to help?

If we find this goal is best saved for later in the process, we can move on to goals that are better found at coarser levels. Do we required a certain amount of experience or schooling? Do we want people from a similar background (domain, technology, methodologies)? Do we care if they change jobs a lot? Too little? Are they active in learning new technologies? Are they interested in our methodologies? Do they live nearby?

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.