Questions to Ask when Applying for a Software Engineering Job

Posted on March 26, 2017

I've been working as a software engineer, primarily focused on front-end development, for a few years now. I recently started a new job as a senior front-end engineer at a company called Omada Health. During my job search, I spent a lot of time trying to figure out the most important questions to ask when applying for a software engineering job. I was looking for somewhere that would facilitate my growth, where I could make an impact, and where I would enjoy my work. So far, I believe I've found a company that meets these qualifications and then some. In this post, I want to present some of the questions I asked during the interview process that helped me make the decision to choose Omada. These questions are roughly divided into categories including company info, people and processes, product, and engineering. I think they represent a good baseline of the info a software engineer needs to decide on a new position. I'll go through each of these categories and explain their questions.

First Contact

What product(s) do you build with web technologies?
About how many people are currently using your product?
What's your front end stack?
What's your back end stack?
How many employees does your company have?
How many engineers does your company have?
What are your main sources of revenue?
Do you have investors? Who are they?
What are the stages of your interview process?

To be respectful of people's time, I didn't try to get all my questions answered in a single conversation, particularly not in my first contact with a recruiter or engineering manager. So I focused on getting just the essential basic info on a company that I needed to decide if I was interested. In particular, I wanted to know about their product, the technologies they use, how big the company is, and what going through their interview process would be like. I value working at a company whose product is one I think makes an important difference in the world and would be fun to work on, that uses technologies I want to learn and think will be valuable to my career, that is at a size I'll find comfortable, and whose interview process is one that fits my timeline. In my last job search, company size was particularly important to me, as I was looking for a smaller company (compared to where I was at LinkedIn).

The Company

What is your company's vision?
How large is your company's potential market?
What are the biggest challenges your company faces?
Who are your company's biggest competitors?
What's your growth been like over the last few years?
Where do you see your company in a few years?
Open source projects?

After gathering some initial info and deciding I'm interested in learning more about a company, I ask these questions to learn more about how a company wishes to impact the world, how successful they think they currently are in their market, and how successful they hope to be. With these questions, I'm looking to determine if the company's mission is one I can get behind and if I can have confidence that the company is and will continue to be successful.

I also throw in a quick question about open source, as I value a company that puts their technical solutions out there. It gives me a chance to take a look at the kind of code their engineers produce.

People and Processes

What is your process for onboarding a new engineer?
What is the average size of a team?
How is a typical team structured?
How often and with what methods do you evaluate performance?
How do you track issues?
What project management strategies are popular with your teams?
Do engineers participate in interviewing other engineers, and if so, how?
How many hours a week do engineers usually work?
How often do engineers need to work extra hours?
How do you help your engineers learn and grow?
How often do you send engineers to conferences?

Next I delve into how the company deals with the people it employs, particularly engineers. When I'm in the market for a new job, I look for places that take engineer onboarding seriously, that keep team sizes from growing unreasonably large, and that follow a standard process for evaluating performance (ideally with some inclusion of peer feedback and less or no focus on ineffective metrics like number of tickets closed). I also want to know how teams are structured (I prefer cross-functional teams where I'm working closely with designers, data scientists, and product managers), how teams keep track of work, and how they manage projects. Usually, I look for a company takes what works for them from Agile methodologies and doesn't mandate strict adherence to a particular approach. I also ask about how the company utilizes its engineers in the interviewing process for new engineers, as interviewing, both as the interviewer and the interviewee, is itself a skill-set I want to continue to develop.

Finally, I ask the company to be up-front with me about the frequency of and circumstances influencing when I may have to work overtime, as balancing work with family is important to me, and I check to see if they support engineers' learning and growth through things like internal tech talks, mentorship, and conference attendance.

Product

How do you decide on going forward with a major new feature or change?
How do you handle the release of a major new feature or change?
After releasing a major new feature or change, how do you determine if it was a good idea?
How do you approach quality assurance?
How do you ensure consistency across your UIs?
How do you approach internationalization and localization?
How do you find out how users are using your products?
How do you ensure your products are accessible?

As a front-end engineer, my work usually centers around building effective user interfaces for a product. So in addition to learning about a company's particular product, I seek out info on how they manage their product's development. I focus heavily on how they make decisions about how to change or add to their product, as well as how they evaluate the effectiveness of those changes. I favor companies that use a data-driven approach, ideally getting feedback from users as early as possible via user research and then measuring a change's effect on users via A/B testing and other experimentation methods.

When it comes to UI development, I look for companies that strive for consistency in their designs by using styleguides and pattern libraries and that put effort into making their UIs accessible to people with disabilities. I also look for companies that have adopted a vigorous approach to quality assurance. If a company's product supports multiple languages and locales, I ask about how they handle internationalizing and localizing their UIs.

Engineering

How do you develop code locally?
What version control systems do you use?
How do you test your code?
What's your code deploy process?
How often do you deploy to production?
What do you do when a bug makes it into production?
How do you ensure quality, consistency, best practices, and good design in your codebase?
How do you document your code?
How do you manage code ownership?
How do you distribute reusable code internally?
How long have you been using your current stack?
Do you face challenges related to legacy code, and if so, how to do you approach dealing with them?
What tools do you provide for your engineers to make them productive?
How do you keep your use of CSS maintainable?
What's your browser support policy?
How do you do cross-browser testing?

I go into the most detail when it comes to engineering questions, as these details will have the most impact on my day-to-day work. I want to know how development works at the company, particularly how code gets developed on an engineer's local machine and then how it moves through a deployment system to production. I'm looking for a process that involves writing tests for code, running those tests in a continuous integration system, and frequently deploying to production. I also ask about the "unhappy path" for things like bugs making it into production and how they handle those problems.

I explore a company's processes and attitudes around code quality. I want to get a feeling for if I'll be entering a well-designed and maintained codebase or one that suffers from inconsistency and use of anti-patterns. So I ask about how a company facilitates the design and implementation of high quality code, looking for things like formal code review or pair programming, adherence to a coding styleguide, use of automated linting, and formal technical design reviews. I also look for a serious approach to technical documentation that favors using docs for high-level knowledge while leaving low-level in self-documenting code.

Other areas I ask about include the tooling they have in place to facilitate developer productivity, how they distribute reusable code between projects, and whether they have a significant amount of legacy code and how they approach dealing with it. Ideally, I want to work at places where they use tooling and automation to scale engineering productivity, where code reuse is a first-class concern, and where legacy code and technical debt are handled proactively and consistently.

Finally, as a front-end engineer, I also ask about CSS architecture (if they got this wrong, working on their front-end could be a nightmare), what browsers they support (mostly looking for if I'd have to help support really old Internet Explorer versions), and how they approach cross-browser testing of their application.

Overall, I want to work at a place that approaches software engineering deliberately, setting up processes that support efficiency and effectiveness while also maintaining a culture that constantly questions that status quo and seeks to optimize itself more and more through adding, modifying, or replacing development processes.

Conclusion

So there you have the list of questions that informs the criteria I use to evaluate a company and software engineering position. Perhaps the next time you're on the job hunt, asking some of these questions will help you get the info you need to make an optimally informed decision about where to pursue your next opportunity.