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. I