Senior technical interviews, from both sides of the table

The worst senior technical interview I ever sat through was forty minutes of inverting a binary tree on a whiteboard while two people stared at me in silence. I had shipped systems serving millions of requests, and none of that came up. I have since interviewed plenty of senior engineers myself, and I have a strong opinion now: a senior technical interview should be testing judgment, not whether you memorized an algorithm you will never write by hand again.

What a senior interview is actually for

When you hire a junior, you are betting on potential. When you hire a senior, you are betting on someone who can be handed an ambiguous problem and come back with a sane plan, a sense of the tradeoffs, and the ability to bring other people along. None of that shows up in a leetcode score. So the questions I ask are deliberately open. I want to see how someone thinks when the answer is not in the back of the book.

My favorite prompt is just describe something you built that you are proud of, then go deep. Why that database. What broke in production. What you would do differently. A real senior lights up here because they have scars and opinions. Someone coasting on a title gives you a feature list and nothing underneath it.

How I run one when I am the interviewer

I tell the candidate the format up front. No gotchas. I want them at their best, not flinching. Then I give them a problem close to the actual work, something like designing an indexer that ingests on-chain events and serves them through an API, and I let them drive. I am watching for a few things while they talk.

• Do they ask about constraints before they start drawing boxes, or do they jump straight to a solution they read about once.
• Do they name the tradeoffs out loud, or pretend there is one right answer.
• When I push back, do they defend a bad idea or update gracefully.
• Can they tell me what they would do first, and why that piece comes first.

That last point matters more than people think. Sequencing is a senior skill. Anyone can list ten things a system needs. Knowing which two you build in week one, and which six you defer, is the actual job.

The senior technical interview from the candidate seat

When I am the one being interviewed, I have learned to slow down. The instinct is to prove competence fast, so you start coding or drawing before you understand the problem. Resist that. The first thing I do now is ask questions back. What is the scale. What is the read versus write pattern. What already exists that I have to live with. This is not stalling. It is the exact behavior they should want from a senior, and it buys you a clearer picture before you commit to an approach.

I also say my assumptions out loud and check them. Something like, I am assuming we control the schema here, tell me if that is wrong. It turns the interview into a working session instead of an exam, and working sessions are where senior people shine. If the interviewer wants me to suffer in silence, that tells me something useful about the team too.

Coding rounds that do not insult anyone

I am not against writing code in an interview. I am against writing code that has nothing to do with the role. A good coding round looks like the day job: here is a small messy function, make it correct and readable, add the test you would actually write. I learn more from watching someone clean up real code than from watching them recall an algorithm. Reading and improving existing code is most of what senior engineers do, so test that.

If a company insists on hard algorithm puzzles for a senior backend or full-stack role, I take it as a signal about how they think about the work. Sometimes it is just legacy process. Sometimes it means they confuse cleverness with seniority, and those are different things.

Signals I trust on both sides

The strongest signal I look for, as interviewer and candidate, is whether the conversation feels like two engineers solving something together. When that happens, the decision is usually easy. The candidate who says I do not know, here is how I would find out is worth more than the one who bluffs a confident wrong answer, because the first one will not quietly break production six months in.

If you are interviewing for senior roles right now, prepare your stories before you prepare your syntax. Have three or four projects you can go deep on, including the parts that went badly and what you learned. That depth is the thing that separates a senior technical interview from a quiz, and it is the part you cannot fake at the whiteboard.