In the software world, we love to say we’re hiring the best. We want independent thinkers, collaborative problem-solvers, and people who can build the future of our products. Sounds great, right?
So why are we still complaining that it’s impossible to find skilled software engineers?
Why are we flooded with candidates but walking away frustrated, saying “nobody is good enough”? Why are otherwise strong companies stuck, unable to grow their teams or deliver on their product vision?
Let’s be honest. Some of the pain is real. But a lot of it is self-inflicted.
We Built the Hoop-Jumping Olympics
Our hiring processes have quietly evolved into elite obstacle courses.
We make people:
- Solve sorting algorithms from scratch (because that’s totally day-to-day life in 2025),
- Recite obscure library methods by memory,
- Crack logic puzzles worthy of Sherlock Holmes,
- And endure 4-5 rounds of interviews stretched over 3 weeks.
We call it “rigorous.”
They call it Nope, I’ve got better things to do.
Spoiler: the good people are out there. They’re just opting out.
Highly skilled engineers already juggle production fires, deadlines, mentorship, maybe even a second startup.
They’d rather spend that time upskilling or solving real-world problems—not speed-running a coding gauntlet for a maybe.
The Fear That Broke Our Process
A lot of teams overcorrect for fairness. We want to be objective, measurable, repeatable. So we make the interview process feel like a standardized test.
But here’s the catch: software interviews are inherently subjective. And they should be.
Not every great engineer is a fit for your team. And that’s okay. But instead of acknowledging that and embracing a more human-centered process, we doubled down on trivia to feel “fair.”
So what do we test?
Questions like:
- “What class in Java handles cryptographic hashes?”
- “What’s the exact signature of that method from XYZ library?”
- “Which collection type guarantees insertion order?”
What do those answers tell you? That someone read up on trivia the night before. Maybe that they have a good memory. But not much else.
But What Are We Actually Looking For?
Let’s step back.
You’re hiring a mid-level or senior developer. What do you actually want?
- Someone who learns fast
- Someone who adapts to your context
- Someone who understands how systems break
- Someone who collaborates well
- Someone who doesn’t bring legacy baggage and repeat the same mistakes
You want someone who makes your team better. Not someone who sounds smart for 30 minutes.
So why not interview for that?
The Better Alternative: Interviewing with Scenarios
This is where Scenario-Based Development (SBD) offers a shift in mindset. It’s not just a framework for building software, it’s a lens for thinking, hiring, and collaborating better.
When your goal is to find someone who improves your product and your team, your interview process should reflect that. So make it:
- Focused
- Human
- Grounded in real work
- Efficient
Here’s what that can look like:
For Back-End / Full-Stack Engineers:
- “A user is trying to send a payment, but their card keeps failing. How would you trace the issue?”
- “How would you add partial refund support into our existing payment system?”
- “You’re joining a legacy codebase. What’s your first week look like?”
For Software Testers / Automation Engineers:
- “You’re asked to validate a feature that lets users change their billing address. What kinds of tests would you design?”
- “A flaky test fails intermittently in CI but not locally. What’s your approach to debugging it?”
- “We’re adding support for multiple currencies. What testing challenges do you anticipate?”
- “How would you design an automated test strategy for a critical API with frequent changes?”
- “What’s your approach when developers say a bug isn’t reproducible, but a customer keeps hitting it?”
These aren’t academic puzzles. They’re practical prompts that reveal:
- Product thinking
- System awareness
- Testing mindset
- Collaboration style
- Problem-solving ability
You know… the things you actually need in a mid or senior hire.
Why Scenario-Based Approaches Work Better
They’re grounded in real-world thinking, not hypotheticals.
They assume you’re hiring for wisdom, not perfection.
They make space for collaboration during the interview, not just one-sided performance.
And they reflect the messy, collaborative, ambiguous nature of actual software development. Because let’s face it, that’s the job.
Final Thought: It’s Not About Lowering the Bar
Let’s be clear: this isn’t about making it easier to get hired.
It’s about making interviews hard in the right ways. The kind of hard that tells you whether someone will thrive in your environment. Whether they’ll ship value, avoid pitfalls, and raise the quality bar for everyone around them.
And yes, this is a challenge to rethink what we value in our hiring process — just like Scenario-Based Development challenges us to rethink how we build.
But that challenge is worth it.
Because when we finally start hiring for what actually matters, we won’t have to complain so much about how “hard it is to find good people.”
Want help redesigning your interview process around scenario thinking? Or curious how SBD could improve your team alignment and product outcomes? Let’s talk. Or even better, try flipping your next technical interview into a scenario and see what you learn.
