By the time someone has a decade of experience on their resume, I already know they can code — and write correct code at that. What I don't know, and what actually determines whether they'll thrive on my team, is whether they're curious, passionate, and wired to build great things. That's what the interview is for.
4–7 min read
Key Takeaways
When a senior engineer sits down across from me, they've typically spent ten or more years solving real problems in production environments. They've debugged systems at 2am. They've made architectural decisions under pressure. They've written a lot of correct code — and learned from the times it wasn't.
That track record is already documented. I can see it. I believe it.
So why would I spend an hour asking them to write a sorting algorithm on a whiteboard or recall the exact syntax of an API they'd look up in thirty seconds on the job? What does that tell me that their career history doesn't?
The honest answer is: not much. It tells me whether someone can perform a specific cognitive task under artificial stress — which is almost nothing like the actual job. A senior engineer who hesitates on a whiteboard problem isn't a weak engineer. They're often someone whose brain — like mine — is wired for solving problems in full context, not performing isolated recall under pressure.
At the senior level, the resume and track record have already cleared the technical bar. The interview is for everything they can't show me on paper.
What I'm trying to understand in a senior engineer interview comes down to three things.
Are they still learning? The engineers who stay sharp over time aren't the ones who mastered a stack and stopped. They're perpetually curious — reading about new approaches, experimenting on side projects, rethinking patterns they've used for years. I want to know what they've been learning lately. Not for certification value. Just because it interests them. That curiosity signals someone who will keep growing on your team rather than slowly calcifying.
What excites them? This sounds soft. It isn't. When I ask an engineer what they're most excited about in their work, the answer tells me immediately whether I'm talking to someone who wants to build great things or someone who wants to complete tasks. Both exist. But for the kind of environment I'm building — where engineers own outcomes and care about what they're shipping — I need the first kind. Passion isn't a nice-to-have. It's the engine.
Who are they as an engineer? Beyond the skills and the experience, I want to understand their instincts. Do they think in systems or in features? Do they ask about the problem before proposing a solution? Do they care about the person on the other end of what they're building? Those instincts are hard to teach — and they show up in how someone talks about their work, not in whether they can invert a binary tree under time pressure.
By the time someone has a decade of experience, the interview isn't a test. It's a conversation. I'm trying to understand who they are as an engineer — not whether they can perform on command.
Series
People-First Leadership · Part 1
Next · Part 2
Why I Let People Struggle — And When I Step In
Next · Part 3
People Are Your Most Valuable Asset — And Most Leaders Don't Actually Believe That
Next · Part 4
The Documentation Discipline Every Engineering Leader Needs
Next · Part 5
Accountable Autonomy: The Leadership Philosophy That Actually Works
There's a distinction I think about a lot in hiring: the difference between engineers who want to write code and engineers who want to build great things.
Both can be technically excellent — and correct code matters, don't get me wrong. The difference is in orientation. An engineer focused inward on the craft of implementation cares about the elegance of the solution, the correctness of the logic, the performance of the system. That has real value.
But an engineer focused on the outcome — what this system does for the people who use it, how it fits the larger product, what it enables that wasn't possible before — that's a different level entirely. They care just as much about getting the code right, but the code is in service of something bigger.
At the senior level, that distinction matters enormously. Senior engineers aren't just implementing solutions. They're shaping how their team thinks about problems. They're making architectural decisions that will constrain or enable the organization for years. They're setting a standard for how work gets done.
For that role, I want builders. And you don't find builders with a whiteboard syntax test. You find them by asking what they care about.
I'll be honest about this. I've sat through enough technical interviews — on both sides of the table — to have a strong opinion about what's wrong with most of them.
Too many are structured to find gaps rather than reveal strengths. The format is adversarial by design. Questions are pulled out of context and stripped of the real-world complexity that makes engineering interesting. And the signal it generates is narrow — you learn whether someone can perform under artificial conditions, not whether they can actually do the job.
I've been in interviews where it felt like the goal was to establish dominance rather than genuinely assess fit. I've watched technically strong engineers stumble on whiteboard problems because their brain — like mine — is built for solutions in full context, not isolated syntax recall. My brain is wired to see the whole problem and find the path forward. Hand me a chunk of code stripped of its context and ask me to perform with it under pressure — that's not testing engineering ability. That's testing a very specific kind of memory.
I've also watched candidates ace every technical question and then show up disengaged, incurious, and uninterested in the outcomes of their work. Technically correct. Checked out. The format rewarded the wrong things and missed everything that mattered.
My interviews for senior engineers are conversations, not tests.
I ask what they're excited about. I ask about a project they're proud of and listen for whether they talk about what they built or what it did. I ask what they've been learning lately. I ask whether they'd do anything differently on their last major project.
I watch how they handle ambiguity — whether they ask good questions or barrel toward an answer. I notice whether they're genuinely engaged or just going through the motions. I pay attention to whether they talk about their work in terms of impact or just implementation.
None of that requires a whiteboard. It requires a real conversation — and the willingness to trust that a senior engineer with a strong track record already knows how to write correct code. The interview is for the rest: the curiosity, the passion, the drive to build something worth building.
I'll say one more thing — and this applies to me as a candidate as much as it does to me as a hiring manager.
When a company requires a technical screen for a senior engineering role, I take that as a signal. Not necessarily a dealbreaker, but a signal. It tells me what they're optimizing for. They want to verify syntax recall and performance under artificial pressure. They want coders.
I want to work somewhere that wants thinkers.
A company that evaluates senior engineers on whiteboard problems is showing me, before I ever join, how they think about engineering talent. And a company that thinks a decade of production experience still needs to be validated with a sorting algorithm is probably not building the kind of engineering culture I want to be part of.
The interview process is a two-way window. Candidates are evaluating you just as much as you're evaluating them. How you run your interviews says everything about what you value — and the engineers who are most worth hiring will notice.