Questions to ask in your developer job interview

Najaf Ali
Happy Bear Software
6 min readJan 15, 2017

In job interviews, there comes a point when the interviewer asks you for questions. Most candidates answer “no”. Sometimes they answer with one or two questions for the information they think they need about the company and the offer.

This is an enormous waste. Until this point, the interviewer has control of the conversation. They ask you a sequence of questions, with the goal of assessing your suitability as a candidate. When they ask for your questions, they are handing control of the interview over to you. You can do much better than just a couple of sheepish informational queries here.

You should have two overall goals in your job interview. The first is to get an offer from the company. Asking intelligent questions can go a long way to demonstrate how you think, what you value, and other positive characteristics you have that the interviewer might have missed. At most companies, all of this will lead to a higher chance of you getting the offer.

Your second goal is to find out as much as you can about the company. You want to do this because making the decision to start work at a company will have a huge impact on your career and quality of life. Spending even a short probationary period at this company is a one to three month chunk of your CV for this year. You may end up spending years of your life here, spending more time with your coworkers than people you actually care about. The stakes are high, and it’s worth finding out as much as possible about what working at this company will be like before entertaining an offer. Asking questions at an interview can get you a first hand account of the working conditions and career progression from a a real-life employee of the company.

In this article I’m going to give you a list of questions that you should consider asking at the interview. You don’t have to ask all of them, and there’s no special wording I’m using here. These are just to get you thinking about what you should ask when you get to this stage of the interview. Come up with 5–10 questions of your own, using this list as an inspiration, put them in your notebook, and take your notebook into the interview.

Can you describe how you spend a typical day? This gets the interviewer talking and gives you a quick reference point about one employees day-to-day activities at the company. Depending on their role, you might want to worry if e.g. they spend all day in meetings, or don’t go to any meetings at all, or have to turn up very early/stay very late to get any work done.

How is development time split between firefighting, maintenance, and feature development? Here you’re asking about the proportion of time spent on each of these activities. Asking these questions shows that you have practical experience of actually working on a development team. Avoid workplaces that are too heavily weighted towards firefighting, it was likely a lack of adequate budget, expertise, or engineering culture that got them into that situation.

What concrete steps does the company take to foster diversity and inclusion? Regardless of your politics, this is a good question to ask. How they answer will tell you a lot about the organisational stance towards these issues, giving you the information you need to decide whether you’re aligned with it. If the interviewer gives a concrete set of actions they’ve taken or is taken aback by the question, that answer carries information. If they are dismissive of the question, that answer carries information too.

What are the medium to long-term goals of the company? Here you’re asking about medium to long term vision and strategy. This shows that you can think not only about your day-to-day work but the context within which it sits. The answer gives you two bits of information. Firstly if the interviewer can answer coherently at all, it indicates that the organisation is good at communicating it’s plan to everyone at the company. Secondly it tells you what the company will be focusing on in the medium and long term. You can use that information to determine how well the companies goals align with yours.

Is there budget and time set aside for professional development? Asking this question shows that you’re interested in improving your effectiveness as an employee. The answer tells you how much support you can expect from the company in doing so. Many technology companies provide budget for workshops, books, conferences, and other training, and give you time to work on your skills in some form. The more of that the better.

What is the company’s stance on working from home? Maybe you like the idea of working remotely and maybe you hate it. This question tells you what you need to know about this company either way. A company that is 100% in-office is fine. A company that is 100% remote is fine. The difficulty comes in office/remote hybrid situations if the office becomes a privileged area for communication. These difficulties can be addressed, but you’ll want to question further to make sure they have been.

How often do you deploy to production? In the right company, this question hints at an opinion about how software should be released. Many tech companies deploy their production applications multiple times a day, though this requires a commitment to automated testing with infrastructure set up to run all of those tests before a deployment. Other tech companies might deploy every week, every fortnight, once a month, or at even larger intervals. You probably want the former.

Can you describe the stages a feature or change has to go through from requirements gathering through to deployment to production? Here you’re asking about the development process. This again indicates that you’ve done this job before. Since you’re going to be plugged into this development process, it’s important that you’re on board with the status quo, at least to begin with. Too little, too much, or needlessly time-consuming process can all be bad signs.

How early in the requirements gathering process are the development team consulted? What format does that take? Here you’re really asking about what the relationship is like between the development team and the rest of the company. Is it collaborative, with the development team brought in to inform strategic decisions before they get into a backlog? Is it adversarial, with requirements dropped “over the wall” for the development team to work on?

What is the development team’s stance towards testing? At face value this will tell you a bit about the engineering culture at the company. It also tells you how willing the company is to invest in the quality of the software you’re producing. Additionally, if the conversation switches to one about test coverage, dogmatic adherence to “best practices”, or hero worship of programming gurus, you’ll know to avoid that too.

Does the development team do code review before deploying code to production? Code review is a highly effective way for a team to share knowledge and establish a set of shared technical norms and values across a development team. Asking about them and how they’re done should tell you a bit about how the development team communicate with each other.

How often do you do one to one meetings? Doing regular one-to-one meetings is the absolute basic minimum required to run a functional team of any kind. Asking this question should give you an idea of how good the company is at management. If they don’t do one-to-one meetings, you can ask about how employees give feedback to managers and team-leads.

This is a relatively small sample, but should give you enough to begin a meaningful conversation with your interviewer about what working for their company will be like. Use them, don’t use them, come up with your own questions, but whatever you do, use this moment to take ownership of the interview. Guide the conversation to topics that indicate that you’ve done this job before and give your more information about the job at hand.

This won’t guarantee an offer, but it will make it more likely. When you get the offer you’ll also be much better positioned to decide if it’s one you want to accept. These are all good things for both you and for the company.

--

--