Questions to ask potential employers
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 quickly to cover your living expenses, you may not be able to afford to be picky about your employer, and when you're asked the inevitable, "So, what questions do you have for us?" the only question you have is "Will you give me money in exchange for work?"
However, when you're comfortably employed at a job that doesn't leave you satisfied, you have more leeway to find a new environment that will help you thrive. Your job is your biggest investment in yourself, and staying a job that restricts your growth—especially early in your career—can have lasting impact on your income and skills. Demand for highly effective and motivated programmers currently outpaces the available supply, forcing companies to compete for our time in the form of benefits, salary, and work environment. However, it can be hard to evaluate how happy you'll be a company before joining, and rapidly changing jobs can be draining and stressful.
In my career (as of May 2018) I have worked for 7 different companies, ranging from 4th employee at a startup to a Fortune 100 financial company, and no 2 companies are in the same industry. I feel this has given me a relatively uncommon perspective on how companies operate at different sizes, in different industries, and at different points in the development lifecycle.
To this end, I've compiled a list of questions that I ask, wish I had asked, or plan to ask in the future. Each question has additional details about why I find that quesiton valuable and what answers I anticipate. It ended up being a lot longer than I expected, so I'm splitting it up into several parts to avoid it being too overwhelming.
- The onboarding process, workplace, and team
- The development environment and emergency situations
- Personal growth
- Project management
How long do you expect it would take me 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 overall health of the team. The faster you can deploy your first change, the more likely they are to have well defined tasks (that are well understood and prioritized), a deployment process that's simple enough for a new person to perform, and confidence that somebody unfamiliar with the overall system will be able to make a change.
Asking how long before they expect you to become productive will help you set expectations. For junior or mid level roles, I don't think it's uncommon for this to be measured in months. The question will help you and your employer get on the same page, which I think helps stave off some of the impostor syndrome that can come with familiarizing yourself with a new codebase--especially if you haven't experienced that many times.
For many teams, there likely isn't a single person who understands the entire codebase. In frontend it's more likely that you'll eventually develop and understanding of the whole because it's less likely to contain specialized expert knowledge. Reactions to this question can help you gauge how the developers feel about the code they work on.
What kind of equipment will I be provided? Will the company pay/reimburse me if I want something specific?
Equipment is critical. In my mind, the expense associated with getting a developer outfitted with their preferred equipment is relativley small compared to the salary and benefits of a developer. Filling a desk with laptop and peripherals costs less than a single month's salary for any midlevel developer. Once you've developed for a few years you may grow accustomed to a specific set of devices, and I believe it's a reasonable expectation that the company should provide them.
On the other hand, I have purchased my own equipment that I bring in to jobs, because my experience at most companies does not match my opinions on the matter. Even if they do reimburse or expense equipment, they may want to wait until they're confident you won't leave before making the additional investment in devices that may not be used in the event of your departure.
Perhaps unintuitively, I've found that smaller companies are more likely to be willing to provide me whatever equipment I ask for. This may be a result of small companies having been more likely to have recently raised funding, or perhaps smaller companies are more willing to invest in employees due to having a smaller number of them.
Workplace and team expectations
How many of the developers have been here less than 6 months?
A large number of developers that recently joined means 1 of 2 possibilities: rapid growth, or high turnover. Rapid growth is great for a business, but it also means that they're figuring out new processes and assembling teams out 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 can be a red flag. It could mean stressful work conditions where people rapidly burn out and quit, a high pressure environment that has unreasonable expectations of its employees, a company that's on hard times, or a reorganization to save a project. When interviewing at a company that shows signs of high turnover, it's even more important to ask a lot of questions and try to build a sense for why that's the case.
The most important person to ask questions of is the person overseeing the team that's experiencing turnover. It's hard to ask questions in this area, but finding out whether they quit or were fired and reading the tea leaves of whether you might be soon to join their ranks might save you a negative experience.
How many developers have been here 2 years? 4 years?
This can act as a proxy for job satisfaction within developers. It's not impossible to get a single developer to stay in a bad situation for years and years, but it's much more difficult to find several on the same team. Four years is a very long tenure at a single company in startups, anywhere that has multiple developers who have worked there for two or more years has likely gotten their culture above a certain threshold. 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 will 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 much of the team is made up of contractors, who may be brought in to help bolster a struggling team or as a last-ditch effort to save a failing project.
How often do 2 devs work together on a single task? 3 or more devs?
To use the common jargon, pair programming and mob programming. There's a classic comic about interrupting developers.
But I recently saw this version updated for pair programming, and it strongly resonated with my experiences.
Development is not an inherently solitary activity, and I believe that working together on a single task produces better output than working individually. Of course there are times where you need to split off and write code independently, but programming as part of a team is about precisely committing mental models to disk: the clearer the mental model, the better the end result, and extended discussion between multiple developers is, in my opinion, the best way to clarify mental models.
This is about getting alignment with your potential employer, however. This question helps me find out if we share the same view on collaboration. If you prefer to work alone, you may strongly prefer a different answer to this question (I'd encourage you to think hard on why you prefer to work alone as well).