Questions for your interviewer

The nature of the software development job market means that most developers will interview regularly throughout their careers. It's often said that an interview goes both ways. It's supposed to be a back and forth conversation. You're evaluating them as much as they're evaluating you.

Of course, the power dynamic is never in your favor as the candidate. You spend most of the interview selling (at best) or defending (at worst) yourself. If you're lucky, your interviewer reserves 15 minutes at the end for your questions. If you're unlucky you get a perfunctory chance to ask a single question before they shake your hand and escort you back to the lobby (or close the Zoom meeting). By then you're tired and stressed from having just gone through your own interview, you don't know what to ask or how you would even evaluate the answers. Hopefully this post helps with that.

Below I'll go through some suggestions for questions you can ask when it's your turn. But first, I'll talk about my assumptions. I'm assuming that you are a software developer (or programmer, or engineer, or similar). I think a lot of this would be applicable to other roles, but that's not where my experience is. I'm also assuming that you want to work in an environment that's safe and empowering for you and your colleagues. Particularly for your marginalized colleagues. These questions are intended to explore how the team works, and how the company views and treats their employees. I'm mostly ignoring technical questions here. Hopefully you know how to ask what frameworks they use or how long their sprints are, if you don't know already from the job description. Instead, these questions focus on team dynamics, quality of life, psychological safety, and so on.

A lot of these questions are intended to uncover some realities of the work environment indirectly. Why be indirect? Honestly, because a lot of the time I don't expect people to be able or willing to give an honest answer to the direct question. For example, I really want to know if I will have psychological safety and be supported by the organization if things ever go wrong. I have difficulty imagining that anyone would ever answer "no" if I just ask that flat out. So I instead ask what the process is for following up on production incidents, because that's a time when those protections are critical. If the process would protect individuals, that's a good sign and would enable a healthy team dynamic. If not, that's concerning. If there's no process, that also is quite telling.

Now the part you're really here for, the reverse interview questions. After each question, I'll describe what promising, neutral, and worrisome answers look like. I'll also discuss what you can learn from the question, so that you know how to contextualize and follow up on any answers you get.

How long does it take a new developer to get up to speed?

😀 1 to 2 days
😐 1 to 2 weeks
😱 More than 2 weeks

The answer to this question reveals a lot about the overall developer experience. The care and attention that's given to onboarding a new person into a team and project will carry over into the project itself. In addition, all of that work will directly benefit the developers on that team in the long term. The things that make this slow is when it's hard to get the code, or to set up a development environment, or to configure the necessary development tools, and so on. Sometimes people think of these tasks as one-time problems, but they're not. These things have to be done over and over, when investigating issues, when debugging, when running tests, when doing deployments. Spending a little time to make these things easy, or even automatic, is a major investment in the experience and wellbeing of a development team.

Can you tell me about an ongoing or recently completed project?

😀 They can and do
😱 They can't or it's difficult/unclear/evasive

The idea with this question is to dig into how decisions are made, how priorities are established, and how that is communicated with the teams it will affect. People and teams have needs, and those needs should be considered and met. The best way to do that is to allow them to have enough agency over their own work that they can do most of it themselves.

Here are some follow up questions to help you do that. How was that project designed or built? What other options were considered, and why did you choose this one? What other projects were deemed a lesser priority and what made this the highest priority? How was this project presented to the team? Did the team have any input? What affect did that input have on the design, scope, priority, etc? How and when did you seek that input?

How do you measure success?

😀 An answer related to desired outcomes for the people or issues involved
😐 Any logically coherent answer involving outcomes
😱 Anything else

It is super common that people and organizations will just start doing things without ever giving thought to the reason they're doing it or how they'll know they succeeded. This works well enough with your chores. It doesn't work with complex systems like big software projects and the teams that build them. This question gets into the organization's ability to identify goals, and also to recognize that a goal is not a plan. When you ask the question OKRs might come up (Objectives and Key Results). That's reasonable, but it's important that the key results in those OKRs are real observable outcomes and not just goals in their own right.

After a production incident has been resolved, what happens next?

😀 They intentionally review, learn, and improve
😐 Nothing changes (giving time off or free food is not change)
😱 They consider production someone else's problem

