3 Types of Questions You Should Never Ask During an Interview

So your boss came to you and told you to conduct an interview for a new hire. Or maybe you’re actually the hiring manager. Guess what? These suggestions apply to everyone! Based on my experiences with many technical interviews, avoiding these 3 types of questions applies to anyone wanting to steer clear of legal issues and attract the best candidates with the most accurate predictions of success.

I won’t make any claims about being able to predict applicant performance in specific scenarios. This is mainly because studies have shown such predictions to be difficult to obtain regardless of the type of measure utilized during the interview process. While interviews can be a good predictor of how an applicant will apply knowledge in a general and broad scope, it’s extremely difficult to judge whether or not said applicant will succeed with a specific technology for a specific project that your company has in mind. It’s even more difficult to predict when you’re using bogus, irrelevant, and nonsensical questions as a measure.

My advice is to stick to standardized, measurable, specific, and proven questions that are directly relevant to the job position and company as a whole.

1. Personal Questions

I’ve already discussed this one in an article about learning to conduct interviews, but I want to repeat it because it’s an important one. I’ve personally experienced and heard stories about some interviewers who feel that it’s appropriate to ask the applicant about their personal life including hobbies, what they do in their spare time, family life, age, birthdays, religion, and more. These topics just aren’t relevant to whether or not the applicant is fit for the position. In fact, asking about age and marriage can land you in legal hot water if an applicant decides to use that against you in a discrimination case.

Spare time and family life can be indicators of how available an applicant will be after hours. Someone who has a lot of hobbies and a few children probably isn’t willing to work tons of overtime. Without being able to ask about these, I can already hear the slave drivers screaming that they won’t be able to judge whether or not an applicant will be available 24/7 because they have a family to support. While that’s a topic for another day, rest assured that morale and overall productivity at a company with such policies is doomed to stay in the pits.

Making comments about age and asking about birthdays is just asking for trouble. It’s common for companies to look for the youngest possible applicants in the name of so-called “culture fit.” What they really want is someone who is still in “college mode” with no responsibilities beyond work and someone who is willing to take rock bottom pay out of either desperation or naivety. Silicon Valley and Wall Street will often call these people “passionate” to place a positive spin on the fact that they’re trading their free time for a slim chance at riches. Age related controversies around the interviewing process have happened as recently as last month. Do yourself a favor, avoid them like the plague.

2. Brainteasers

For many years, some of the top companies in the world drilled their applicants on questions about how calculating numbers of open doors, piano tuners in Chicago, trees in Washington State, ping-pong balls in an airplane, and other such nonsense. Fortunately, the big names have stopped doing that. Words like “complete waste of time” should be a pretty big clue that you should probably avoid these types of questions.

A couple of years ago, the New Yorker printed an article going much more in-depth on the topic of skipping the whole “brainteaser” thing. In it, the author describes that very little evidence actually exists to suggest the overall success of predicting specific outcomes from such questions. While these types of questions may seem like a good idea to judge an applicant’s ability to quickly form a concrete solution from an abstract and almost nonsensical question, they do little more than measure how well someone can perform such a task in an interview scenario. We all know that companies do not force their employees to solve such problems under such conditions.

In reality, science, technology, engineering, and math professions allow for employees to work under calm conditions in which references to coworkers, past materials, documentation, the Internet, and more are available. Instead of asking questions which measure how an applicant thinks quickly, you should instead focus on questions that emphasis thinking well. Ask experience and direct skill related questions with which you can measure command of actual domain specific knowledge.

3. Buzzwords and Acronyms

Software and process documentation exists for a reason. Different people will have varying success with remembering a ton of different buzzwords and acronyms. This is especially true when the technology industry loves making up new buzzwords and acronyms on a daily basis. A buzzword means something one day, and it’s flipped on its head the next. Expecting any applicant to rattle off various explanations of an innumerable number of buzzwords and acronyms is silly.

I’ve been on the receiving end of an interview that went roughly like this:

Him: Let’s start by playing something I call ‘Buzzword Bingo’.
Me: (Hesitantly) OK…
Him: What’s SOA stand for?
Me: Service oriented architecture?
Him: What’s TDD stand for?
Me: Test driven development?
Him: What’s Django?

Now, let’s be real. What exactly has the interviewer learned about me? Nothing much except that I have memorized some acronyms that I may or may not know anything about. In fact, my answers could be completely wrong! Acronyms have a nasty habit of meaning different things to different people. As for buzzwords, what’s the point? The applicant can easily look up the answers online during the interview or in their spare time after the fact.

A better alternative is to simply ask the applicant if they’re familiar with a certain piece of technology (unless stated on their resume in which it’s fair game) and drill in to some domain knowledge like so:

Example 1: I see that you used ASP.NET MVC in a project. Can you tell me about how that framework was useful for your ultimate implementation?

Example 2: Tell me about a time that you used JSON to transfer data between two services.

These questions give the applicant the opportunity to speak from real experience rather than offering a regurgitated Google search.