We're currently in the process of hiring a web developer as well as a project manager. This isn't exactly unusual (we've been hiring at a steady pace for a number of months now) but a remark from our new VP Marketing (
@ggueneau) made me want to
write a few words about the hiring process here at XWiki.I was telling him that the PM candidate would have to go through 3 interviews with members of our client development team (after having met or talked with 3 people already) and his reaction was along the lines of: "C'mon, 6 to 7 interviews, nobody does this but for executive positions! We're going to scare the guy away and lose our people's time!". I didn't really agree with him and I thought I'd explain why here. This will probably not match
Joel's reference article on the subject but it can prove interesting nonetheless.
First, some background: the hiring process at XWiki wasn't exactly our biggest strength in the company's early years. We went through a couple unsuccessful hiring experiences and had to let some people go. Thus when we had to start hiring more intensively towards then end of 2009 I somehow ended up writing our first official hiring procedure. Its aim was to achieve the following objectives when bringing new people onboard:
- We want someone who's interested in the company, what we do and our philosophy
- We want someone who has the technical skills required for the job
- We want someone who will be a good fit with the current team, especially the people she will be working with on a daily basis
Sounds pretty obvious, doesn't it? Our process was designed quite to achieve this in a pretty straightforward way:
- The first interview is usually conducted through Skype. It's meant to describe the job in more detail, get basic feedback about the candidate and make sure she understands what XWiki is all about
- If we feel like the candidate could be a good fit, she's invited for an on-site interview with our HR person to gather initial in-person feedback
- Then we have an in-depth technical assessment, either writing code (for developers), writing some documentation and bug reports (for QA) or writing a short specification (for PMs) to assess the candidate's skills with regard to her intended position
- Assuming the technical test is a success, the candidate then gets to talk with 1 or 2 persons she'd be working with. She also talks with someone who holds a similar position within the company
After every single interview, a transcript of the interview (if available) as well as the interviewer's feedback is logged on our intranet. Each interviewer gets to give a "YES" or "NO" opinion about hiring the candidate, give her a mark out of 10 and write some feedback. Marks and YES/NO opinions are expected to be motivated and can be the topic of further discussion through comments when needed. Once all the feedback has been gathered, management comes to a decision about the candidate. All bases covered.
Although it might seem a bit time-intensive, our process makes sure that every stakeholder can have her voice heard and that obvious mismatches can be rooted out earlier rather than sooner. Given the long-term cost of bad hiring decisions, I think this is ultimately a huge win. An additional benefit is that it makes existing employees feel involved and trusted by management. For instance, I remember some PM candidates that I thought were very interesting (groked the business, expressed themselves well) but got dismissed by our developers for their insufficient technical understanding or poor organizational skills. To me, each of those occurrences proves the value of our process. Even though from the outside it might look like we're trying to own up to bigger companies with a longish hiring phase, it's definitely not a random or haphazard thing.
If I have one last piece of advice to give based on my (very limited) hiring experience, it's that you should be very deliberate in defining and executing your hiring process. Never hire someone unless you've done your homework first. Unless you get lucky, you're likely to regret it later on.
