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
• The development environment and emergency situations
• Personal growth
• Project management (this one)

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.

I firmly believe that, all told, about a third of project time will 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 What's the lifecycle of new development, from somebody's idea to deployment?

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 several 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 for 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.

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.

Thanks for reading! I hope these questions will help you find a job that makes you happy. 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!