(image credit: Nik MacMillan)

Searching for a job sucks, especially early in your career. Most applications never get a response, most responses don’t turn into interviews, and most interviews don’t turn into offers. When you’re unemployed and need to find something to cover your living expenses, you may not be able to afford to be picky about your employer. When you’re asked the inevitable, “So, what questions do you have for us?” the only question you care about is “Will you give me money in exchange for work?”

However, when you’re employed at a job that doesn’t leave you satisfied, you have more leeway to find a new environment that will help you thrive. There are a lot of companies hiring software developers, forcing them to compete for our time. But it can be hard to judge how happy you’ll be a company before joining, and changing jobs is stressful. Asking good questions during your interview can help you find out if it’s somewhere you’ll enjoy working.

In my career I have worked for 6 different companies, ranging from 4th hire at a startup to a senior developer at a Fortune 100 financial company. This leaves me an uncommon perspective on how a wide range of companies operate. Changing jobs so many times has given me a lot of experience interviewing, as well.

I’ve compiled a list of questions that I ask, wish I had asked, or plan to ask in the future. Each question has details about why I find that question valuable and what answers I expect. It ended up being a lot longer than I expected, so I’m splitting it up into several parts so it isn’t too overwhelming:

• The onboarding process, workplace, and team (this one)
• The development environment and emergency situations
• Personal growth
• Project management

Onboarding process

How long will it take to deploy my first change? To become productive? To understand the codebase?

How long it takes a new developer to deploy their first change is a decent proxy for health of the team. The faster you can deploy (not commit, not merge, but deploy) your first change, the more likely they are to have good processes and healthy infrastructure. I define this as well defined tasks, a simple deployment process that a new person can perform, and confidence changes won’t break anything. Some companies can deploy a new hire’s first change on day 1, at others it may take weeks.

For junior or mid level roles, it’s not uncommon for it to take months to become productive. Asking what expectations your manager has will help you get on the same page. Knowing what’s expected of you helps stave off some of the impostor syndrome — especially when you’re early in your career.

Many teams don’t have a single person who understands the entire codebase. Web and mobile apps are less likely to contain specialized expert knowledge, making them easier to fully grok. Reactions to this question can also help you gauge how the developers feel about the codebase overall.

What kind of equipment will I be provided? Will the company pay/reimburse me if I want something specific?

Equipment is critical. We spend 8 hours a day using it, and filling a desk with a decent laptop and peripherals costs less than a month’s salary for any midlevel developer. You may grow accustomed to a specific set of devices through your career, and I believe it’s a reasonable expectation that the company should provide them.

On the other hand, I’ve bought my own equipment because my experience at most companies does not match my opinions on the matter. They may have a waiting period after your date of hire before paying for peripherals. Companies don’t want to invest in devices that may not be used in the event of your departure. I’ve found that smaller companies are more likely to be willing to provide me the equipment I prefer. Large companies may have more draconian device policies or purchasing processes.

Workplace and team expectations

How will you know if I’m doing a good job?

This might be the most important question to ask, and it’s a good question to ask of several people. Developers and managers will have different types of answers to this question, and asking people in different roles can give you a good sense of the range of priorities.

The answer to this depends a lot on your experience level and the exact position you’re applying for. For a junior role, a good team will judge you by how well you learn from the other developers. Senior developers excel by multiplying the efforts of their coworkers.

How often do two developers work together on a single task? Three or more developers? To use the common jargon, pair programming and mob programming. There’s a classic comic about interrupting developers, summarized as “your stupid interruption reset my progress figuring out this code.”

I recently saw this version that was updated for pair programming, and it resonated with me.

I keep seeing that one comic around about Never Interrupt A Developer, and I couldn't really relate, so I redrew it to reflect my experiences pic.twitter.com/liXbFM2eSA

— Anne LoVerso (@AnneLoVerso) March 9, 2018

Development is not an inherently solitary activity. Working together on a single task produces better output than working alone. There are times where you need to split off and write code, but programming as part of a team is about committing shared mental models to disk. The clearer the mental model, the better the end result. Extended discussion between developers is the best way to clarify mental models.

But this is about getting alignment with your potential employer. This question helps me find out if we share the same view on collaboration. If you prefer to work alone, you may want to hear a different answer to this question, though I’d encourage you to think hard on why you prefer to work alone.

How many of the developers have been here less than 6 months?

A large number of developers that recently joined means one of two possibilities: rapid growth, or high turnover. Rapid growth is great for a business, but it comes with problems. They’re figuring out new processes, and assembling teams of people who have never worked together before. It’s good to keep in mind when joining to try to understand what challenges that brings, and what you’re getting into.

High turnover is usually a red flag. It might mean people are burning out because of stress or unreasonable expectations. The company might be on hard times or attempting to save a project. When interviewing at a company that shows signs of high turnover, you should dig deeper to find out why that’s the case.

The most important person to ask questions of is the person overseeing the team that’s experiencing turnover. This is a sensitive area to explore, so be cautious. Your goal should be to find out whether employees quit or were fired, and judging whether you might join them.

How many developers have been here 2 years? 4 years?

This can act as a proxy for job satisfaction within developers. It’s possible to get a single developer to stay in a bad situation for years, but it’s much more difficult to find several on the same team. Two years is a long tenure at a single company in startups. A company with several developers who have worked there for more than two years likely has a good culture. Of course, this assumes the company has existed longer than that. If they’re younger, it might be better to ask how many of the first employees are still with the company.

This applies to large companies as well. A developer may have been with the company for 4 years, but only on a particular team for a few months. It may also be helpful to ask how many contractors are on the team. Contractors are often brought in to help bolster a struggling team or as a last-ditch effort to save a failing project.

Thanks for reading the first group of questions to ask your interviewer! Stay tuned for part two, with questions about the development environment and emergency situations, in a few days. I’m on Twitter as @vcarl_, and I moderate Reactiflux, a chatroom for React developers (shoutout to the jobs-advice channel), and Nodeiflux, a chatroom for Node.JS developers. If you have any questions or suggestions, reach out!