Thursday, July 30, 2009

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.

5 comments:

Greg said...

This is good advice for the first round.


For later rounds I have often spoken with companies about "contracting for a day" some of the finalists (at a decent rate) to see how they really work out with the team.

Nothing says how a person will do on the team like seeing their first day.

Mark Freedman said...

Finding the right fit is incredibly difficult and painful. It often feels like we waste so much time, but if we find the perfect candidate, it's usually worth it. But if we pick the wrong one, we could be picking up the pieces for years.

Several years ago, my former company tried an "open house" style interview day, which was recommended by the E-Myth Academy, who we were working with at the time. It was pretty fascinating, and we met a lot of people fairly quickly. We didn't make such a great choice, and regretted letting someone pass due to salary restrictions (would have saved us a lot in the long run, but that's another story). But I'd recommend trying it at least once.

By the way, I'm not sure how legal it is asking how close someone lives. Maybe finding that out in a roundabout way is ok, but HR would smack us for that.

I wrote a somewhat related article a while ago, from another point of view. Please excuse the negativity ;) Was a bit frustrated when I wrote it.

Lisa said...

I like the speed dating idea. I've read research that said you form your opinion of the candidate in like 30 seconds.

When hiring testers, we get the candidate in a room with the whole team and project one of our UI screens, and as the candidate to start doing exploratory testing on it, telling us what she is doing as she goes. This has told us a lot about the person's thought process and ability to communicate.

wunda said...

@Greg, I love the idea of consulting for a day -- if you can get the funds :) I'm sure it does save money and headaches.

@Mark, thats a great post! I remember when you wrote it. Bummer when salaries get in the way. All the questions I wrote were pretty random (if such a thing exists), though paying for moving expenses or allowing remote work are other things to consider :)

@Lisa I bet watching them explore the app works well and is kinda fun (unless the person is a total dullard, which I'm sure you've run across :P)

Chris Holmes said...

The worst thing about trying to add a new team member is that the talent pool gets a LOT smaller when you're not in a metropolis...