.png)
Over the course of my career, I’ve had some genuinely great managers. I’ve also had some bad ones. The signals were almost always there in the interview process. I just didn’t know what I was looking at.
Here’s what I look for now. I hope it helps you avoid some of what I learned the hard way.
Signal 1: How They Talk About People Who Left
This one’s subtle, but it tells you a lot.
People who’ve left will come up naturally in interviews. Watch for managers who explain every departure by questioning the character of the person who left. “They just didn’t care.” “They weren’t a culture fit.” “Honestly they were a bad employee.”
In my opinion, that’s a way of avoiding accountability for why people actually leave. And when that attitude comes from the top, it tends to spread. Teams start adopting the same narrative, blaming the people who left rather than asking harder questions about why.
I’ve noticed that when every single person who left was apparently the problem, the problem usually isn’t the people who left.
Ask directly 💬: “Can you tell me about someone who left the team recently and what led to that?” Then just listen. The answer tells you a lot more than most of what gets discussed in interviews.
Signal 2: How They Handle Underperformance and Feedback
This one shows up in what a manager says, but also in what they don’t.
Here’s the pattern: there’s no definition of done. No shared understanding of what good work actually looks like. Ownership of systems and responsibilities stays fuzzy. Then one day someone’s told they’re underperforming, with no specifics about what they did wrong or how to fix it.
In engineering, I’ve seen this show up in a particularly frustrating way. A manager who starts treating GitHub activity as a proxy for productivity. Not accuracy. Not quality. Not whether the work actually solved the problem. Just…were you visibly committing enough, consistently enough, to prove you were working. And if you weren’t, that became the performance conversation.
That’s not a performance problem. That’s a management problem.
Ask directly 💬: “How does your team define done? What does good work look like here and how is that communicated?” A real answer is specific. Watch for answers that are vague, circular, or that put the entire burden of figuring it out on you.
Signal 3: The Moving Goalposts
This one took me the longest to recognize, because it’s so easy to second-guess yourself when it’s happening.
Here’s how it works: policies and technical decisions exist, but they’re vague enough that management can reinterpret them however is convenient. No announcement, no conversation, no acknowledgment that anything changed. If you raise it, the original understanding gets reframed or denied.
Real examples I’ve seen:
- An informal PTO policy that everyone understood and followed, until one day the written policy was enforced without warning or conversation
- A remote role that slowly accumulated passive frustration about people not being local
- An architecture direction the team aligned on, quietly abandoned in favor of something else with no discussion about why
Nothing officially changed. It just did.
Once you’ve lived this a couple of times, you start to recognize it. Vague policies and decisions that get selectively enforced or reversed are a feature, not an accident.
Ask directly 💬: “What are your policies around PTO, remote work, and working hours, and how do changes to those get communicated?” And ask a peer, not just your future manager. They’ll often answer more honestly.
Before You Accept That Offer
Most engineers spend a lot of time preparing to answer interview questions and not enough time preparing to ask them. The interview is a two-way evaluation, and you have more leverage than it feels like you do.
It took me longer than I’d like to admit to really internalize that.
If any of this resonates, or you’re weighing an offer and something is nagging at you, come find me in the Believe in Serverless community or engage with me on the social media links below.
Good luck out there. 💪🏻