What I Look For When Evaluating a New Role

I've changed roles a few times in my career. Some moves were great. One was a mistake I recognized within months. The difference came down to what I evaluated before saying yes.

Early on, I optimized for compensation and brand name. Those matter, but they're table stakes. The things that actually determine whether you'll thrive in a role are harder to assess and require asking better questions.

The Dimensions I Evaluate

1. The Problem Space

The single biggest predictor of job satisfaction for me is whether the problem is interesting. Not "interesting" in a theoretical sense, but interesting in a "I want to think about this on a Saturday morning" sense.

Questions I ask:

• "What's the hardest technical problem your team solved in the last six months?"
• "What's the biggest unsolved problem right now?"
• "If I joined, what would I be working on in my first three months?"

The answers tell me whether the work is genuinely challenging or if the role is mostly glue work and maintenance. Both are valuable. But I know which one energizes me.

2. The Team

I'd rather work on a boring problem with a great team than a fascinating problem with a dysfunctional one. The team determines your daily experience more than anything else.

Questions I ask:

• "Can I meet the people I'd be working with directly?" (If the answer is no, that's a red flag.)
• "How does the team handle disagreements about technical direction?"
• "What does code review look like? How long does a typical PR take to merge?"
• "Tell me about someone who recently grew into a more senior role on the team."

I also pay attention to how people talk about each other. In healthy teams, people speak about their colleagues with respect, even when discussing challenges. In unhealthy teams, you'll hear subtle (or not subtle) frustration.

3. The Engineering Culture

Culture is what happens when no one is watching. It's the default behavior, not the aspirational values on a careers page.

Questions I ask:

• "When was the last time you had a production incident? How did the team handle it?" (Blame-free post-mortems vs. finger-pointing tells you everything.)
• "How do you decide what to build next? Who has input?"
• "What's your deployment process? How often do you ship?"
• "What's the ratio of new feature work to maintenance and tech debt?"

I'm looking for teams that ship frequently, take reliability seriously, and give engineers influence over what gets built. If the answer to "how often do you ship" is "every two weeks, on release trains," that tells me something different than "multiple times a day."

4. The Manager

Your manager is the most important person in your work life. They control your project assignments, your visibility, your performance reviews, and your promotion path. A great manager at an average company beats an average manager at a great company.

Questions I ask the hiring manager directly:

• "How do you run 1-on-1s?"
• "What does success look like for this role in the first year?"
• "Tell me about someone you managed who got promoted. What did that process look like?"
• "How do you handle it when you and a report disagree on a technical decision?"

I also try to talk to someone who currently reports to this manager. Their candid perspective is more valuable than anything the manager says about themselves.

5. Growth Trajectory

A role should make you more valuable, not just more experienced. There's a difference. Doing the same thing for three years gives you one year of experience repeated three times.

Questions I ask:

• "What would I learn here that I can't learn where I am now?"
• "What does the path from this role to the next level look like?"
• "Is there scope for me to take on more responsibility as I prove myself, or is the role fairly fixed?"

The best roles put you slightly outside your comfort zone. You should be confident you can do 70% of the job well on day one. The other 30% is where the growth happens.

6. The Business

A technically great team at a failing company is still a failing company. I pay attention to the fundamentals:

• Is the company profitable or on a clear path to profitability?
• Is the product growing or declining?
• What's the competitive landscape?
• If it's a startup, how much runway do they have?

I'm not looking for certainty. Every company has risks. I'm looking for whether the leadership understands those risks and has a credible plan to address them.

Red Flags I've Learned to Spot

"We're like a family." Families don't do performance reviews. This usually means blurred boundaries between work and personal life, and difficulty making hard decisions about underperformers.

Vague answers about engineering practices. If the team can't clearly articulate their deployment process, testing strategy, or incident response, it's likely ad hoc. That means you'll be building process from scratch, which is fine if that's what you want, but exhausting if it isn't.

Everyone is "senior." If a 20-person team has 15 senior engineers, the title is meaningless. Ask about the actual level distribution and what distinguishes levels.

High urgency in the hiring process. "We need to fill this role by next week" pressures you into a fast decision. Good teams want you to make an informed choice because they know that's how you get people who stay.

No clear answer to "why is this role open?" Every role is open for a reason: growth, backfill, new initiative. If the interviewer dances around the answer, dig deeper. Understanding why the role exists tells you what you're walking into.

The Decision Framework

After gathering all this information, I score each dimension on a simple scale:

Problem Space:        Exciting / Good / Okay / Boring
Team:                 Strong / Solid / Mixed / Concerning
Engineering Culture:  Mature / Developing / Ad Hoc / Chaotic
Manager:              Great / Good / Unknown / Red Flags
Growth Trajectory:    High / Moderate / Low / Stagnant
Business:             Strong / Stable / Uncertain / Risky

No role is perfect across all dimensions. The question is which tradeoffs I'm willing to make. I'll take a "Good" problem space with a "Strong" team over an "Exciting" problem space with "Concerning" team dynamics every time.

What I Got Wrong Before

My biggest career mistake was optimizing for the wrong dimension. I took a role because the problem space was fascinating and the compensation was great. But the team was dysfunctional, the manager was absent, and the engineering culture was chaotic. I spent more energy navigating organizational dysfunction than doing actual engineering.

The lesson: the day-to-day experience matters more than the pitch. A role that sounds incredible in the interview but feels draining on a Tuesday afternoon is the wrong role. Trust the signals you pick up during the process. If something feels off, it probably is.