part-1.md

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

Onboarding process

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.

https://twitter.com/detly/status/394755439314755584

But I recently saw this version updated for pair programming, and it strongly resonated with my experiences.

https://twitter.com/AnneLoVerso/status/972239118976651269

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).

part-2.md

Development environment

How long does it take to do a complete deployment?

Long deployments are often manual deployments, which are more prone to errors and accidental downtime, and long deployments increase cycle times and make people more nervous to make changes. This question can also serve as a proxy for how improvements that aren't user-facing are prioritized. User experience is of course tremendously important, but a good developer experience will help them roll out user-facing improvements more quickly, and will make working there more satisfying.

I work in frontend mostly, and as such generally ship static files as build artifacts. I prefer to hear that deployments are less than 15 minutes, and can be done by any developer. I'm ecstatic if they have the ability to run multiple testing environments simultaneously, but I've found that rare.

How large are PRs? For a "big" PR, how many lines of code? How long is it open?

Small PRs are simpler to manage, cause fewer (and smaller) merge conflicts, and indicate a better understanding of modern continuous delivery strategies. Large, long lived branches can be a sign of inexperienced tech leads or a lack of rigor in managing tasks. Large PRs are the only option in codebases where many modules are tightly coupled, so having the ability to ship small PRs continually is indicative of well maintained code.

To me, a "big" PR might be 2000 lines of code, or touching 20 different files. I prefer to open PRs early as work-in-progress (ideally receiving direction and code review from coworkers along the way), and might have it open for half of a two-week sprint. When PRs are opened only when they're "done" and expected to be code reviewed, I'd prefer them to touch no more than a handful of files, or change less than a couple hundred lines of code.

Ideally, the team is already comfortable shipping changes behind feature flags. Feature flags are easier to do if the code is more decoupled, so I feel more confident that a team trusts its codebase if they're using feature flags.

How many repositories would I touch to make routine changes?

Some projects might be in a monorepo so large that there are a thousand commits a day, some projects might be scattered across hundreds of repositories as a web of interlinked dependencies.

This question should be used to kick off a conversation about project structure and code sharing. For small companies that may only have a single product, having a large number of repositories is a red flag. For large companies, I'd want to ask how they manage code duplication and internal libraries.

How often do developers have to make simultaneous changes across repositories?

To me, frequently needing to tightly coordinate changes in multiple repositories signals a lack of clearly defined responsibilities and tighter coupling between modules. By "simultaneous changes" I mean careful coordination of multiple deployments across services to avoid incompatibilities. An important part of creating something robust and durable is understanding what faults related services can tolerate and not breaking compatibility.

Releasing a new backend version shouldn't necessitate a simultanous frontend change to avoid downtime. Releasing a patch version of an internal dependency shouldn't require changing the code that consumes it. These types of interdependencies across repositories sugggests fragility in the codebase, which can indicate tech debt or a lack of understanding of how to mitigate the potential issues. The best answer for this is "never," though it might happen occasionally due to unintentional coupling.

Emergency situations

These are questions that I added in direct response to previous experiences. They are not questions I asked, but are questions that, if I had asked, I might have saved myself several extremely stressful months.

How often do you have major outages? What constitutes a major outage for you?

Major outages should be infrequent, by which I mean with several months with no events. Getting on the same page when asking the question is important: if you view a major outage as "the customer can't access the application," but they view it as "the customer can't access for a period greater than 4 hours," their answer might be truthful but against such a different yardstick that it's not helpful to you.

Frequent major outages could indicate code that is tremendously difficult to change, significant numbers of unknowns dependencies in the codebase, large amounts of turnover, huge amounts of tech debt that has not been managed, or several other serious red flags. A software company that can't consistently run its own code is in dire straits.

Do you have a defined process for handling an outage?

A lack of process means that they haven't had enough outages to merit codifying a process around them. For a small company or startup that's still young, a lack of process might well be a good sign--the code has worked reliably so far. For a large company, it might be a red flag depending on how large and established the team is. If they experience periodic outages and don't have any processes in place for how to handle them or prevent them from reoccuring, that is unambiguously a red flag.

Would I be expected to be on-call?

It's up to you whether this is to be expected or an unreasonable request. Developers who write code that imports data from third parties overnight are more likely to have to deal with unexpected breakage at odd hours than web developers. You'll need to talk to your peers and identify whether this is a reasonable expectation.

