The Goal of An Interview Question

Especially in engineering, when we're searching for jobs we tend to look for high minded matches in terms of philosophy, attitude, and perspective on the world. I think these tend to be interviewing mistakes because the things that make us happy are simpler things like "are we shipping code all the time", "do we have customers who use our software?", "are we able to get positive feedback from those customers", "is there a rock competition that a random engineering manager runs at standup". These things have a much bigger impact on our day to day lives than things like "making a dent in the universe" or "are there interesting problems to solve". I'm not saying these aren't important, but... by the time I get to the interview stage of the process, I should have a pretty clear idea if my work will have a huge impact and whether or not it's an interesting problem to solve. It's either a a high leverage position (high rank or small team), and by the time I'm talking to someone who's not a recruiter I should have a pretty clear idea of the product or tool I'm going to be a part of building.

The goal of each stage of the interview is to determine if those ideals that I think I match on actually line up in practice.

How to Structure a Good Question

I have a few goals when it comes to asking good interview questions (as the interviewee). I don't always get this right and often I'll default back to the easy stuff, but at a high level I try to hit these marks:

1. Specific Examples: I want to allow the company to give explicit answers to the questions with examples that I can actually determine if they're true or false.

   • Asking something like "How do you feel about work life balance" is unhelpful here because it makes it hard to determine whether or not they're telling the truth. "We value it" might be a true sentiment, but it doesn't give any context on what work life balance means to them or get at the things I might care most about.

2. Not Too Specific: I want the question to orthogonally get at other deeper truths without being explicit about the ask.

   • Going back to the previous situation about work life balance, asking them point blank, "do you value work life balance?" or "do people work nights and weekends?" is also unhelpful because there's a clear right answer. Also getting too specific can be a problem "Tell me about a time you had to work more than 40 hours a week." might leave the interviewer without a solid answer (they're probably not tracking their time), which will likely result in the same initial vagueness I was trying to avoid.

3. Getting Off Script: I want to get a perspective on the company, but not from the default answers they always give, but closer to an honest interpretation of how they feel about the company.

   • The idea here isn't that I'm going to trick them into saying something bad, it's that often people default to the normal good stuff that is pretty common at every company. Asking a question that they haven't heard gets them to pause and recalibrate answers in a way that's productive for me.

4. Opportunities for Follow-up: The other goal is to ask questions that let me ask a follow up if necessary. It's not always (and given the limited amount of time, often isn't), but I want to set myself up for the possibility.

A Potential Example

If we use "Work-Life Balance" as the theme, I might ask a question like: "Tell me about a time you had to work hard in order to hit a commitment. How did you coordinate with the team and what did you learn from the process?" I like this type of question because it's open to the idea that sometimes teams will have to stretch to do things, but also asks them to articulate what they did in that situation, but without asking them if they'll give me the day off when I work an 80 hour week. I'm not boxing them into a corner with the question, but can hopefully get a good sense of how open they're being.

The Caveat

It's important to note that a lot of these might get more or less specific depending on the person, their tenure, and the role at the company. Each of these is a starting off point, but the goal here is to create a set of questions that connect the high level to the daily habits I'll act on.

The Questions

Culture and Mentorship

The goal with these questions are to get a sense of how they think about communication and team building to build strong teams that are fun to be a part of.

1. How do you think about hiring junior engineers?

• This is an important one to me because it signals a lot about how they view growth and professional development. One of my earliest bosses as an engineer made the point that teams with too many seniors tend to perform poorly because there isn't enough of a learning as an organization. A willingness to hire junior engineers also points to a solid nod to diversity at the company as it creates more pathways for people who don't fit a traditional engineer mold to join the organization. It also says something if they only hire juniors, because it might mean they look at engineering as a cheap resource.

2. What steps have you taken to improve diversity and inclusion?

• I want to hear about tangible things they've done to improve diversity and inclusion, especially how they measure it. I don't like asking "how do you measure" because it instrumentalizes the question and puts leaders on the defensive. That said, there are definitely good answers I'm looking for here: actions, partnerships, and metrics they're using to understand success. Bad answers tend to look more like admitting that they have a problem, or expressing a desire for "viewpoint diversity". (It's not to say that viewpoint diversity is bad, but that it's a completely different topic of conversation)

