Often, we focus on acing an interview. However, we need to remember that the process is a two-way street. When the interviewer turns to you and says “do you have any questions for us?”, make sure you’re ready to get the information you need to make a good decision about your next career move.

Interviews are a Two-Way Street

If you spend the entire interview “proving” to the prospective employer that you’re worth hiring, you lose out on the opportunity to measure whether the company with which you’re interviewing is worth your time and effort. Making sure you ask questions of the employer serves a couple important purposes:

• You avoid landing at a company that’s a bad fit
• It takes the pressure off you a bit—they have something to prove here too.

Questions I Like to Use

Generally I like to ask questions that both demonstrate that I myself have a good grasp on modern software development practices and also prod into whether the company employs these practices. In my experience, a company that does not employ modern dev practices is harder to work in: fewer “wins,” painful deployments, a culture of blaming, and less opportunity for growth.

What Does the Development Process Look Like from Feature/Bug Discovery to Delivery?

This is a great question because it’s open-ended and doesn’t give the employer too many hints as to what you’re looking for. What I look for from this question is the following:

• Evidence that feature requests or bug reports are triaged and prioritized.
• Is there a sense of product ownership? Does the company evaluate whether the feature/bug is in service of the product vision, or do they just chase every feature request with reckless disregard?
• Is there a backlog? Are there sprints? Is there regular backlog grooming and sprint planning?
• Are features/tickets/stories pointed to estimate level of effort?
• Is the company using a reasonable code control system (hopefully Git)? Do they do pair programming and/or PR reviews? (I enjoy pair programming but don’t love it full time; this is a personal determination!)
• Does the company use automated testing? Manual QA? (the former is a must; the latter not so much, in my opinion)
• Does the company use continuous integration and continuous delivery?
• How onerous is the deployment process?

You can see that I expect lots of information out of this one question! If any of the key elements of modern software development is left out of the discussion, bring it up directly. For example, if the company doesn’t bring up continuous integration, ask them what they use for continuous integration. If they act offended or taken off guard by you asking this level of detail about their operations, that’s a red flag.

What Kind of Monitoring and Telemetry Do You Use?

It’s good to understand at what level the company is tracking the performance of their application(s). Additinally, you may be able to tell if they have something like PagerDuty and would expect you to be on rotation for application support (very important to know!). You may additionally get some information about Objectives and Key Results (OKRs) that the company tracks, which would be good to know as they would help you understand what outcomes your work may be helping to drive towards. I would consider it a red flag if the company did not mention reputable monitoring and logging services (e.g., DataDog, Splunk) or, again, if the interviewer is taken aback by the question.

What Does Incident Response and Remediation Look Like?

This is extremely important to understand, mostly because you want to know how a company treats its people under duress. Hopefully, the company has an Incident Response Plan that outlines reasonable steps to take during an incident. Even if they don’t share the exact details of the response plan (I wouldn’t expect them to), you should expect to hear that there is one. Hopefully, they keep important stakeholders and users in the loop during an incident and through resolution.

After an incident has been resolved, does the company conduct a postmortem? Is it blameless? For me, lack of a blameless postmortem process is a potential dealbreaker—the last thing you need is to be a part of a company that instills fear of making mistakes rather than using issues as learning opportunities.

How Does the Team Improve Its Processes and Knowledge Over Time?

This is almost directly asking if there are regular retrospectives and information sharing meetings. Continuous improvement is key to optimizing a team’s ability to deliver (not to mention happiness!), so you sure hope they’re have open discussions about what’s going well and what isn’t going well each sprint. Information sharing meetings are probably less common, but worth asking if they exist. If you’re a backend engineer and the frontend team has introduced a new testing tool, it’d be great to learn what that tool is all about.

Conclusion

These questions should tel you a lot about how a company operates. Ideally, they’re practicing a lot of the important mordern software development practices mentioned above. If not, it may be wise to move on and consider youself lucky that you asked these questions!