Show me your codebase

Ten years ago, I was in a whiteboard interview. They wanted me to reverse a binary tree or something. I declined. Asked if I could look at their actual codebase instead.

If you want to know how I think, let me think about something real.

I've been doing this ever since, on both sides. When I interview candidates now, I share our code and let them poke around. Ask them to walk me through how they'd fix a bug. Or suggest a refactor. You learn more in 30 minutes of that than in two hours of algorithm puzzles.

What you actually learn

Live code shows you everything. Architecture decisions. Technical debt. Weird naming conventions nobody remembers the reason for. You see how someone reacts to a mess. Do they ask questions? Do they judge? Do they immediately start suggesting changes, or do they try to understand why things are the way they are first?

That reaction tells you more about cultural fit than any behavioral interview question.

And it works both ways. Candidates see what they're actually signing up for. No surprises on day one. The ones who've been through this process usually show up with ideas already. They've seen the code. They know where they want to dig in.

The conversation changes

Instead of "implement a linked list," you're talking about real tradeoffs. "Why did you use this pattern here?" "What would break if we changed this?" "How would you approach this differently?"

That's a conversation. That's how you actually work with someone.

If you're hiring, try this. If you're interviewing, ask to see the code. Both sides end up with a much better sense of whether it's going to work.