By: Joy Ebertz
This article was originally posted by The Muse. Read the full story here: https://www.themuse.com/advice/software-engineer-questions-to-ask-interview-find-the-right-fit
When you’re looking for a new job, it’s obvious that the company is interviewing you. It can be harder to remember that you’re also interviewing the company to see if the role, the team, and the organization as a whole are the right fit for you. After all, the last thing you want is to spend a couple of years stuck in a job you wish you’d never taken.
And you can and should be picky: As an engineer, you have skills that are in high demand. It seems like everyone in the tech industry is hiring—and software is expanding into many other industries, too. That’s all the more reason to make sure you’re screening and evaluating companies based on fit.
But how do you actually do that? If you’re a programmer embarking on a job search, what questions should you ask to figure out if a company and role are a good fit? As a senior staff software engineer who has also spent some time as a hiring manager and interviewed many times on both side of the fence, I’ve given some thought to it.
While the exact qualities you’re prioritizing and looking for will vary depending on what you value and on your working style, there are a few questions that can be especially revealing.
- What Does the Team Look Like?
- What Are Your Expectations for the Person in This Role?
- What’s Your Tech Stack and What Development Tools Do You Use?
- How Are Design Decisions Made? And If There Are Conflicts, How Are Those Conflicts Resolved?
- How Are Projects Prioritized and Planned?
- What Are the Biggest Challenges Facing Your Team?
- What Is Your Diversity and Inclusion Strategy?
1. What Does the Team Look Like?
Because you’ll be working most closely with your team, those people will have the biggest impact on your experience at the company. So you’ll probably want to have a sense of what the team looks like. How many people are there? What are their roles? How do they interact? Some people thrive on larger teams while others do best on much smaller teams; some people like the context that working closely with people on other teams brings while others find it more distracting than helpful.
Asking about the size and structure of your potential team and learning about its day-to-day functioning can tell you something about how cross-collaborative the team is, what the seniority of its members is, and how job responsibilities are distributed. Does the team work a lot with product management or NOC (the network operations center)? Are those functions considered to be part of the team? Is there a separate Ops team or is the team practicing devOps? Does the team have insight into customer concerns or input into product features? How is the manager involved with the team? Are there senior team members to learn from or junior people to mentor?
There’s a lot to unpack here, but the answers can reveal whether there are opportunities to learn the things you want to learn—such as how to keep a server running or how to run a usability test—and they can give you a sense of what the team dynamic will be.
You may have a very clear image of what you’re looking for in a team, but if you’re struggling to figure out exactly what’s important to you, think about past experiences and what you loved or found frustrating about them. The patterns you see will help you identify your priorities.
2. What Are Your Expectations for the Person in This Role?
While this can reveal interesting information at any level and for any kind of role, it’s especially important for higher-level engineers. Entry-level software positions typically look similar across companies and titles and bands are consistent. However, at higher levels, there tends to be a lot more variation.
For example, a senior staff software engineer job at two different companies can come with completely different sets of expectations. When I was recently interviewing for roles with this title, I found that some companies expected me to be on a small scrum team and spend all of my time coding while others expected me to spend a large percentage (in at least one case, more than half) of my time mentoring, speaking, or working cross-functionally. Some hoped to leverage particular knowledge I already had while others wanted to leverage more general design thinking or leadership experience. None of these are bad, but they might not be what you’re looking for.
It’s also important to find out if a company will offer growth opportunities in the areas you want to focus on. For example, if they want you to leverage your deep knowledge of Java but you want to learn a new programming language, you’re going to have problems. If, however, they want to leverage your knowledge of API design while still allowing you to learn a new language, that might be a good fit.
3. What’s Your Tech Stack and What Development Tools Do You Use?
Many engineers care a lot about the tech stack they work in and the tools they’ll be using. If you’re one of them, you should definitely ask this question and make sure the answers align with your preferences. I’ve personally never cared too much about the exact languages or development tools a company uses, but I still find them useful to ask about because these questions can also reveal the company’s approach to code and projects more broadly.
For example, when I was interviewing recently, I discovered that one of the companies I was talking to was using a cutting-edge programming language. Using brand-new technologies can be an opportunity to become an expert and help shape the direction that technology takes industry-wide. However, it can also mean surprise bugs that take weeks or months to unearth and a lack of community support.
What development tools a company is using can also be informative. Are they picking best of breed or cheaper alternatives? Are they trying to build everything in-house? Are they missing key elements? For example, do they seem to skimp on or lack monitoring tools? If they aren’t following industry best practices, that might be a red flag—or you could see it as an opportunity for you to introduce those practices. Influencing an engineering culture in a positive way is often a good way to get promoted, but it can also be a lot of work, or in some cases, an unwinnable battle.
Natalia Vinnik, Senior Engineering Manager at Google, likes to ask specifically about code review tools. She’s not tied to a specific tool, but rather she’s trying to see if there’s a culture around code and design reviews. First of all, is there a code review tool? And do they gate production changes?
“It tells a lot about eng culture,” she says. For example, it can tell you “if people are open to get feedback from each other or if it’s more about implementation and [code] doesn’t matter as long as it works.” Companies that have a strong culture of feedback on code are often more open to feedback in other areas.
4. How Are Design Decisions Made? And If There Are Conflicts, How Are Those Conflicts Resolved?
Some companies are very collaborative and others are very hierarchical; some have strict processes and others are more fluid. Asking about design decisions is a great way to learn which ways a company leans. Plus, design discussions are one of the places where conflict is most likely to arise, so understanding how those conflicts are resolved can help you get a sense of the overall working style at an organization.
Does the team plan designs in collaborative sessions or does one engineer go off and write a design document? Who is in charge of various designs? Is it always a single tech lead or is responsibility shared, with different team members playing the lead role for different projects? Is feedback discussed in group meetings, one-on-one sessions, emails, or not at all? (It can be a problem if there’s no chance to give feedback.) If there are disagreements, does the lead engineer make the decision or the manager or the group with a vote?
If you’re like me, one of the things you like most about software is having a say in design and other technical decisions, which may not be a possibility if you’re more junior and the company is very hierarchical. However, the other extreme can be a red flag too—I’ve seen companies where very little gets done because the culture is so collaborative that you need to get everyone to agree on each little detail before moving forward.
There’s no correct answer here, just one that appeals to your preferences. The exact balance that works best for you may depend on how much you enjoy being involved in design in the first place, how much structure and instruction you prefer, how willing you are to speak up and voice your opinion, and how adept you are at influencing others.
5. How Are Projects Prioritized and Planned?
Understanding how a company picks which projects to put its resources toward and how it goes about bringing those projects to fruition can tell you a lot about what’s important there—both in terms of products and in terms of engineering values. For example, is the company prioritizing tech debt or only focusing on new features? Are they able to focus on doing a few things well or do they try to do a little bit of everything? Are they building things to last or are they over-engineering?
But that’s not the only reason to ask this question. The answer can also indicate how much influence you, as an individual engineer, might have. If you have a great idea, what would it take to make it a reality? Is there a lot of red tape or would you have a good amount of freedom to test things out? If they mention holding hackathons and actually implementing features inspired by hacks, for example, it can indicate an openness to ideas coming from anywhere.
This question can also give good insight into how nimble and fast moving the company really is. Every software company I’ve ever talked to has claimed to practice Agile (almost all Scrum). However, some of them are actually mostly using the Waterfall methodology with a facade of Agile. Some people thrive better in a truly Agile environment where they are constantly making adjustments and pivoting, but others do better with more predictability and longer time horizons. Digging into what processes actually look like—rather than going solely by terminology that may not reflect reality—can ensure that you find the right fit for you.
6. What Are the Biggest Challenges Facing Your Team?
I like to leave this question open-ended since I think it’s interesting to see if people pick something technical, cultural, or process related. Regardless, the answer can tell you a lot about team culture and can give you insight into what you might be working on.
Are the challenges they bring up something you’re excited to try to fix or at least willing to work with? Samantha Paras, Engineering Tech Lead at DataFox, also likes to ask this to gauge if one of the challenges mentioned is an area that she feels like she can contribute to. Knowing that she can make an impact makes her much more excited about a company.
Are there challenges? If a team isn’t trying to improve anything, that can indicate apathy or little room for growth on the team. Does everyone on the team reference the same challenge? Consistency can mean good self-awareness across the team (or alternately, a serious problem). Do they seem optimistic about finding a solution?
When I was interviewing at one company, every single person I talked to referenced their design and decision making process being cumbersome and slow. While I obviously wouldn’t want to deal with that, the fact that everyone noticed the problem and wanted it fixed made it seem likely to be addressed quickly. Several of them also referenced discussions they were already having around changing that process.
A good follow-up question might be, “How easy is it to make changes?” or “How empowered do you feel to solve that challenge?” Too much change can be bad, but it’s also a bad sign if it’s impossible to course correct or confront challenges.
Vinnik likes to ask a slightly different question: “What keeps you up at night?” But she’s looking for the same sort of information. “I like to know what real technical and [organizational] challenges the company faces and how they think about [them]. I look for transparency and how they approach challenges,” she says. “If they only talk about working a lot and being paged a lot without thinking about fundamental changes that can help, it’s a red flag. If they say there are no challenges or something vague it’s a yellow flag.”
7. What Is Your Diversity and Inclusion Strategy?
The tech industry (and software engineering in particular) really struggles with diversity and inclusion—despite the fact that research has shown that diversity improves performance.
Paras always wants to make sure that a company isn’t just looking to hire a diverse group, which is often the easier and more obvious thing, but is also working to make their culture more inclusive. Inclusion efforts might mean supporting employee resource groups, educating leaders, and fostering company values around celebrating differences. Paras also points out that with diversity and inclusion, grassroots efforts alone aren’t enough, so it’s important to find out if and how leadership supports the efforts.
You’d be hard-pressed to find a software company with perfect diversity numbers, so you’re not necessarily looking for them to have everything figured out. Instead, you’re trying to gauge how they respond to a longstanding problem, if they’re even willing to admit they have one. I find it extremely telling to see if a company tries to put a positive spin on something negative or if they admit they have work to do. I also like to see how much thought and effort they’ve put toward doing better. Are they trying creative solutions? Are they using data to inform their efforts? Are they actually working to fix the issue or are they complacent and giving excuses? (Read more about how to tell if a company’s walking the walk on diversity and inclusion here.)
The answer might tell you more about the company than just its D&I strategy. How a company approaches this very challenging problem can be indicative of how they approach other complicated issues and how transparent they tend to be. Do they face obstacles head-on and strive for constant improvement even when it’s hard or do they just push things under the rug?
With most of these questions, there isn’t a general right or wrong answer. It’s all about finding the place that sounds perfect to you. Do you thrive with consistency or chaos? Do you work well under pressure or do you shut down? Do you get excited about working with brand-new technologies or do you get tired even contemplating it?
Almost every company you’ll talk to leaves at least five minutes at the end of each interview for you to ask any questions you have. Use that time wisely. Your job is a big part of your life, so it’s worth taking the time to ensure the one you’re accepting is the best possible fit for you.
