I’ll quickly run you through a simple process I use with my teams to interview and select candidates for an open position.
The first step is looking through the stack of resumes to find candidates that look like they have the requisite skills and knowledge for the position. Once I’ve selected a handful of resumes, I go through a phone screen with the candidates to assess a few things:
- knowledge/experience, skill, & behavior in the core competency of a position
- technical knowledge
During the phone screen, I have a set of questions that I’ve pre-selected based on what the core competencies are of the position I’m hiring for. Usually they are in the areas such as planning, communication, prioritization, etc. for my Program Management candidates. For these questions, I ask them to provide specific examples in their previous work experiences (as past behavior is supposedly a good predictor of future behavior). If I find areas that I need to drill into (be it knowledge of a specific area, additional clarity, or anything else), I deviate from the script and ask probing questions into their responses.
For the technical knowledge type of questions, I typically ask general questions that the candidate should know or questions that give me a sense of the depth of their knowledge in a technical area (obviously my positions do not involve coding, but you can tailor these to the position you’re interviewing for). For example, I’ll ask a question about what a web service is or what a developer would use to find out the details of what methods a web service supports. Other simple questions we’ve asked in the past are simple CS questions on linked lists and things like that. It’s mostly for these questions where we’ll ask the candidate to go to the whiteboard (if this is part of the onsite interview).
After the phone screen, if I feel this person is a good candidate I’ll ask to schedule an onsite interview with the team. On occasion if there’s someone who’s on the fence, I’ll have others assess via another phone screen.
For the onsite interviews, we meet as a team beforehand (before any candidates come onsite, that is) to determine who’s going to be asking what questions (what core competency areas each will cover, what technical questions). For the interviewees outside the immediate Program Management team, I typically want to know from them if this person is someone they can work with from a knowledge, skill, and communication perspective. In the past, I’ve also included them in the determination of who’s going to ask what questions.
I typically look to have at least 3 – 5 onsite interviews and stack rank the candidates based on the scores that were given for each core competency and technical knowledge area (to be honest, this might be a little overkill as recently we’ve gone back to hire/no-hire). If it looks like the top one would be a good fit, we’ll go ahead and make an offer. We’ll move on to make an offer to the next candidate who would be a fit as appropriate. If there are no good fits, we’ll continue the process again.
There’s a good article about the interview process written by Joel Spolsky, which I really like. You can find the article here: The Guerilla Guide to Interviewing (version 3.0)