85 Questions To Ask About The Company In An Interview

Illustration by Katerina Limpitsouni

Over the course of my ten year career in software development, I have been in hundreds of interviews, both as the interviewer and interviewee. The same question gets asked at the end of almost every single one: “Do you have any questions for us?”.

Almost every interview ends with this question. Prepare for it. Have an extensive list of questions prepared in advance. More questions than you’ll ever get time to ask. Better yet, write them down or print them off.
– Stevie Buckley, On nailing the interview

You may think you are done being judged, but this is the Bizarro World part of the interview where instead of being evaluated by your answers, you are being evaluated by your questions. I know this is true because I do it as a hiring manager. I’m expecting a good candidate to have questions. Curiosity is a clear indicator of excitement for the position and I want someone who is excited to work with me. The kinds of questions you ask represent the values that are important to you. If you don’t ask anything, it seems like you only care about getting paid.

As a candidate, I know that’s not always the case. There are all kinds of reasons why I might not ask very many questions:

  • I’m exhausted from trying to appear flawless for the last hour.
  • I’m saving my questions until I know if I’m going to get an offer or not.
  • I suddenly forgot what I was going to ask.
  • I think I already know enough (this is never true).
  • I’m afraid my questions will be stupid; either too specific or too vague.
  • I don’t want to take up too much of their time.
  • I need to end this so I can go to the bathroom.
  • I just don’t know what to ask.

But it’s important to always ask some questions because it’s a rare chance to learn what it will be like to work there. Don’t make the mistake of assuming you’ve learned everything you need to know in a couple hours. No one will be offended if you keep asking questions. If they do, you probably don’t want to work there anyway.

Remember, most of us only chat with our boss for one hour before getting the job. Then, your boss becomes one of the most influential people in your life. You are trading the one thing you can’t get more of: your time. Make sure it is appreciated!
– Rodolphe Dutel, How To Hire Your Boss

With the below list, at least you will never run out of questions to ask. As a candidate, it’s equally important for you to figure out if the company is the right fit for you. Note: do not ask all 85 questions at once, in a monotone voice.

Company Culture

  • How long have each of you worked at this company?
  • Tell me about a typical workweek
  • Do you have bouts of “crunch time?”
  • When was your last vacation?
  • What is a bad day here like?
  • Describe the day to day role
  • What are the company’s primary values? What characteristics are you looking for in a candidate in relation to those primary values?
  • What sort of training, mentoring, and career growth assistance is available?
  • What’s the most impressive thing you’ve seen out of someone else you’ve interviewed recently?
  • What do you see as the most challenging aspect of this job?
  • What do you like best working at the company?
  • How do you respond to the negative Glassdoor reviews? (if they have any)

Project Management

  • How are decisions made? How will the team be asked to accomplish things? Who makes those decisions?
  • How do you set milestones/deliverables for projects and how does your team react when it’s clear they won’t be met?
  • Where do requirements come from?
  • How long does a requirement or idea take before it’s ready for the team to work on?
  • How long does it usually take for a development task to make it from “ready for the team” to “in production”?
  • Can you outline the steps in that process? (BA-ing/req gathering/product discovery, grooming, sprint forecast, development work, code review, QA, provisioning, other testing/review, deployment)
  • If you do sprint commitments how often do you hit that goal?
  • Who decides what the team works on?
  • How are development tasks allocated?
  • What is your biggest bottleneck?
  • What tasks need approval or help from outside of the team (manager/ops/security/architects/DBAs/legal)?
  • What percentage of you work is firefighting, maintenance, or new features?
  • How much of you time is in recurring meetings? Do you have any that you don’t think are worth having?
  • What are the big goals for this team over the next year/two quarters?
  • Who are the customers of the team? [internal department, other teams, paying clients, anyone who signs up]
    • How often to team members speak with them?
    • [for internal] What’s the relationship like with that department/teams?

Team Setup

  • Who do you work with on a daily basis?
  • How big are your teams?
  • What roles make up a team?
  • How many of your teams are missing a particular role?

Expectations

  • What would be expected of me for the first three to six months?
  • What will success look like in this position and how will it be measured?
  • Tell me about the last person who had this job
  • What did my predecessor do that was above and beyond?
  • How do you measure engineer productivity?

Development Process

  • What’s your deployment process like?
  • How often do you release to production?
  • What’s your approach to testing?
  • How would you describe the development culture?
  • Do engineers pair-program, or mostly work alone?
  • How long are your sprints?”
  • How widespread is X programming language at the company?
  • Who is responsible for code being declared “production ready”?
  • Who is responsible for deployments?
  • For you personally what is the toughest/slowest/most frustrating part of that process? How would you change it? [Why haven’t you?]
  • Are there any development tasks that are only handled by one person? [eg. only the DBA does SQL, only the lead does X]
  • How do you prioritize tech debt?
  • How involved is the CTO in day to day work? (sprints, tickets, merge requests)
  • Which agile processes do you follow?
  • Do you have sprints? How long are they?
  • Do you do sprint planning?
  • Estimation?
  • Retrospective?
  • How many people are not remote? Is the company remote first?
  • What’s the tech stack?
  • What metrics does the team have on your running system/products?
  • What overlap is there with Ops?
  • What does it take to provision and configure a new server?
  • What tool do you use for code review?
  • How many different codebases?
  • Do you make daily builds?
  • Do you have a bug database?
  • Do you fix bugs before writing new code?
  • Do you have an up-to-date schedule?
  • Do you have user or product owner acceptance testing?
  • Do you have pre-prod testing environments?
  • What’s the process for releasing to production?
  • Do you use feature flags?
  • What is your branching flow?
  • What is your unit test suite like?
  • What is your automated integration test suite like?
  • Do devs work closely with QA?
  • Who would be my direct manager?