3. What differentiates a good engineer from a great one?

• This one I got from a close friend (who's written for this website). On its surface this is a question about skill and technique, but the deeper question is basically "what do you value in the people you look up to". It gets at asking questions about values and aspirations.

Product

As an engineer I'll be working with product managers and other stakeholders to ship code. Often companies will prioritize engineering happiness because of our expense and our relative value in the industry. Product often sits on the other end of the spectrum, answering directly to stakeholders unless there's a champion on the executive team who believes in independent and autonomous product teams.

1. How do product and stakeholders work together to set priorities?

• The issue here (that I've seen in my career) is that if product doesn't have autonomy to be effective at their jobs, it often also limits what engineers can do, because they're partnering people without the authority to make decisions. I want to get a sense of how they talk about product work (in terms of features or problems) and who has the rights to prioritize them.

2. How many production bugs do you have and how do you manage them?

• I started asking this one recently, and the responses have been really interesting. In general it depends on the size of the organization in addition to their practices. It also gets at how open they are about discuss production issues and who is responsible for fixing them. The challenge here is that sometimes this gets interpreted as "Are you going to throw me into a stressful on-call cycle". I'm still working on how to frame this more effectively.

3. What type of work cycles do you work in?

• How often work gets pulled in and shipped shapes a lot of how projects get scoped and developed. I like to get a sense of the cadence that they work in and how often they're learning. A good follow up question here might be: "Tell me about a really good retro and what you took away from it" to dig into how they're reflecting and improving their process.

Dealing with Issues and Specifics

1. What gives you the most angst in your day to day on the job?

• This is one that will let them flinch a bit and answer in a way that's probably fairly personal rather than "there's this crappy process we keep using", but the way they flinch should be informative to what they're aiming for. One interviewer responded with "I worry about making the right decision/technical design." This is informative because it seems like there's probably a high standard for work at the organization.

2. How do you give feedback to one another?

• I know earlier I said not to be blunt, but I think this one is good to be up front about. It's important to know whether or not constant feedback is the name of the game, or if you should wait for your yearly/quarterly review to get information about your performance.

3. I would like to grow to title [insert title here] how would I do that?

• This one really depends on the size of the company and your personal goals. If you're not looking for a specific career growth, there's no need to ask, but if you are, it's worth understanding what time scale they might offer that to you.

4. What types of metrics do executives share with the company?

• I'd be up front about this one. At most of the companies I've worked at, they've been very transparent with specific data about the targets we're aiming for, where we're at and how we intend to get there. If a company isn't doing that for you (especially as a software engineer), it's probably worth thinking about how set up for success you're going to be.

5. Talk to me about a mistake you made recently

• This one is blunt on purpose. It's similar to the production bugs in the sense of it's kind of a "show me your warts" question, but it's also trying to get them to be vulnerable about how they frame personal success and failure. Do they admit any fault? Do they admit to an inefficiency that's not really a mistake but a matter of happenstance? It's not necessarily bad if they do one or the other, but it's an extra data point in how they think about the world.

6. Tell me about a time you had to work hard in order to hit a commitment. How did you coordinate with the team and what did you learn from the process?

• This is the one from above. It gets at both personal and company perspective and also gives me the opportunity to ask follow-ups like "How often does this happen" or "How do you feel about it?" if necessary.

Pay Attention to the Types of Questions They Ask

In addition to asking the questions, it's important to get a picture of what they care about and what they're aiming for. Are they following up to anecdotes I've mentioned or are they walking through a list? Are they looking for a set of traits that they're checking off, or are they curious and trying to get to know me better as a person.

There's No Silver Bullet

These questions are meant to be a starting place to think about questions. I think all interview questions should be updated over time as attitudes about the hiring process involve. Certain questions will fall in and out of favor (which means people might be more or less practiced with an answer) and the important thing isn't to instrumentalize the process or assume there's a single set of questions to ask to tell 100% of the time.

I hope this helps!