There's no shortage of advice about the hiring process, both from the candidate's side and from the company's side: websites, books, seminars and more. One almost needs meta-advice about which advice to take!
Lately I've been concentrating on improving the interviewing phase of the hiring process. Bad interviewing is expensive: it wastes the company's time (time which is in short supply or else you wouldn't be trying to hire more time, i.e., more people); it wastes the candidate's time (and the best candidates will see that waste and downgrade their opinion of the company); and worst of all, it doesn't actually determine whether the candidate will be a good technical and cultural match for the organization: a good hire.
Here are three interview techniques I use "in real-life":
There are two things I want to know about an individual contributor: one, does she have the necessary technical chops? and two, will she fit in to the social culture of the team?
One common practice is to give the candidate hard toy problems and watch how she solves them. Unfortunately, this only proves that the candidate can solve toys/games but does nothing for whether the candidate can solve the real technical challenges facing the company. Additionally, having these interviews one on one will give the interviewer some clue about how the person handles one on one interaction, but nothing about the more important team/group interactions.
Thus, in addition to one-on-one interviews, I have been asking the candidate to do a code review of some of our existing code with a couple of the team members. We walk the candidate through some of the architecture and the code, then ask her for a review. What we're looking for here is:
Don't settle for an interview process that doesn't test for the right skills just because "that's the way we do it here" - if you do, you'll end up with the wrong kind of people ("be careful what kind of test you are acing"). Understand why a particular process is followed and then find ways to improve it. My suggestion (team code reviews) has proved to be an excellent test for the kind of people I like to have in my teams. Your mileage may differ.
When hiring for a management position, the skill you are looking for is how they deal with people - thus the interview should be focused on that.
My solution is to ask the candidate to tell me about the people around them in their current position. "Tell me about someone in your group" ... "Tell me about the best person" ... "Tell me about a problem person". And then I listen. Sometimes I need to direct the conversation, but often I just need to listen. And I'm listening for whether the person understands the people around him. What makes that person the best person? How does the candidate plan to mentor one of the not-the-best people in the group towards excellence? Has the candidate had honest conversations with his team about their skills and limitations?
In other words, I want to hear the candidate tell me about his people skills. If he can't, then he either can't communicate (a bad flaw in a manager) or he doesn't have people skills (a bad flaw in a manager).
The final piece of advice I have about interviewing is "don't stop at generalities". I always continue a line of questioning further and further into the details until either the candidate or I have reached the limits of our knowledge. "Do you know PHP?" is a first question, but if the answer is "yes", don't stop there - the next question might be "what is the most surprising thing you've found about PHP?". And then "explain how that surprising feature works". And then "where have you used/avoided that surprising feature?". And so on, in more and more detail, until I've found the limits of their knowledge. Then I go back up and start on another line of questioning.
The same technique applies for interviewing managers: "tell me about the last annual review you gave an employee" ... "and then what did you tell him?" ... "how did you follow up?" ... "how did you deal with that reaction?" ... etc. I just keep driving down to more and more detail until I have uncovered enough detail about previous situations that I believe understand how the candidate deals with people.
I approach hiring like any other engineering task: take it seriously, analyze it, and then improve it. I don't settle for "that's the way we do it here". My advice is not to waste your time or the candidate's time: make the best use of your hour to learn whether the candidate has the technical/people skills and the cultural fit for your organization.
| ||||
