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?


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

Front-End Engineer / Developer Interview Questions

Throughout my career, I have interviewed lots of front-end developers, possibly in the hundreds. Below are some of my favorite questions to ask and why. Most of these have been taken from this excellent GitHub repo. These are pretty basic concepts, but you can adjust your expectations and follow up questions based on the experience you need for the role. These can be all be asked in about 20 minutes (perfect for a phone screen).

Warm Up

  • Tell me about the last project you worked on.
    I have their resume, so I don’t need their entire career history. I’d rather hear about what they have been doing most recently.
  • Which part are you most proud of?
    This usually gets people to talk about the specific parts they built rather than the overall project. It’s also a positive way to start the interview.
  • What would you do differently next time?
    Hopefully candidates will have learned something since they started their most recent project and would like to apply that to their next one. I like to hear how pragmatic they can be about choices that may have seemed correct at the time and only look bad in hindsight.


  • What is CSS selector specificity and how does it work?
    It is amazing how many senior level front-end engineers cannot answer this correctly. Really I’m just looking for someone to talk about how an ID is more specific than a class, or that the ordering of style definitions matters, or how you can add more selectors to get more specific. I often follow up with a specific example, like if you have two styles that change the color of the text, but one is an ID and one is a class, which one will take precedence? Sometimes this helps people understand the initial question more but sometimes it just proves how much they depend on Twitter Bootstrap to do all the styling for them.
  • What’s the difference between display: inline and display: block?
    To me this is very basic, but again I’m amazed how many people struggle to define this. If someone can’t remember or isn’t understanding the question, I usually follow up with an easier question: can you name some HTML tags that are inline by default? If they struggle with that, then I’ll ask if they think a <span> is inline or block.


  • Compare and contrast Angular with React.
    I will replace React with Vue/Backbone/Ember based on their experience. The goal is to find out how much time they’ve spent working with multiple libraries and learning the pros/cons and best use cases of each. This is also a good way to find out if someone is too dogmatic about any one particular framework.
  • What is the difference between “==” and “===”?
    Few people miss this one. It’s pretty basic, but it’s always nice to have people mention type conversion and get a small win, especially if they’ve been failing the CSS questions.
  • What are the differences between variables created using “var”, “let”, and “const”?
    I usually ask this if I’ve seen them mention ES6 on their resume. If not I will first ask them if they’ve used ES6. Even if someone has not used ES6 yet, I would hope they’ve at least heard of “let” and “const”.
  • Describe event bubbling.
    Many people get this confused with the event loop, or something else that they struggle to describe. I know React, Angular, and even jQuery to some extent have removed the need to deal with event bubbling and the weird side effects it can cause. But I like when people are at least aware of the concept. If they can talk intelligently about it, they obviously have a decent understanding of the DOM as well.
  • Explain how (the keyword) “this” works in JavaScript.
    Most people inherently get this (pun intended) and use it all the time, but it’s a difficult concept to verbalize. I think being able to describe programming concepts to other people is just as important as knowing them.


  • What tools would you use to test your code’s functionality?
    Not everyone writes unit tests. But almost everyone says they do. An easy way to see if they are bullshitting is to ask them to name their favorite tools. Hopefully they quickly respond with Mocha, Karma, QUnit, or something similar. If it sounds like they know what they are talking about I might delve deeper and see how passionate they are about TDD or code coverage.
  • What is the purpose of a code style linting tool?
    More recently I have simply asked: “Do you lint?”, but the end result is the same. People either use a linting tool and understand it’s purpose or they don’t. I personally would not want to work with someone who did not use a linting tool on a regular basis, but obviously there are people who do not.


  • Explain what a single page app is and how to make one SEO-friendly.
    These are great to see how well a person is able to communicate concepts like SPAs and how well they actually understand how they work and what their shortcomings are. Not everyone has done SEO optimization for their job, but I expect every mid to senior level engineer to at least know where to start. I expect them to mention meta tags, server-side rendering, semantic links, etc.
  • Name 3 ways to decrease page load (perceived or actual load time).
    This one is kind of a gimme, but it’s telling if a person rattles off a bunch or they just barely get to three. Much like SEO, I don’t expect everyone to have experience with performance optimization, but they should know the basics. Answers like “compress your images” or “caching” are fine, but I’m hoping a candidate will talk about minifying, gzip, code splitting, or other more advanced techniques.
  • What does CORS stand for and what issue does it address?
    Please at least say “Cross Origin” and mention “security” and you’ll get a pass. I have definitely heard candidates that say “oh yeah I work with this all the time” but then can’t describe why it exists. It’s one of those things that they just do, but they don’t know why.
  • Describe the difference between a cookie, sessionStorage and localStorage.
    Most people struggle with at least one of these. Cookies are a given, but depending on whether your experience is more back-end or more mobile, you may have never worked with session or local storage. But again, I’m hoping senior level candidates are at least aware of them as concepts and can describe what they are at a high level.

Hopefully these are helpful for anyone else who is interviewing front-end candidates or someone who is a front-end candidate. This is not an exhaustive list of everyone question I can or would ask, but it’s a good place to start. I will usually follow these up with a coding project and a more culture based interview with the rest of the team.

What I’ve Been Working On (Ionic and Angular Resources)

As you can see by my stale timeline, I haven’t updated this blog in awhile. I’ve been busy building the HomDNA app for iOS and Android using Cordova, Ionic, and Angular. Here’s what I’ve learned (more detailed posts to come):

AngularJS Architecture

AngularJS Plugins

AngularJS Optimizations

AngularJS Unit Testing

Cordova Plugins

Build Process with Gulp

Install Homebrew for OS X

After more than a decade of Windows use, I finally made the switch to an Apple. I started using a Macbook Pro at Rapid7 last year and although I was mostly using Ubuntu in a VM, I got addicted to the simplicity and power of these sleek machines. Since I had to give the company property back when I switched jobs, I had to buy my own. I figured it was a good investment, since I work from home.

One of the first things I did, in order to easily download applications like Node.js, MongoDB, etc. was to install Homebrew, the Mac version of apt-get (package manager). Here’s how to do it:

Open a terminal (use spotlight search to find it) and enter:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

from http://brew.sh/

Choosing a JavaScript Framework

I’ve been trying to convert IPOFest (a pet project started by Kyle and I) from all PHP to JavaScript that interfaces with a PHP API. At work we use Backbone.js and since I had never used it before, I practiced on IPOFest. First I started with Backbone and Knockout.js, with Knockback.js as a bridge. I didn’t go too far down that path, but it did feel a bit awkward and the Knockback documentation didn’t help very much. At work we use Handlebars for templates, so I started changing over to that. Continue reading

My Interview with the Los Angeles Lakers

I could have been sitting courtside, rubbing shoulders with Jack Nicholson and listening to bad Kobe Bryant jokes… okay more like editing bad photos of Kobe while sitting at a desk in El Segundo, miles away from every home Laker game. Still, ever since I realized that Lakers.com existed, I’ve considered it the white whale of webmaster jobs. I had no idea how much they paid, how much work was involved, or even where their offices were. I just knew that my passion for web development would be in perfect synergy with my passion for the Lakers, in a perfect union.

Well, recently, I had my chance at that job. Continue reading