What does your on-call process look like?

If you've established that you will be expected to be on-call, know what you're getting into! How often, how time off is affected, what sort of response time and escalation process there is. Being on-call is a much larger responsibility that just writing code, so know what you're getting into.

part-3.md

Personal growth

About what fraction of their time are developers given (implicitly or explicitly) the freedom to explore or learn?

To wax poetic for a moment, I like to think about this to put it in perspective: "programming" has only existed in a recognizable form for around 60 years (dating from FORTRAN's introduction on punched cards in 1957). We've only written code (using a keyboard to write human-readable programming languages) for about 50 years. We've been building cars and airplanes for 100 years, buildings and cities for 1000s of years. We're still in the infancy of our field, and there's a lot of exploration and learning left to do.

As developers, we sell our expertise. With how quickly technology progresses--whether it's the tools we use, the languages we write, the libraries we install, or the environments we run in--exploration and learning are necessary to learn about creative solutions to problems we've encountered.

We need to be able to solve problems quickly, and the best way to do that is to have a lot of background knowledge about different ways to approach and solve problems. Learning by reading articles, experimenting within the codebase, or by trying to start a new project will all help you in ways that aren't immediately obvious. Organizations that don't see the value in this freeform exploration will limit your career growth.

How do you define success and growth for your individual developers?

This is an important understanding to have. Many employers would be perfectly happy to define success as hitting all your deadlines, and growth as shortening time between deadlines. There exist companies that enable growth across the stack (frontend/backend/ops), across disciplines (design/engineering/management), or other ways.

Unfortunately being able to define growth for yourself means knowing what you want, and doing some introspection from time to time. A great answer from employers is "to help you achieve your personal goals," but that means that you need to have goals and dreams for yourself!

How often do you do lunch and learns, or other semi-formal knowledge sharing?

Closely related to learning and growth, lunch and learns or other knowledge sharing between engineers can be one of the most valuable parts of a job. Especially as a junior developer, an opportunity to learn from your coworkers' experience can open your eyes to new ideas or tools. At a more mid-level or senior stage of your career, lunch and learns can help you get public speaking experience. Giving technical talks is a great way to level up your career (whether at meetups, conferences, or other venues), and lunch and learns can be a lower stress way to practice.

It's great if somebody in the workplace organizes weekly lunch and learns, but another great answer is "not enough!" Organizing internal events like that can put you in touch with lots of great coworkers, are a great learning experience, and will get you a reputation as somebody who cares enough to get involved.

How often does my potential manager have 1:1s with their reports?

It's generally understood that one-on-ones are a necessary part of effective software management. They provide opportunities to talk about things that aren't directly related to the immediate task at hand, talk about personal goals, and address any concerns you have about your position or future. Not having these one-on-one discussions is a missed opportunity to catch potential problems before they arise.

One-on-ones are often weekly, but I've found that having them too frequently can cause them to become too routine or disruptive. I think the right interval is often enough that you feel heard and know that you'll have a chance to talk, but not so frequently that you get into a habit of having nothing new to talk about.

What kinds of topics are usually discussed in 1:1s?

It's very easy for these one-on-one chats to turn into status updates, but that's not what they should be used for. One-on-ones are too valuable an opportunity for direct contact with your manager for them to become routine updates, they should be a chance to talk about your career growth and future opportunities, talk through any frustrations you're experiencing, and generally get to know each other better.

Do you pay for conferences?

Again relating to learning and growth, professional conferences are great opportunities to meet other developers, learn from speakers, and represent the business. Tickets, flights, and accommodations can be expensive, but it's an opportunity to stay on the cutting edge of new development and bring back knowledge to share with the team.

For companies that pay, I don't think it's uncommon for it to be a reward for performance, or for there to be an expectation that you'll share some of what you learned while there.

part-4.md

Project management and prioritization

How do you balance shipping new features and maintaining the codebase?

There is always a need for this balance. My personal rough estimate is that about 1/3rd of development time is needed for maintenance, whether that's refactoring code that doesn't meet changing requirements, identifying and deleting dead code, improving build or test configuration, or other non-user facing tasks.

Ultimately, I firmly believe that, all told, between a quarter and a third of project time will ultimately be spent on these tasks. That could be 1 out of every 3 days, sprints, months, or years. If you push nothing but features for two years, can you afford to dedicate the next year to the maintenance tasks you've deferred?

It's easy to pay lip service to allocating time for maintenance, but allowing it to happen regularly and be worked to completion–not just until the sprint ends–is another story. This makes it hard to judge their response at face value, so you might need to work around the edges of this question instead of asking it outright. Asking questions about their experience with different kinds of maintenance might allow you to fill out a more reliable answer yourself.

What's the lifecycle of new development, from somebody's idea to deployment?

This is one of the largest deciders of company culture in my mind. How work is planned, coordinated, and communicated from ideation to implementation is the basis for how productive the company is. The clearer the answer to this question, the more likely the company is to have a healthy understanding and respect for the people involved in it.

Many companies operate in silos, with discrete handoffs between teams and very little communication outside of that. The most effective organizations I've worked in have actively encouraged communication outside of these handoffs, involving as many interrelated groups as necessary at each stage in the process. Coordinating many different stakeholders and keeping the discussion productive is difficult, and the most obvious solution of "put everyone in a room and hash it out!" has many pitfalls that can grind progress to a halt.

Unfortunately I don't really know what answer I'd like to hear most from this questions, but I think it's very informative as to how they work, and can serve to raise red flags that they aren't aware of.

How do you track tasks? How are those tasks created?

This is both a question of how detailed their task tracking is (I have yet to work anywhere that tracks time spent per ticket, but this would be a great way to suss that out) and what their process around creating and organizing tasks and tickets is. Ticket creation, grooming, prioritization, assignment, work tracking, determining "done", and handling unplanned work that arises are handled slightly differently by every team, and a lot of places don't give these steps the consideration they're due.

Do you do agile/scrum?

Some people distinguish between "agile" and capital-A "Agile," and "scrum" entails certain defined processes that are aimed at fulfiling the goals of agile. The original agile manifesto was written in 2001, which was distilled into 12 principles. Everywhere I've worked has professed to do agile, and none of them have done it the same way.

In many cases I've found "agile" means doing standups, calling tickets "stories," and excusing chaos as "being responsive to changing requirements." I encourage engineers to familiarize themselves with the agile principles and periodically question if the practices they experience at work live up to them.

Asking whether they do agile should serve as a gateway for asking how more information about their process. Agile principles recommend working as a team to establish a set of practices that work for those individuals with the agile principles and manifesto as the driving force behind it. Agile and scrum are not prescriptive, they're goals and starting points. Each team should expect it to evolve, especially when the team grows or shrinks.

How do you decide what to build?

This can be a good way to get an idea of how much planning is done before starting work, and what level of involvement you as an individual engineer will be able to have. Answers might range from "we get specs and implement them" to "we survey customers to identify pain points."

For large companies that have significant numbers of stakeholders, receiving specs may be perfectly adequate. The smaller the company, the further the answer should move towards being focused on finding and meeting customer needs.

Do you have "swimlanes" in your task tracking? What are they called?

Swimlanes are the columns on a Kanban board, which is frequently used in agile to visualize the status of work. What they're named can be a simple way to get an idea of how the team mentally models the work they do. At its most simple, they might be named, "backlog," "in progress," and "done."

I've found that what works for teams I've been on is having a backlog, in progress, ready to review, ready to test, and delivered.

How do you know when something is done?

There's a classic problem of what constitutes "done" in software teams. "It's done, but it's not, you know, done done." A software developer thinks it's done when the PR is merged, a QA thinks it's done when it's tested, and the business thinks it's done when it's shipped and delivering value.

I recently saw a tweet describing "done," "done done," and "done done done" as a slightly humorous but genuinely helpful description of what these states look like.

https://mobile.twitter.com/Cramtirolf/status/992160079225868288

Having a shared understanding across the team and organization of what "done" means will help avoid misunderstandings around deadlines, and the more clearly their answer communicates that they've thought this through, the better.

What project management software do you use?

This is purely for information gathering. In my career, I've used Pivotal, Asana, Wrike, JIRA, Trello, post-it notes + a whiteboard, printed cards, and likely other schemes I'm forgetting. Getting a sense for how each of these tools model work will help you in your career and prepare you when you're joining a new team.

You'll have to build up a list of what constitutes a wrong answer to this question yourself. Different people enjoy working with different task tracking software. Personally, I find JIRA to be the worst, except for all the others.