Don’t Ask The Wrong Questions At The End Of Your Tech Interview

Don’t Ask The Wrong Questions At The End Of Your Tech Interview

By Shawn Bullock | In-the-Trenches Software Architect, Entrepreneur, Mentor, Dev Career Coach. Problem Solver.

The Internet is full of coders seeking advice about what questions to ask at the end of an interview. Many responses link to resources containing various questions to ask. Those questions tend to be random and unfocused, and thus useless to the candidate.

Why? Because most candidates don’t have a purpose for asking those questions. Without a purpose, the answers will fail to gain insights and waste precious time. Asking the wrong questions is about as bad as not asking questions at all.

Do you want to have a more impactful Q&A at the end of your interviews? You need to ask the right questions. You ask them to gain clues about whether the company is a good fit. That is the purpose of asking them.

The right questions should help illuminate details about the culture and expectations. The best questions are the ones that help you figure out whether you want to work there (or not). Avoid asking questions that lead to answers you are not prepared to act upon.

It’s not always easy to figure out what questions are important and which aren’t. I form questions based on previous experiences then apply a rating system to them. Some of those experiences I don’t want to repeat and others I do. And that is my purpose for asking them.

We all have different purposes, or reasons, for asking questions. We may not want to work in a certain kind of environment? Or we do. We may want certain benefits, perks, or favorable conditions (such as commute, maternity, vacation, etc.). But we all have our reasons. But we need to prioritize our questions to address them.

Example Questions

Here’s the rating system I use:

  1. I am not prepared to accept or reject an offer over the answer
  2. I am prepared to accept or reject an offer over the answer
  3. The answer may be useful in context of other factors

So how do we identify good and bad questions? Here is a list of questions on GitHub. I’ll use some of them as examples.

A. Are your Git repos hosted in-house or by a 3rd party?

Will any answer to this question make you unhappy to work there? Are you prepared to reject an offer if their Git repos are hosted remotely or locally? I know I’m not.

B. Do you have established code style rules?

Will any answer to this question make you unhappy to work there? Perhaps you’re a brace on the same line person while they prefer the next line? Are you prepared to reject an offer over the answer? Consider other factors. Such as: how its enforced, or how communal the ownership of guidelines is.

C. Will I have to work over a VPN?

Will any answer to this question make you unhappy to work there? Are you prepared to reject an offer over the answer? This one is tricky. If you are on-call and have personal consequences for missing an SLA then you’ll want a VPN access. What if you frequent areas with unreliable internet access?

D. What are your expectations for how many productive hours a developer will have per day?

This is a poorly worded question because most places will have a mix of meetings, coding, interruptions. Here’s a better way to ask the question: “How do developers spend a typical day?”. Worded this way, the interviewer can tell a story rather than be in the spotlight. So, will any answer to this question make you unhappy to work there? Are you prepared to reject an offer over the answer?

E. What type of people are successful here? What type are not?

Will any answer to this question make you unhappy to work there? Are you prepared to reject an offer over the answer? This is the type of question whose answer can reveal much and help determine whether you could align there.

F. Does the company provide a mentor to other developers?

This is a weak question and can make yourself seem too insecure. Try rephrasing to: “What are your expectations of me the first few months? And what kind of support does the company provide new hires?” So, will any answer make you unhappy? Would you reject an offer over the answer?

G. How do you estimate work?

Will any answer make you unhappy? Prepared to reject? How the company estimates, or doesn’t, is unique to each company. Some practice Agile and others don’t. I’ve been places where nothing was practiced other than GTSD. Personally, I am not prepared to reject an offer over any answer.

H. Is this an open office, personal office, or cubicle place?

Will any answer make you too unhappy to work there? Prepared to reject?

I. How diverse is the company?

The company may not currently be diverse but at least if it wants to trend that way it could be worth working there. This is certainly a question that will strike everyone differently. So, potentially unhappy? Prepared to reject?

Closing Thoughts

In all cases, think about what kinds of answers might confirm why you’d accept or reject an offer, or is useless to ask. I do an exercise like this:

Question: Do you use GIT?

Importance: Not prepared to reject.

Why: GIT didn’t exist until a few years ago and every company has its unchangeable reasons for using whatever source control it does (or doesn’t).

Factors: Use any source control system, then fine. Doesn’t use any? Then follow up with “what authority and senior management support will I have?” (do other exercise for that question).

Doing so will help you identify the purpose of the question relative to your goals. Knowing what kinds of answers to expect could help steer the conversation in interesting ways. But the main purpose is to help determine whether to avoid asking the question in the first place.

Knowing who to ask the questions to is also key. Management and HR are more suitable for perks, stock, and benefits type questions. Immediate team or peers would be more suitable for technical questions, and anyone might be suitable for culture questions.

Comments are closed.