In a lot of cases I think developers first learn they're "senior" when they get asked to start giving technical interviews. One day you're chasing bugs in a debugger and the next day someone's life, or at least the next bit of their professional life, is in your hands. This isn't what most developers aspire to. I certainly never did.

It can be awkward and uncomfortable, and nobody will train you for it. Most people probably just mimic what's happened to them, scars included.

But this is a good problem to have. It's an opportunity, but not one we always feel prepared for.

Interviewing gives you the literal ability to help shape the organization. Not just theoretically, but in a very concrete way. That's leverage we often don't have. It's worth doing, carefully.

What I'm Not Doing

The role of a technical interviewer does not need to be establishing some particular level of eliteness. It is not the time for artificial stress, trivia games, performance theater, or an adversarial posture at all.

Adding stress does not add rigor. It adds noise, and noise hides signal. If the goal is truth then panic is counterproductive.

Kindness and friendliness, in this regard, are not the same as permissiveness or laxness. It doesn't mean you recommend everyone. But deep familiarity leaks, and if the room is quiet enough you will be able to pick it up.

What I Actually Do

I hesitate to get too specific -- checklists and strategies aren't really the right framing for this. It's a conversation, and good conversations don't start with specific goals. You do need to know their history, and it's good to show them that you've read their resume.

What Are You Proud Of

The first thing I like to ask is what they're proudest of on their resume -- specifically not what produced the most business value or the best KPIs, but what they, looking back, are proud to have done. And I'm not coy about what I'm looking for from them here. I will tell them, point blank, "I'm not talking about business value, I'm talking about what you value."

They can tell management about their KPIs, that's just not what I'm looking for here. I want them to reveal a bit about themselves and what they value. They have a wide latitude in how they answer this question, and it tells you a lot. Maybe in their heart of hearts, producing 7% growth year-over-year is their absolute jam. That's fine, and that's a signal.

But, personally, when I'm in that chair, I'd rather see some passion.

Rosetta Code

I'll state flat out I don't like having people write code in interviews. Others can and do disagree, but to me you're going to end up selecting for something you don't actually care about. And you can tell them up front, "we're not doing live coding." That can be the very first thing you say to them after "hello" and with a lot of people that's going to earn you trust.

Instead I like to ask people to read code, and reason through what it does. Small functions, usually with the names and variables scratched out, and just let the person think through, out loud, with you. What does the function do? What do they think of it? Is there something they'd do differently? I don't do trick questions, so if they like the function as-is that's fine. But if they've got some style or taste they care about? That's signal.

I'll usually pick at least one example from a language not on their resume. I'll acknowledge to them that, yeah it's not on their resume, and I just want them to work through it. Nobody understands everything the first time they see it in the real job, so here's an opportunity to watch them in that situation. Caution though, this is the sort of thing that works if you've built up trust. You're not springing a trap on them or trying to measure them as a Real Coder. You're just showing them something they don't understand and asking them to see what they can figure out.

Aside: C and C++ on resumes

If someone lists C or C++, I'll usually show them a small piece of terrible C and ask them to tear it apart.

Returning pointers to stack memory. Array size issues. Pointers that could be const &. Nothing clever -- just a dense, overwhelming run of obvious footguns, one after the other. The best people will crack their knuckles and dig right in.

C is rough. If a role genuinely needs it, I need to know the person can smell garbage instantly.

And if it doesn't, listing C or C++ is still worth talking through. They're sharp tools. Saying you've used them is a claim about how you manage risk, and that I am always interested in.

Favorite Language, Really

I like to give the person explicit permission to answer idiosyncratically. We both know this is an interview. We both know there's a script. Most of the time, we both choose to stay inside it.

So I ask what their favorite language is, and I'll say something like: "This is obviously an interview, so I know the 'right' answer is 'the right tool for the job.' That's not what I'm asking. If you were king here -- no constraints -- what would we use?"

That question isn't really about language at all. It's about what happens once the script is suspended. People who've actually lived in a language talk about its libraries with texture: tradeoffs, preferences, scars. People who haven't don't. Deep familiarity leaks, especially when it's safe to stop performing.

I don't push back hard on the answer itself. The point isn't to corner anyone. It's to have a real conversation with the developer sitting across from you, as much on their terms as the situation allows. If you've built enough trust, you end up talking with the actual person you'd be working with.

What I've Stopped Doing

I used to give a little homework -- usually an early Project Euler problem. Not because the problems were hard, but because they were interesting. They didn't reward memorization or tricks so much as curiosity, and a certain class of developer really lights up when you hand them something like that.

The point was never the answer. It was an excuse to look at code together without doing live coding, and a chance to see what someone found interesting enough to explore on their own. As a bonus, if I was asking someone else to spend time on it, I'd solve it too. That felt like the minimum bar.

AI has mostly taken that option off the table. It was always possible to google a solution, but now the tools can hand you structure and tricks without any intent to deceive. The artifact got cheaper; the conversation didn't.

So I stopped doing it. Not because the idea was bad, but because the signal I cared about was never in the code itself.

Why This Works

None of this requires being clever. You can do the job you were asked to do and still treat people like people, on purpose.

In practice, it works. Conversations get clearer. Signal shows up without force. You leave the room actually knowing how someone thinks.

But mostly, it's just a decent way to spend an hour with another developer. You don't need a stronger reason than that.