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
- 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.
- 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.
- 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.
What You are Trying To Uncover
- Unwillingness to invest time in automated testing, but still pressure because things are unreliable
- I want to invest the time to do things right up front so that I not saddled with broken shit and getting woken up all the time to fix stuff
Are you willing to do things right even if they take a little longer. Is that valuable to the organization?
There is no way to affect organizational change because upper management is not willing to make any decisions. As a result everyone reinvents the wheel everywhere and there is no collective effort towards a common goal.
How is the need for change identified in the organization and is there a process for driving it? Looking for management says “this is what we are doing”.
Start-up and 1000000 hours a week. Sustainable pace of work
I at a point where I want to give 100% . . . tell me about
The following are a set of questions that I use.
- What do you do there, what is your role?
- What are you working on?
- What languages do you use?
- What is your day-to-day look like?
- What is your development environment like?
- What OS do you use?
- What IDE(s) do you use?
- How are DEV/TEST/PROD environments setup?
- How closely are they configured?
- How do you maintain parity between them?
- How are changed propagated through the environments?
- What is the policy on unit, integration, and system testing?
- How is your team organized and what are its responsibilities?
- How does your team do code reviews?
- How often do you deploy new code?
- How does your team plan its projects and tasks? This is a question that is trying to get at the type of planning and development methodologies that the team uses.
- How does your team approach observability, monitoring, and alerting for the systems that it builds?
- Can you tell me about how management communicates information to the company?
- What is your manager like?
- How does he/she direct your work?
- How does he/she respond to feedback about how things are going or suggestions about the work you are doing?
- What are the best things about working there?
- What would change if you could?
- Can you tell me about something that happens here that wouldn’t happen anywhere else?
- What is the work-life balance like?
- 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.
- Tell me how your team goes about planning and building out a new system?
- Think about your most recent deployment. What short-cuts were taken and how were they/will they be addressed?
- What happens if your team misses its sprint goals or falls below its target velocity?
- Can you give me an example of a situation where the need for change was identified by engineers and adopted and championed by management?