The Interview Process Wasn’t Built for Them
The Generalist Series, Part 3
Most engineering interview processes are good at what they do. They test depth of knowledge, system design at scale, algorithmic thinking. They find strong specialists reliably.
But they will miss the person who holds the whole thing together. Not because that person fails the interview. Because the interview never tests for what they do.
The CV problem
The first filter most candidates hit is the resume screen. And for generalists, this is where it often ends.
Their CV looks like a series of pivots.
Two years in backend,
a year in data engineering,
a stint in platform,
a move into a cross-functional role.
To a conventional screener, this reads as “couldn’t commit.” The pattern looks like someone who hasn’t found their thing yet.
David Epstein’s research in Range suggests the opposite. He calls it “match quality”: people who sample broadly before committing tend to find better long-term fit. The pivoting CV is often evidence of a healthy search. Someone who tried enough domains to know what they’re good at and where they create the most value.
The screening question should shift. Not “did they stay?” but “did they get better at each step?” Look for trajectory, not tenure. Look for whether each move made them more capable, not whether it was in the same direction.
What to listen for
If a generalist makes it past the resume screen, the interview itself often still misses them, because most interview rubrics are calibrated for depth signals. Here’s what to listen for instead.
They describe problems in terms of what was at stake, not just what they built. The specialist walks you through the architecture of their system. The generalist tells you the situation the team was in. Why that problem mattered more than the three other things they could have worked on. They lead with context, not components.
They talk about the people around them. They naturally frame their own contribution relative to the team. They mention what other people were doing, what information was missing, who needed to be connected. This isn’t modesty, it’s just how they think. They see the system of people, not just the system of code.
They reach for analogies from outside the domain. This one is subtle, and most interviewers miss it. A generalist might explain a caching strategy with a metaphor from logistics. Or describe a team dynamic using sports coaching language. Epstein identifies this (analogical thinking) as one of the strongest predictors of creative problem solving. It means the candidate is drawing on a wide base of mental models, not just the patterns from their specific domain.
Three questions that surface these signals:
“Walk me through a time you worked on a problem that crossed team boundaries.”
“What’s a decision you influenced that wasn’t technically yours to make?”
“Tell me about a time you borrowed an idea from one field to solve a problem in a completely different one.”
The third question tends to separate generalists from specialists. Specialists struggle with it because their work doesn’t usually require them to cross domains. The generalist lights up.
The job description problem
Even if you fix the screen and the interview, the job description itself might be filtering generalists out before they ever apply.
“Senior Backend Engineer.” “Staff Platform Engineer.” “Principal Data Engineer.” The generalist reads these titles and thinks: that’s someone else’s job. The specificity of scope tells them there’s no room to move. And moving is what they do.
The fix is to describe the problems, not the stack.
Before: “We’re looking for a Senior Backend Engineer with 5+ years of experience in distributed systems, strong knowledge of Kafka and PostgreSQL, and a track record of building high-throughput data pipelines.”
After: “We’re looking for an engineer who can work across teams to solve problems that don’t have a clear owner. You’ll spend time in backend systems, data infrastructure, and cross-functional planning, wherever the hardest problem is that week. You should be comfortable operating without a fixed scope.”
Same role. Different framing. One attracts specialists. The other attracts the person you actually need.
The trust prerequisite
One honest caveat: hiring a generalist and dropping them into a role with rigid scope and tight oversight will fail. Sure, they can follow rules, but the value they create depends on freedom to move.
The best delegation model I’ve seen comes down to two words: “be careful.”
Trust plus guardrails. Autonomy with a safety net.
The generalist needs room to go where the problem is. They need a manager who trusts them to do that without micromanaging the path.
If your organisation isn’t ready for that, hiring a generalist won’t fix the problem. You’ll hire them, constrain them, watch them plateau, and watch them leave. Which is where we started in Post 2 of this series.
You don’t need to redesign your entire hiring process. You need to stop accidentally filtering out the person who would have made your team better.
Screen for trajectory. Interview for context awareness. Write the job description for the problem, not the stack. And make sure the role has room for someone who moves.
In rhe final post we’ll look forward: what the generalist becomes on an AI-augmented team and why it matters now more than ever.
Share this with a hiring manager on your team. Or reply with the interview question you’d add to this list.