Question to Ask Your Potential Manager

  • What is your favorite part about managing a team?
  • How will you evaluate my performance?
  • How available are you? Would we be in the same location/office/desks?
  • How many direct reports do you have?
  • What is your his background? [technical/non-tech]
  • How often do you do 1:1s?

Hopefully this helps you with your next interview! Or if you are a manager or a recruiter, hopefully this helps round out your pitch by answering questions before they need to be asked. Send me your favorite question to ask in the comments or on Twitter!


Further Reading:

My Management Philosophy

Photo by rawpixel on Unsplash

This is the start of my Manager README. If you’re just starting out in management, or looking for help managing a remote team, hopefully my experience can help.

Why should you listen to what I say?

I currently manage the Front-end and QA teams at Measurabl. I recently helped launch Kingston Lane while at Native Axis, a fully remote startup where I was the head of engineering for two and a half years. For over ten years I have been a Front-end Developer and at almost every position I have been the lead developer; responsible for mentoring junior developers, performing code review, defining the tech stack, establishing code design pattens based on best practices, etc.

During my career I have conducted hundreds of technical screens and interviews. I have helped design the hiring process at multiple startups. I have had regular 1:1s with direct reports on a weekly basis for the last three years. I’ve worked with great and terrible managers throughout my career and I’ve learned from all of them.

Lessons Learned

One of the most important lessons I have learned is that software development is 20% coding, 80% communication with other people. Even the code we write is mostly for other developers. The computers break it down into ones and zeros anyway. All of our organization, patterns, and variable names are only for our peers and future selves. The better you can be at communicating through code, pull requests, email, Slack, video chat, and in-person, the more successful you will be.

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.
– Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

What do I value?

When I started at Native Axis, I wanted to create a remote software development company that embraced flexibility and trust in it’s employees to enable huge productivity gains. By removing the physical requirements of being colocated, everyone on the team was able focus on doing their best work instead of being distracted and stressed by commuting and sharing office space.

My philosophy on management aligns very well with how remote companies have to function: on trust. I want to work with people that I can trust.

[Y]ou need to learn to manage by expectations rather than by “butts in seat,” so make sure you can show trust in those you hire.
Wade Foster, CEO of Zapier

My goal as am anager is to enable them to do their best work without micromanagement. I really like how Help Scout prioritizes “players” (relative to management “coaches”) and follows “servant leadership”. This aligns well with how I tend to manage my own teams. I believe it is my job to improve the health and productivity of their team through optimism, empathy, and leverage-based thinking.

Although clear communication is key for any company, I think it’s the most important aspect of a remote company. Without the nuance and context of body language and tone of voice, it’s easy to misread any Slack message. I always assume the best of intentions from everyone else and infuse my communication with optimism to avoid negative conclusions by anyone else.

Empathy is equally important for communication. With every pull request comment I use language like “what do you think about”, “have you tried”, and “you could also” instead of “you should” or “this is wrong”. I think these simple techniques keep people open to receiving feedback.

Leverage-based thinking (thanks for the term Edmond Lau), means focusing on improvements to the development process that allow everyone on the team to iterate faster. These may or may not involve some actual coding. For example:

  • Adding automated unit test coverage thresholds to every build.
  • Upgrading dependencies and picking tools that have quicker build times to remove downtime for developers.
  • Staying on top of blockers and distractions that take developers out of their flow. This translates to scheduling meetings in blocks instead of throughout the day and responding to questions or feedback from QA, product, or upper management so that developers don’t have to.
  • Streamlining CI/CD integration.
  • Adding automatic error tracking (Sentry), type checking (TypeScript), and style guide enforcement (ESLint).
  • Facilitating mob programming (like pair programming, except with the entire team).

How do I deal with different levels of experience?

I have worked with and managed junior engineers fresh from code school, as well as senior engineers with over twenty years of experience. Engineers from either side of that spectrum can be overly confident and inflexible. I would prefer engineers more like myself that are positive, confident but humble, and willing to change their mind or their habits for the betterment of the team and company.

Do I still still code?

Sometimes I do miss being an individual contributor, but I believe that as a manager you have to give up on many of the “fun” projects to allow your team to enjoy their work and learn from those new experiences. I also do several things to stay close to the code. For one, I review every pull request, so that I’m up to date on the codebase and can share my knowledge with the rest of the team on a daily basis. When I do have time to code, I tend to focus on changes that will boost productivity for the entire team (see “leverage-based thinking” above).