Breidenbach - Getting to a Hire Level, Part Deux

By Kevin E. Breidenbach 29 April 2009

So, having read the first part of this series, you’ve looked over your organization and found that you have a good Agile process in place, quality people working for you, and a good base of subject matter experts. It turns out that the 80 hour weeks your team has been working are caused by the runaway success of your business and your team’s enthusiasm for accepting more and more stories and pushing new functionality out the door. Yes, I know, very Obamistic, but it could happen!

So what do the rest of us do?

Creating a Hiring Process

You could just throw together a job specification and rely on search firms or job boards. You could also ask the neighbor kid to prepare and file your tax return for you. Search firms do find good people, but you can’t outsource your responsibility: at the end of the day it’s your responsibility to find the right person or people.

Marketing the Position

The first thing most job candidates see is a published job description and position requirements. This is an extremely important artifact: not only does it describe what you are looking for, but it also advertises the job role. If you want the best people you need to entice them into entering your recruitment process, and what you advertise is an important part of achieving that.

If you know that a developer will have the opportunity to do greenfield development, put it in the description. If they are going to get the chance to work with some of the best minds in the business, tell them. Starting to see where this is going? This is Marketing 101.

The job requirements should be specific, but not give away too much information. For instance, suppose we know that we definitely want someone with experience of working in an Agile development team. So say just that, but don’t get into specifics such as: “must use test driven development” or “has pair programmed with Ward Cunningham”. The candidate (and sometimes the search firm) will add whatever you have specified to the resume. This is why you have to thoughtfully drill down into their experience during the interview: if they’ve never really worked in an Agile team, you'll know about it soon enough.

Improve Your Interview Success Batting Average

Every person that you bring in for an interview costs both money and time. It reduces productivity during the time they are visiting, and is an overhead cost to your business. This is true of both face-to-face and phone interviews. To make best use of increasingly scarce time, you need to make sure you are bringing in the right people in the first place.

Test, Test, Test

While you could rely on a search firm or recruiter to only supply you with resumes of people that fit your job description, we all know that rarely happens. Excuses like “JMX and JMS are the same, right?” just don’t cut it, and in the past I’ve been known to stop dealing with search firms who do things like that. But there is an easier way to know you're investing time in the right candidates: testing!

No matter what your HR department tells you, there is nothing wrong with testing candidates. Providing it is done fairly and each person applying for a particular role is given the same tests with the same constraints, you’re good to go.

My favorite test is to send a programming exercise to candidates before they are brought in for an interview. Give them a set number of days to complete it, and eagerly await the results. This will instantly give you an idea of who to bring in: if they send you one file of code, but no build script or unit tests, the resume goes in the bin. If they do send in what you consider to be a complete response, you’ve now got some very specific talking points for the interview. Quiz them on their design decisions, the patterns they used, and so forth. You’ll soon know if they actually produced the code they submitted, or had somebody write it for them.

The Day of the Interviews

So you’ve perused the resume, checked out the programming exercise and you’ve decided to bring the candidate in for an interview. Tell the candidate that they should expect to be at your location from between 1 and n hours, where n depends on how many face to face interviews you have planned.

...And more tests

Still, you still don't want to invest your staff's time interviewing a candidate if he or she is not going to be up to the task. So, once a candidate is on-site, the first thing I do is give each candidate a couple of written tests.

I have some terrible code that compiles and works, but is inefficient and poorly written. One test I ask them to do is to make the code more efficient. A second test is a basic design quiz that asks how a developer could refactor code to make it easier to unit test. Each test should take 10 minutes, but I give them 20 minutes total and let them decide how to spend the time. It doesn't take long to review the results. If a candidate fails to perform in this exercise, I won’t waste time with an interview.

The next phase is a quick pair programming exercise. First, let the candidate take to the keyboard for a while, and then sit back and be in the partner’s chair. This will give you some idea at how well he communicates, his ease at pairing and how he performs under pressure. Again, if he’s not a good fit, thank him for taking his time and send him on his way. Your interviewers can get on with their work, and they’ve not been disrupted by a poor candidate.

Face to Face Interviews

At this point, you're ready to interview. Send in your “A’s” to make sure you’re only hiring “A’s”. They should stick to questions in their area of expertise: business people shouldn’t ask technical questions as they will look unprofessional and may dissuade a good candidate from joining. However, the technical people should concentrate on technology applicable to the domain they are working in: it may be wonderful that somebody can design an elevator control system, but it's of theoretical value only if you’re building trading platforms.

Discuss the Candidate

Get everyone together to discuss the candidates who make it through the face-to-face round. The decision must not be about egos, but facts: one person who takes a dislike to a candidate shouldn’t have the decision making ability to throw him out. Also, the hiring manager shouldn’t be able to over-ride the team decision. There can be a lot of nefarious motivations in hiring decisions. I’ve seen people hired solely because they were friends with the hiring manager, and it always ends in tears.

The Golden Rule of Hiring

Hiring is not an easy task and it shouldn’t be taken lightly. As much as you need a development process in place, you must first have a formal hiring process in place. Remember also that in advertising for new hires, you are advertising your company as well. Being unprofessional through the hiring process will turn away top candidates, even in the current economic climate. Above all else, remember the golden rule: treat the process and the candidate as you would like to be treated. One way or another, all the tests, interviews and advertising - all the activities you perform in the hiring process - communicate how much respect is valued in your organization. Your next hire will respond to that most of all.

---

About Kevin Breidenbach: Kevin has a BSc in computer science and over 15 years of development experience. He has worked primarily in finance but has taken a few brief expeditions into .com and product development. Having professionally worked with assembly languages, C++, Java and .Net he's now concentrating on dynamic languages such as Ruby and functional languages like Erlang and F#. His agile experience began about 4 years ago. Since that time, he has a serious allergic reaction to waterfall and CMM.