Incidents happen in production. That's just the reality of complex systems. You can and should try to reduce the frequency and the impact of those incidents. But, that's not the point of this question. The point is to understand how the team and the company behave once the incident has been resolved. Ideally, it is taken as a learning opportunity, and some productive action is taken. This could be setting up guard rails, improving documentation, providing training, or anything else that's forward looking. If they talk about finding or avoiding blame, that's a big red flag. Likewise if they don't think they have to be worried about what happens in production. It's true that development and operations are different concerns handled by different people, but developers should still be aware of and care about the realities of production.

How often do you do deployments?

😀 As soon as changes are ready; daily or more
😐 Weekly, or at least once per sprint
😱 Less often than that

By far the best predictor of how well a development team performs is how often they are able to deploy changes to production. This benefits every step of development and operations. Deploying quickly both enables and is enabled by a safe development environment where teams operate at a high level and respond quickly to changes.

Edited to add:
There are a number of useful follow up questions here. How long is the delay between when changes are committed to when they're deployed? What strategies does the team have to make deployments safe and reliable? What tooling do they use to enable that? In general, teams perform best with shorter feedback loops. And the feedback loop between making changes and applying them to the real system is the one that ultimately matters. So the best situation is one where changes can be deployed as soon as the team agrees they're ready, and where that deployment is fast, safe, automatic.

How are security and accessibility issues prioritized?

😀 They are considered from the beginning, alongside features
😐 They are addressed ad-hoc, after problems arise
😱 They are rarely fixed, or don't make any effort to uncover them

Security and accessibility are important. The mercenary reason is that they can become major liabilities if they're ignored. But really, they're important because they affect people. Failures of security or accessibility can cause real harm to vulnerable people. The company should care about that. They should appreciate they have a responsibility to people, and try to do the right things to keep those people safe. This question reveals a lot about how the company views people.

Can you tell me about your stats and initiatives related to DEI?

😀 They can and do
😐 They seem confused or hesitant
😱 They don't have any, won't share it, or dismiss it as unimportant

Diversity, Equity, and Inclusion (DEI) is the umbrella term for any effort to make workplaces more equitable and less discriminatory. It's an imperfect conceptual framework, but it's extremely common so you can trust people will know what you mean when you ask about it. It's a good sign if the company is tracking these things and has taken action to improve them. If they actually give you some direct numbers, it's helpful to know that as of 2020 about 70% of professional software developers are white and about 91% are men. Just know that both of those groups are overrepresented, and use it as a starting point to discuss efforts to make the team and company safe and inclusive for everyone else.

If you are a cisgender white man, this is a chance to exercise some privilege. Asking the question signals that you care about this stuff. You might never have more leverage with a company than when you're a promising candidate for a role they're trying to fill. You can make it clear that failing to support and protect vulnerable people is a recruiting obstacle. And you can bring up issues that those vulnerable people don't have the safety to discuss.

Does your health plan cover gender affirming surgeries for transgender patients?

😀 Yes, and they knew that already
😐 Yes, but they had to research it
😱 No

This one is easy. Healthcare is a human right, transgender people are people, and in the United States your access to healthcare is determined by your employer in most cases. It's a terrible system, and I hope we can change it soon. But for now, it's up to employers to either provide or withhold healthcare for their employees. I'm sure you don't want to work for a company that would withhold healthcare from people. Again, if you're cisgender, this is an opportunity to exercise some privilege for marginalized people.

What changes to your product or process have you made in response to Covid-19?

😀 Any real change to make work easier or less stressful
😐 Going fully remote with some financial support
😱 Not going fully remote

2020 was an absolutely brutal year for most of the world. 2021 hasn't improved much. Before covid and the associated isolation, the normal state of work was already pretty taxing on most people. Now, it's untenable. Work can't just keep demanding more and more of people forever. Ideally, a company has made some changes to reduce the stress that work is adding to their employees. Great options would be to relax deadlines, eliminate performance reviews, or prioritize fixing problems that cause unnecessary stress and disruptions. If nothing else, moving to a fully remote work force is the minimum that a company could do to maintain a safe work environment.

Cover photo by Wallace Chuck from Pexels