Show me your codebase

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

If they wanted to know how I thought, I wanted something real to think about.

I've used that approach ever since, on both sides of the table. When I interview candidates, I share code and give them room to explore it. We might walk through how they would fix a bug or ask what they would refactor. I've learned more from 30 minutes of that conversation than from two hours of algorithm puzzles.

Watch how they meet the code

A real codebase carries architecture decisions, technical debt, and naming conventions whose history nobody quite remembers. Seeing it gives a candidate something substantial to react to.

I pay attention to whether they ask questions before proposing changes and how they respond to the mess. I'm also interested in whether they can separate a personal preference from a change that would help the team. We'll have plenty of those disagreements if we work together.

The candidate is evaluating us too. They can see the kind of system they may be joining and ask about the decisions that shaped it. People who come through this process often arrive with ideas because they already know where they want to dig in.

That doesn't require sharing the whole repository. A representative section, checked for secrets, customer data, and code the company can't disclose, is enough to start the conversation.

Talk about the tradeoffs

Real code leads naturally to the questions people ask once they're on the job: "Why did you use this pattern here?" "What would break if we changed this?" "How would you approach it differently?"

I want to hear how a candidate works through those questions. I also want them to hear our answers before they decide to join.