Interviewing for a Software Engineering Position

The interview process is as much about preparing yourself to answer questions about you and your skills as it is you interviewing the prospective employer to see if it is a place where you want to work. Very close attention should be paid to the interview process, or lack thereof, that you go through.

The basic stages that you should expect from a well engineered interview process are

  1. Initial phone screen
  2. Technical phone screen
  3. Hiring Manager, Tech Lead/Team interview
  4. Offer Negotiations

Researching the Company

Interviewing the Company

Are their defined policies for security, DNS, storage, monitoring and alertingData governance?

code reviews?

One of the things

Questions for Current and/or Former Employees

Talking to current or former employees of an organization is a good way to get information about a prospective employer. Ideally, the person that you are talking to should be a Software Engineer as that will hopefully get you some good firsthand information about what working there as a Software Engineer might be like.

Questions are broken down into three main categories

  1. Informational: These questions are geared towards gathering information about the company, work environment, languages and tools used, etc. This is a good way to start the interview and break the ice. A lot of the answers to these questions will lead to additional questions.
  2. Behavioral: These questions get at information about things that have actually happened. Questions that start with, “Tell me about a time when…”. One of the things to listen for is to hear what happened especially when things did not go as planned. And then, whether or not the organization paid attention to what didn’t go well and how they made changes for the better. More succinctly, does the organization have the culture and processes in place for honest organizational introspection.
  3. Situational: These are questions about the future and hypothetical situations. Questions that start with “What happens if…”, or “What would you (or your team, boss, division, etc.) do if…”. They put people in situations that they have not experienced and ask what they would do and help you get information on how they think that their employer would react. Frame these questions around specific things that you have seen in places that you have worked that you both liked and disliked. This will help give you some insight as to how a potential employer might handle the same scenario. The key here is to think about that is important to you. If an organization that has blameless post postmortems as a core part of their culture is important, be sure to pose a hypothetical question which will lead the conversation in that direction

A typical balance between the Behavioral and Situational questions is about a 70/30 split.

The following are a set of questions that I use.


  1. What do you do there, what is your role?
  2. What are you working on?
  3. What languages do you use?
  4. What is your development environment like?
    1. What OS do you use?
    2. What IDE(s) do you use?
  5. How is your team organized and what are its responsibilities?
  6. How does your team do code reviews?
  7. How often do you deploy new code?
  8. How does your team plan it’s projects and tasks? This is a question that is trying to get at the type of planning and development methodologies that the team uses.
  9. Do you and your team write unit and integration tests?
  10. How does your team approach observability, monitoring, and alerting for the systems that it builds?
  11. What is your manager like? Are they open to honest feedback about how things are going or suggestions about the work you are doing?
  12. What are the best things about working there? What would change if you could?
  13. Can you tell me about something that happens here that wouldn’t happen anywhere else?


  1. Tell me about a time when you or someone on your team deployed updates to a system that broke it? This is a good questions that will hopefully open the door to further discussions about observability, automated deployments, monitoring and alerting and how those are implemented and the wider policies behind them.
  2. Tell me how your team goes about planning and building out a new system?


What happens if your team misses its sprint goals or falls below its target velocity?

The Guerrilla Guide to Interviewing (version 3.0)