When you go into an interview you will be asked a lot of questions.
I’ve interviewed at least a couple dozen people and I’d say about 85% of the time when the developer, somewhere towards the end of the interview, is asked “And do you perhaps have any questions for us?” they answer “No”.
Unless we’ve had a lot of to-and-fro and a more organic conversation this is a huge red flag for me. It means they don’t value themselves; it means they’re not curious, it means that in all likelihood they just want to get a job rather than a good job and it also means they’re not experienced enough to have had bad experiences that they want to avoid repeating.
So here is a list of potential questions you can ask your prospective employer that show you value yourself, that you are good enough to have choice and therefore need to make your own estimation of what a company can offer you.
What does an average day look like?
Do you do standups? Online, in the office? Does all the team work 5 days a week? How many meetings do you have a day? Are they adhoc or according to a schedule? Does everyone do 9-5 or can I take an afternoon off and work in the evening?
Can you describe the developer culture?
Do developers share knowledge? How? Hackathons, knowledge sharing presentations, pairing, switching teams? Is it a competitive environment or a collaborative one? How do you ensure knowledge moves from seniors to juniors? Is the department a silo or is there knowledge and skill sharing across the whole enterprise?
What technology stack do you use?
How much freedom is there for a team to use a different stack? Who decides the stack? How does it evolve over time? What’s the current roadmap? What’s worked well and what do you think has been a mistake?
What is your CI/CD pipeline?
How do you guarantee a level of quality? What sort of tests do you run at which stage? How much is automated?
How do you manage observability?
How do developers get alerted to problems? What kind of problems do you face and with which frequency? How often should I expect to be working outside of office hours? When an issue occurs what tooling do you have available to diagnose and trace the problem? Do you collect metrics and if so, how are they made available?
How is work specified?
Do you work with user stories? How are they specified? How are requirements managed? Who is responsible for this? How does the business interact with the technical teams? How much domain knowledge do the developers need?
Do you work in feature teams or component teams?
What is a team responsible for? How is work that touches multiple teams managed?
What is the biggest challenge for the software?
Scale? Performance? Consistency? Complexity? Availability? Security? Maintainability?
What’s your employee turnover rate?
What’s the biggest reason people leave?
Being critical of a company isn’t being negative or being picky it’s being self-respectful. If you are a good developer then these things should be important to know and it’s important for you to know them before you make a commitment.