I spent three years at a startup where the “culture” was essentially just a collection of expensive beanbags and a Slack channel that never stopped pinging. During the interview, they talked endlessly about their “agile transformation” and their “cutting-edge microservices architecture,” but nobody mentioned the fact that the senior architect was on call every single weekend. If you want to know how to spot a bad engineering culture in an interview, stop listening to the recruiter’s rehearsed lines about innovation. They’ll sell you on the tech stack, but they won’t tell you about the unwritten rules that govern how people actually behave when the production database starts melting down at midnight.
I’m not here to give you a list of personality tests or psychological tricks. I’ve spent fifteen years being the person who has to fix the mess, and I’ve learned that the real red flags are usually hidden in the mundane details of how a team handles failure. In this post, I’m going to share the specific, uncomfortable questions you should be asking to see if a company actually values its engineers, or if they just view you as a way to ship features until you burn out.
Table of Contents
Asking the Right Software Engineer Interview Questions for Culture Fit
When you’re sitting across from a hiring manager, avoid the trap of asking “Do you value work-life balance?” They’ll say yes, and they’ll be telling the truth as they see it, which is usually a lie. Instead, pivot to the mechanics of how they handle failure. I’ve found that the best software engineer interview questions for culture fit are actually questions about the last time things went sideways. Ask them: “Walk me through the last major production outage. Who was involved in the post-mortem, and was anyone reprimanded?” If the answer focuses on finding a person to blame rather than a flaw in the system, you aren’t looking at a healthy team; you’re looking at a minefield.
You also want to probe for technical debt and engineering excellence signals without sounding like you’re judging their codebase. Don’t ask if they have debt—every company does. Ask how they decide when to stop shipping new features to fix the foundation. If they can’t give you a concrete answer about how they allocate time for refactoring or addressing technical debt, you’re likely walking into a cycle of constant firefighting. This is often where the most subtle toxic engineering management signs hide: in the quiet assumption that “we’ll fix it later,” a “later” that never actually arrives.
Technical Debt and Engineering Excellence Signals You Cant Ignore
When you’re sitting there, they’ll likely try to sell you on their “fast-paced environment” or their “cutting-edge stack.” Ignore the marketing. Instead, try to get a sense of how they actually treat their codebase. Ask how they decide when to stop shipping features and start fixing the mess underneath. If the answer is a vague “we manage it as we go,” that’s a red flag. That usually means they don’t manage it at all, and you’ll eventually become the person spending your weekends fighting fires caused by three-year-old shortcuts. Tracking technical debt and engineering excellence signals is much more telling than any LeetCode puzzle; you want to know if they have a budget for refactoring or if “quality” is just a word they put on a slide deck.
I’ve also learned to look for the scars. Ask them about the last time they had to perform a major migration or a significant architectural change. If they can’t tell you about a time things went sideways, or if they blame a “rogue developer” for the failure, you’re looking at a lack of psychological safety. In a healthy shop, a botched deployment is a systemic failure to be studied, not a person to be punished. If they can’t talk about mistakes without pointing fingers, you aren’t joining a team; you’re joining a blame game.
The subtle tells that your next job will be a series of long nights
- Ask about their on-call rotation and how they handle handovers. If the answer is “we just hope for the best” or “it’s a bit chaotic,” run. A healthy team treats on-call like a shared burden with clear documentation; a bad team treats it like a punishment for being alive.
- Find out what happens when a deployment fails. I’m not looking for “we have zero downtime”—everyone lies about that. I want to hear if they do a blameless post-mortem or if they start looking for a name to put on the incident report. If they mention “accountability” in the context of a single person’s mistake, that’s a red flag.
- Inquire about how they manage their backlog. If the engineers have zero say in what gets built and everything is just a top-down directive from product managers, you aren’t an engineer; you’re a feature factory. You want to know if there is actually space to fix the things that are slowing you down.
- Ask how they handle technical debt. If they say “we don’t have any,” they’re either lying or they aren’t looking. The real signal is whether they have a formal way to address it, like a dedicated percentage of each sprint, or if they just ignore it until the whole system starts buckling under its own weight.
- Watch for how they talk about their “rockstars.” If they brag about the one engineer who can fix everything and works 80 hours a week, you’ve found a single point of failure. That’s not a hero; that’s a person who is going to burn out and leave the rest of you holding a very heavy, very broken bag.
The Post-Mortem Checklist
Stop looking for “passion” and start looking for psychological safety; if they can’t tell you about a time they broke something without sounding defensive, they’ll hide the next outage from you.
Treat technical debt as a real line item in their roadmap, not a buzzword; if they don’t have a dedicated way to pay it down, you aren’t joining a platform team, you’re joining a cleanup crew.
Listen for how they talk about the people who get paged; a healthy team discusses the tooling and the process, while a broken one just blames the person who made the commit.
The Final Check
At the end of the day, spotting a bad culture isn’t about catching them in a lie; it’s about listening to what they don’t say. If they can’t tell you about a recent outage without pointing fingers, or if their answer to technical debt is just “we’ll fix it in the next sprint,” you’ve already found your answer. You aren’t just looking for a place that uses the right tools, but a place that has a functional relationship with failure. If the interview feels like a performance of perfection rather than a transparent conversation about how they actually operate, you should probably trust your gut and keep looking.
I’ve spent enough time in the trenches to know that no stack is perfect and every codebase has its scars. The goal isn’t to find a utopia where nothing ever breaks; that place doesn’t exist. Instead, look for the teams that treat post-mortems as learning opportunities rather than blame sessions. You want to work somewhere where the engineers are empowered to leave things better than they found them, even if it takes a few extra hours of unglamorous refactoring. Choose the team that values stability over hype, and you’ll find much better sleep on the nights when things inevitably go sideways.
Frequently Asked Questions
How do I distinguish between a team that is genuinely busy with high-growth scaling and a team that is just drowning in unmanaged technical debt?
Ask them how they decide what to build next. A scaling team talks about capacity, roadmap trade-offs, and how they’re evolving their architecture to handle the load. A drowning team talks about “firefighting,” “putting out fires,” and how they “just don’t have time” to fix the stuff that keeps breaking. If their primary way of describing their sprint is “survival,” you aren’t joining a growth phase; you’re joining a rescue mission.
What should I do if the interviewer gives me a vague, "everything is fine" answer when I ask about on-call rotations or incident management?
If they give you the “everything is fine” line, they’re either lying or they don’t actually know. In my experience, “everything is fine” is the universal code for “we don’t have a process, we just have luck.”
Is it possible to spot a toxic culture during a remote interview, or are the red flags mostly visible in person?
It’s actually easier to spot them remotely if you know where to look. In person, you can hide behind office perks and “vibes.” Over Zoom, you have to rely on the friction. Watch for the lag in communication, the way engineers look at each other before answering a question, or if the interviewer seems rushed to get through their script. If they can’t manage a smooth video call, they probably can’t manage a calm incident response.
How do I ask about work-life balance without sounding like I'm afraid of hard work or looking for an easy ride?
Don’t ask if they “value work-life balance”—that’s a red flag for managers looking for someone to burn out. Instead, ask about the on-call rotation and how they handle incidents. Ask, “When the last major outage happened, how was the handoff managed, and did the person on call get to sleep the next day?” It’s not about avoiding work; it’s about checking if they have a sustainable system for when things inevitably go sideways.
