Skip to content
On this page
Person asking questions

Questions for the Company

Prepare these in advance

Questions for the company are critical. They show the company that you're prepared and interested in them. But, even more importantly, they can help you suss out whether a company is right for you.

When to ask questions

Hopefully every interviewer with whom you speak will give you a chance to ask questions. Often, this comes at the end of an interview session. This is a great opportunity to learn about the company and whether you would want to work there. Definitely have at least a few questions for each interviewer, even if you ask the same questions to a couple different interviewers. From their perspective, it's a red flag when a candidate doesn't have any questions (how interested could this candidate be?).

What to ask

Questions to ask can range from general, process-related questions to more domain-specific questions. Some example questions I tend to ask as a web app engineer include:

  • How is the project managed? Agile, waterfall, agilefall, Kanban? I personally like agile better because I think it reduces project risk.
  • What does the lifecycle of a new feature look like? What does the lifecycle of a bug look like? These questions try to determine if the company has reasonable ways features are determined and what phases a feature goes through to get to production. Likewise, I try to determine what kind of vetting bugs go through and how they're prioritized. In this question I also try to determine whether the project uses modern practices like automated testing and continuous integration.
  • How often do you ship code to production? I'm a fan of shipping constantly since it reduces the pressure on any one deployment and also makes deployment more trivial. Of course, this isn't always possible, but it's good to understand what this looks like for your prospective project.
  • What's something interesting you worked on recently? For fellow engineers, I'm curious what tasks they did recently that were interesting. There's no right or wrong answer, but it might give you a sense of the work.
  • What are your biggest challenges right now? This question is always interesting because you get answers that range from difficult business challenges to areas of technical debt.
  • What kind of technical debt does the codebase have? I usually preface this question by saying "I know that every project has technical debt of some kind." It helps show you're pragmatic and their answers will give you a hint about what kind of challenges you might face on the project.

Outcomes

I aim to leave the "questions for the interviewer" part of the interview with two outcomes:

  • The interviewer thinks "wow, this candidate is really interested in this job" and -x I have enough information to actually make that determination.