Job interviewing is one of the most important parts a manager’s or team lead’s job, but too often managers go into the process without a clear vision of what they’re looking for, and therefore they don’t know what to ask about.
Even worse is getting some cool-sounding questions from a blog article that don’t tell a manager what she needs to know. Some of these “clever” questions can insult the job applicants whom you most want to attract. At a minimum, they waste precious time for both you and the interviewee.
It’s essential to plan your questions well before the interview. Here’s some advice that may help you do so.
Begin with the end in mind
Before you consider the questions to ask, you have to know what you’re looking for. Going into the interview without knowing what you want is like starting a programming project without software requirements or user stories.
Start by looking at the ad you wrote for the job. You spelled out the key areas of knowledge you’re seeking, so start there for your checklist, at least for the hard technical skills.
Then consider the day-to-day life in your team. Do you do many small projects? A few large ones? Do people work together on teams most of the time, or on solo work? Is there much interaction with other areas of the company, or is everything funneled through intermediaries?
As you build your list of questions to ask, consider the importance of each area. You might even organize your list of questions into categories, sorted by importance within those categories. That way, you can address the most important issues, and ask follow-up questions later in the interview if appropriate and if there’s enough time.
No question you ask should be make-or-break. No single answer should be the deciding factor for a candidate. I once saw a posting from a manager who said, “I ask what the candidate’s favorite browser is. If he says Internet Explorer, then I know I can’t hire him.” That attitude is counterproductive and can lose you otherwise qualified candidates.
The goal of the interview is to get a picture of the candidate through conversation. If there truly are absolute technical or business requirements for the position (such as a Secret clearance or extensive experience with Linux servers), those should be screened out well before the interview.
Print the list of questions you want to ask. When it’s time for the interview, don’t rely on your memory or on brief notes. Create a printed document with headings for each topic and bulleted questions, allowing plenty of whitespace for you to make notes. Don’t read questions off a screen, and don’t take notes on a computer while the candidate talks. These can make the candidate feel ignored, as if the computer is more important than your conversation.
Start with basic factual recaps
For tech skills, start with basic fact-finding questions. “How long have you been using Ruby? At which companies have you used Ruby? Tell me about some of the projects you worked on with Ruby.” These questions may be asking about facts that could be extracted from the resume, but that’s OK. The candidate isn’t going to say “RTFM, dude. It’s on the resume!” (and if he does, then end the interview right there).
Asking for factual recaps on the resume serves two purposes. First, it lets you verify the claims made on paper. Maybe his resume implies he’s had five years of Ruby experience, but upon asking for details, it turns out he took a Ruby class five years ago, but did nothing with it until last year.
More importantly, the recap questions ease you into asking more detailed and open-ended questions about the technical topic. Don’t just ask, “Have you used PostgreSQL?” Leave it open by asking, “Tell me about some of the times you’ve used PostgreSQL.”
A big part of asking open-ended questions is uncovering any B.S.ing that the candidate might be doing. Anyone who’s read product documentation can talk a good game (especially if you’re hiring someone for the expertise you lack in-house), but under the sunlight of probing questions, the truth comes out. These questions can just be conversational tech discussions:
- It says here you set up a PostgreSQL database at your last job. How big was it? What strategy did you use for sizing the WAL log?
- Which of the many modules available do you use for finding files with Perl?
- What challenges did you have when you first started writing PHP?
Make sure your tech knowledge questions matter
The technical knowledge that you expect from the candidate vary depending on what sort of position you’re hiring for. It makes sense for a network administrator to rattle off the seven layers of the OSI network model, and I’d be wary of a candidate that couldn’t.
Does that make sense for a DBA? A graphic designer? If you don’t actually care if your DBA knows that answer, then don’t ask the question. Don’t ask questions “just to see what they know.”
On the other hand, there’s nothing wrong with asking about knowledge that isn’t directly related to the job but might be good to know anyway. If, for example, you’re considering moving from Rails to another framework, go ahead and ask about the candidate’s experience with other non-Rails frameworks, even though it’s not a job requirement and wasn’t in the job ad. If the candidate has experience that makes her more useful to your company, that adds to her value and helps you make a better hiring decision.
Ask open-ended questions that encourage story-telling
Unless you’re hiring someone who will never interact with other humans in any way, ability to work well with others is at least as important as technical know-how.
Don’t ask “Do you handle stress well?” because that’s a yes/no question. Don’t ask, “How do you deal with stress?” because that just lets the candidate rattle off a prepared answer that sounds good but may not be true.
Instead, ask, “Tell me about a time that you had a lot of stress at work and how you handled it.” Telling stories is illuminating and is less likely to let the candidate hide behind stock answers he thinks you want to hear.
This approach is called “behavioral interviewing,” but I prefer to think of it as just having a conversation about work life.
Ask questions about the candidate’s past. Explicitly ask for stories. “Tell me about a project that didn’t go well,” or “…a project you’re very proud of” or “…teams you’ve worked on that worked very well together.” War stories from the past tell a lot about how the candidate solves problems far better than silly problem-solving answers about moving Mount Fuji, and they also give insight to how she handles adversity. “What’s the worst bug you ever wrote?” “Tell me about a time you lost a lot of code or data, and what you had to do to get past it.” “Tell me about a project where things just seemed to go wrong.” Anyone who’s been in the business for any amount of time has stories like this. And probably enjoys talking about them.
After a question like this, a good interviewer follows up with, “What did you learn from that experience?” A good candidate answers it without being asked. “So, after the show, our team looked back at what we could have done to prevent that situation in the first place. We decided that showing Marketing our progress more often, throughout the entire project, would probably have raised the problem earlier in the process. Now, we do demos of project progress every two weeks to confirm that we’re heading in the right direction, and Marketing likes feeling more in control.”
Ask about your business problems
The best questions are those that show both that (or if) the candidate can recall knowledge and that he can use that knowledge to solve problems.
Provide an example of a recent problem your group had, and ask how the candidate might approach it. “We’ve been having some slow queries against our PostgreSQL database. How would you diagnose them?” You can give specifics: “This query I’ve printed was giving us trouble, sometimes taking over 1500ms to run. What would you look at to try to speed it up?”
Then, when she’s given you her answer, ask for another. Maybe she suggests partitioning the index, and maybe that’s even the “right” answer in your mind, but ask for another possibility. Questions like this don’t have one right answer in the real world, and there shouldn’t be one right answer at the interview desk, either. But the answers should give you a sense of how the job candidate approaches problem solving, and your kinds of problems in particular.
Ask questions about playing well with others, not just technical work
You can train someone in Oracle PL/SQL or threading in Python, but you can’t train the ability to get along with others on your team. Any candidate with great technical chops will come down and hit the ground running, but if he disrupts the team then he’s a net negative in the long term.
Ask about adversity and hardship. Every job has problems that come up, deadlines that are missed, code with bugs, and conflicts between team members. Any IT worker who’s had a job has had to deal with these things, so ask the person you’re interviewing about them.
- “Tell me about a project that didn’t go well.” Think about if this person is someone you want on your team when things go poorly.
- “Tell me about a personal conflict you had with a co-worker.” Nobody likes everybody, and that’s OK. How does the candidate handle the person he doesn’t like so much? How does he handle conflicts with others? What annoys him?
- “What’s the worst bug you ever wrote?” “Tell me about a time you caused a disruption of service.” Follow this up with, “What did you learn from this? What changes did you make as a result?”
Avoid questions that can lead to irrelevant bias
When you look over your list of questions, examine them for built-in assumptions. It’s fine to ask, “Which open source license do you prefer: GPL, MIT, or Apache, and why?” if your company works in open source, releases open source, and is an active part of the open source community. If not, it’s just philosophical navel-gazing that can lead you down the road of personal bias.
I’m fond of asking, “vi or emacs, and why?” I don’t care which one the candidate chooses, but I do want to know what went into the choice. In a disappointing number of cases, the developer did not even make a choice between the two editors so much as just never taking the time to think of learning a tool other than the one he started with.
Don’t ask “Google” questions
The worst questions to ask are the ones famous for being asked at Google and Microsoft. The questions aren’t bad, but the motivation is. Don’t ask questions just because a big company like Google does.
Unless you’re Google, or your company transports golf balls by air, questions like, “How many golf balls can fit inside a 747?” are not helpful. These questions are often justified as “a good way to get to see how people solve problems,” but I think that’s hiring managers deluding themselves. Why do you care about how the candidate will solve a problem that she will never have?
These estimation questions make sense for Google because one of Google’s core competencies is scaling and estimation for huge projects with huge numbers of users. For Google, estimation is a crucial skill. For the rest of us, a much better question to ask might be, “Let’s say: We’re going to create a website that will handle 10,000 visitors a day: How much bandwidth will we use? How would you go about determining the answer to that?” Even better, ask about the Achilles heel of many programmers: “How are you at project time estimation?”
Don’t ask trick questions
Even worse than asking irrelevant technical questions is asking trick questions “to see how the candidate thinks.” Now is not the time to play amateur occupational psychologist. Questions like “How would you move Mt. Fuji 100 feet to the west?” are the equivalent of “Jump through this hoop for my amusement.” It’s disrespectful to the candidate and it wastes your time.
If you want to see how the candidate thinks, test her on something that is actually useful. For example, “The VP of sales calls from the field, yelling, “Nobody can get on the website!’ What steps do you take?”
The answers can be very enlightening. Here are possible answers, each of which point to a different way of thinking:
- “I ask him what exactly ‘nobody’ means.”
- “I call technical support to see if there have been other problems reported.”
- “I try to load the website myself.”
- “I try to load the website myself from an outside IP address.”
- “I check the Apache web logs.”
- “I check the Nagios server monitoring page.”
- “I ping the web server’s IP address.”
- “I ask him to ping the web server’s IP address.”
You aren’t in the mountain-moving business, so don’t ask. Ask about your business.
Do not ask fanciful philosophical questions
Fanciful questions are a waste of time and are insulting to the candidate. “If you could be an animal, what would it be?” is a question no sensible hiring manager would ask, other than thinking “Ooh, that sounds interesting.” Interesting, however, doesn’t mean useful. What sort of answer are you looking for? What do you think you can tell about someone if they answer a lion instead of a badger?
If you think these are interesting discussions, save these questions for sitting around the lunch table after you hire the candidate.
Remember to make the interview a business meeting between you and the candidate, not an interrogation. You both have a common goal, which is to determine if the candidate and the company are a good fit. A good interview is a conversation between colleagues to discuss the business’s problems and how you both can work together to solve them.
Finally, learn from each interview. Go back over your questions and examine which ones were illuminating and which ones weren’t. If a question doesn’t work well in the interview, modify it or throw it out. Add new ones to your list as well. Print your list of questions fresh for every interview.
If you’re on the interviewee-side of the desk, perhaps you’re more interested in how to respond to the tech questions the interviewer poses to you. In that case, you might also want to read Bad Tech Job Interview Questions (and How To Answer Them).