Searching for a job sucks, especially early in your career. Most applications never get a response, 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.
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 environment. However, it can be hard to evaluate how happy you’ll be at a company before joining.
In my career (as of April 2018) I’ve worked for 6 different companies. I’ve helped run a startup, worked for a small local business, a Y Combinator company, two other startups of different scales, and a Fortune 100 company. I’ve worked with hardware, agriculture-tech, ad-tech, health-tech, and at a financial company. I feel this has given me a relatively uncommon perspective on how companies of different sizes, in different industries, and at different points in the development lifecycle operate, and changing jobs 6 times has given me a lot of experience interviewing.
To this end, I’ve compiled a list of questions that I ask, wish I had asked, or plan to ask in the future, with additional details about what kinds of answers I’m hoping to hear. Here’s the first one:
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.
This post is brought to you by InRhythm’s own Carl Vitullo. Follow him on Twitter for more brilliant thinking like this.
