Senior Engineering Interviews Are Mostly Theatre
As engineers move into senior roles (title dilution not withstanding—”senior” here means many years of practice), their work becomes less and less about writing code all day. It’s more about judgment than logic. They’re shaping systems, guiding teams, making decisions that ripple through architecture, culture, and future projects. They’re solving fewer “how do I write this” problems and more “what’s the right thing to build and how do we build it responsibly” problems (note the alignment of this statement with LLM-assisted programming—a different topic for another time).
So it’s strange—honestly, absurd—that when interviewing for these roles, we still reach for the same tired approach, typically some combination of live coding, whiteboarding systems design, random technical questions, and/or rushed hypotheticals. As a proxy for real conversation, it’s a worn-out strategy for predicting whether someone is right for the role.
The Interview as Performance
For seasoned engineers, technical interviews can be a challenging format for learning anything useful. It’s a performance—a show of nerves and endurance rather than ability or judgment. When you ask someone to rebalance a binary tree or walk through a caching strategy in an interview, what you’re really asking is how well they can adapt to an artificial environment. Can they quickly decode what’s expected? Can they perform under pressure? Can they think out loud in the “right” way?
That might be helpful if you’re hiring stage actors, but for thoughtful, accomplished engineers who are used to solving real problems over weeks or months, it’s just noise. Worse, sometimes it’s a power move, especially when the candidate is very senior. In that situation, throwing down technical puzzles isn’t about assessment—it’s about control, and it’s toxic.
Why Do We Keep Doing It This Way?
Because it feels fair—or at least, it feels standardized. Everyone gets the same kinds of questions, the same time limit. It creates the illusion of objectivity. But fairness isn’t the same as insight. Just because something is easy to score doesn’t mean it’s meaningful.
There’s also inertia. We’ve done it this way for years, it’s how the big companies do it, and isn’t it reasonable to expect everyone to know the same things? But that’s bias, not purpose. At best, it reflects a narrow definition of engineering competence. At worst, it’s just lazy hazing.
It’s not easy to get off the stage and into the real world. It can be intimidating to really talk shop with someone you just met, especially a battle-hardened senior engineer. Asking questions where you don’t already know the answer takes vulnerability. The standard bag of tricks offers comfort and control.
Don’t Ask Trick Questions—Talk About the Work
Real signal comes from lived experience. What did this person build? Why that way? What broke? What would they do differently? What tradeoffs did they make? How did they define “done”?
If you listen with interest and curiosity, you’ll get more insight from a single war story than ten rounds of technical tests or whiteboard sessions. Ask what failed in production. Ask what tough call they had to make. Ask what they learned. If the conversation is honest, you’ll come away with a real sense of how they think and lead.
If your team isn’t equipped to have that conversation—if they need a script, actors and a theatre instead—then the problem isn’t the candidate.