Seven Must-Ask Questions and Red Flag Answers for Your Next Software Engineering Job

Ok, you’ve done it — you got a software engineering offer from a company. The compensation package is good, the benefits are solid, and you get along with your manager (at least, so far). What now?

I’ve been in this position several times in my career. After working at these companies for several years, there are definitely some aspects I wish I had known about before signing the offer. I’m skipping some of the more obvious ones that are probably documented in your offer letter, like “How much vacation can I take?” or “Is there an annual bonus?” These are questions you should ask your recruiter if you can’t find the answers to.

This list is by no means exhaustive (I’ve included a list of more questions at the bottom of the article). These are questions I found to be high signal in assessing whether I should join this company.

First, who should you be talking to?

Your manager (or the hiring manager) may be an obvious choice, but they may not be as connected to the day-to-day work you’ll be doing (and if they’re really focused on getting you to sign, they may sugarcoat their answers a bit). To get closer to your direct “peers”, try to find others who are similar to you in role and scope. For example, if you’re an individual contributor, find other engineers in the same role. If you’re an engineering manager, try talking to managers on adjacent teams.

I’d normally ask my future manager to connect me to two or three of my peers for informational calls.

The questions

Here are a list of questions I’d definitely ask my future employer before I sign the offer, along with red flags (obvious warning signs) that would make me reconsider. These aren’t real answers I’ve gotten, and I’m exaggerating them a bit for dramatic effect, but hopefully they help you understand what I’d actively avoid in my next job. The answers you’re looking for also vary a bit depending on whether you’re talking to a 3-person seed-stage startup, or a Google/Amazon/Facebook (or anything in-between).

How’s the on-call load?

🚩 “It’s bad. I’ve had to work the entire weekend and I get paged throughout the night for alerts that I can’t even do anything about.”

I break this question down into two parts:

How busy is on-call?
How often do you go on-call?

I ask this to gauge the strength of a company’s engineering and operational processes. For example, if a severe incident occurs, can someone who isn’t the immediate owner of that domain know how to resolve the issue? Are there written runbooks on how to handle these problems, and is there an easy way to escalate the issue if needed? Are alerts actually actionable, e.g. if you’re being woken up at 4am, is it clear why, or is it a flaky alert that resolves itself by the time you’re at your computer?

On-call is a fact of life for most engineering teams; you want to confirm you aren’t signing up for a team that’s constantly in a state of emergency (or if you were willingly looking for this, then props to you, I hope they’re paying you a boatload).

What will my first week look like?

🚩 “You’ll immediately be put on a high-urgency project; we need all the help we can get right now.”

I ask this to tease out a company’s onboarding process. Is there a structured format to the onboarding process, or are engineers meant to come in and start fixing problems immediately and learning through hands-on work? Is there going to be a well-scoped project waiting for me to help me get familiar with the codebase and development practices, or are those standards not defined? Will you have a “buddy” you can ask questions to?

It takes time to build trust with your teammates and to gain familiarity with how to navigate a company, so I consider throwing a new hire into the fire immediately a red flag (maybe this is the case for three-person startups, which makes a bit more sense since no one has the time to create an “onboarding checklist”).

What’s your least favorite part of working here?

Pay close attention to how your coworkers respond to this question.

🚩 “My manager. They don’t listen to me.”

🚩 “My teammates. Some people don’t belong here.”

🚩 “The company isn’t doing well financially, so there isn’t a bonus this year.”

🚩 “I never know what’s going on; everything happens behind closed doors and internal communications are lacking.”

This is like a “Tell me your greatest weakness” situation; they should acknowledge the problem and be actively working on it or have plans to address it. Reasonable answers might include:

“The people are too kind, so receiving direct feedback can be difficult.”
“Sometimes organizational changes cause a lot of disruption, making it hard to focus on work.”
“The salary could be higher.”

What’s your favorite part of working here?

🚩 “The free food is really good.”

The above isn’t a bad thing by any means, but I’d hope my coworkers have more substantial things they like about the company, such as “The work is really interesting”, “My managers are incredibly supportive”, “The mission of the company aligns with what I’m looking for.”

If your coworker has more experience and has worked at multiple companies, it can be helpful to ask them to compare their experience at the current company to their past ones. For example, you could ask, “You worked at Facebook before; how do the development tools at compare?”

How many hours do you normally work each day?

🚩 “I work weekends regularly because 9AM -5PM isn’t enough time for my to get my work done.”

I know the hustle-lovers of the internet might say the second answer isn’t necessarily a bad thing; I agree. To get a better understanding of the situation, I’d use follow-up questions to determine if the future coworker is working extra hours because they are engaged by the work and want to, or if it’s due to poor prioritization, slow development velocity, or overaggressive timelines.

The most common answer I’ve received is “It varies”. Emergencies and tight deadlines do occur, and it’s understandable to have to work longer hours during those rare instances. On the other hand, there may be periods of time with less work, allowing for fewer hours.

Walk me through a project you’re proud of from working here.

🚩 “I don’t have any.”

The obvious bad answer here is that they don’t have anything to share, but there are more subtle clues around how they deliver the story. Can you assess if the people involved were truly motivated by this kind of work, and if there are ways to recreate a similar environment for future projects?

I also use this to assess the technical ability of my team and to get a sense of the type of projects I might be working on as well. Does my teammate know what they’re talking about, can they communicate clearly, and does the work actually have an impact on the company?

How is attrition on the team?

🚩 “No one on the team has lasted more than a year.”

There is probably something seriously wrong with a company that cannot retain its employees for more than a year at a time. Dig into why people are leaving.

On the other hand, if team tenure is distributed evenly, that’s a good sign. The long-time team members are likely still engaged in the work and helping mentor newer engineers, while the mid-timers don’t find the old-timers too unpleasant.

Bonus: If people stay beyond the four-year mark, that indicates they are either very interested in the work or the stock refreshers are attractive. It’s also a good sign if there are internal transfers from other teams into the one you’d be working on; your team is likely working on a high-priority domain or has a good reputation within the company.

I want more questions!

Here are some other question lists I found that are useful too:

For more articles like this, follow me on Medium. Not a member yet? Join the community. Want more software engineering interview guides and coding question tips? Check out all of my writing organized by topic in this article.

If you have any requests for what I should write, please let me know!