December 18, 2011 3 Comments
“The biggest risk is hiring the wrong person.” That was my swift answer when asked to identify the most important risk facing hedge funds. In that case, I was talking about hiring the wrong Chief Risk Officer — the person who sets the risk policies and monitors and enforces the risk management practices of an asset manager. Little did I realize how applicable my advice was to my own firm. At 25 people, it’s safe to argue that my firm is at material risk of hiring ‘the wrong person’ every time we make an offer. It’s especially true for the person who is our equivalent of a ‘risk manager’ – the person who makes sure bugs don’t make it through the code and errors don’t end up in client’s reports: our head of Quality Assurance. I can now with personal experience enhance my previous answer: the biggest risk facing any business is hiring the wrong person.
Two weeks ago we suddenly found ourselves needing to hire a new Head of Quality Assurance and my highest priority became writing a new job description.
Since then, we’ve gotten a lot of really good resumes to fill the position. The first one of these came the very next day, and boy did it look good. Only issue: the candidate had a job offer in hand and had only a few days to reply. Not a problem for a nimble firm like ours. We quickly mobilized, scheduling morning interviews in our lower Manhattan office and afternoon interviews in our New Jersey office. One of our people wasn’t able to meet him that Friday but she did make time on her Sunday to meet him for coffee. It feels good when you can move important things as fast as we did. First thing Monday morning we all met to discuss. While some of us were impressed, others had serious reservations. Back and forth, debate, debate, debate. Not the clear cut decision I was hoping for. We realized that we just didn’t have enough information to make a decision. So we decided to invite him back in later that afternoon to address some of these concerns. Three people in one room going over the candidate’s responses from the previous interview. “Let’s go over some of your previous answers, shall we?” His explanations weren’t exactly impressive. Within a few minutes the answer was pretty clear: he wasn’t the guy. How could we have come so close to hiring someone who, on re-examination, was so clearly wrong for the job? We decided it was because we didn’t have a systematic and structured way of looking for what we wanted.
“Put the candidate in the job before you make the offer.” This is what I learned at a recent seminar on hiring practices. Having the candidate “role play” as if he/she were in the job as part of the interview allows the interviewer to answer the important question: ‘will this person deliver what I need?’ The closer you can get to having the person draw up potential solutions to real problems the better: it gives you a much more realistic assessment of how the candidate will perform if given the job. So this is exactly what we decided to do. We wrote a one page description of the current QA situation within our firm – the amount of code ‘awaiting testing’, the state of code documentation, the number, size and scope of ongoing projects, deadlines, etc. etc. We allow the candidate to ask any questions during or after the interviews about the set-up and we give them a few days to put together their “QA Strategy.”
This approach seems to be working quite well. We’ve applied it to a few candidates who have gotten far into the process and it reveals a lot about how the candidates think. It has helped weed out the candidates we’re not thrilled about and has made us more certain of the candidates we’re still interviewing. It certainly takes longer than the traditional “30 to 60 minute interview” but it also gives a lot more information. “Hire slowly and fire quickly” may be the age-old wisdom, but I don’t have the luxury of hiring slowing. I need to hire quickly and I need to make sure I make the offer to the right person. Our new process of “putting the candidate in the job” seems to be a reasonable risk management technique. So far, it’s eliminated a few candidates who might have taken several months on the job to demonstrate that they aren’t the right fit. So by having the candidate actually perform some of the most important aspects of the job during the interview process, we can make a better assessment of who is most likely to succeed.
Another test we’ve decided to apply to candidates is to have them interview one of our programmers about a particular piece of code as if they were designing how to test that code. This interview technique is much more tactical than the one I described above. Does the candidate ask the right questions about the code? Does the candidate demonstrate – in real time – adaptability and learning from new information? Does the candidate ask questions that make sense? Is the candidate chasing the right details? Is the candidate looking for causal relationships between the disparate pieces of information he/she has gotten? Are the candidates’ questions incorporating recently gained information? etc. This reverse-interview format is really quite illuminating – it gives us a flavor into how the candidate thinks.
We have a couple of rather promising people approaching the ‘offer/no-offer’ decision point. With these new interviewing processes, I think we’ve minimized the risk of us hiring the wrong person. Now, it’s time for our job to turn to the other side of the coin: actually hiring the right person.