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.

Do they ask questions before proposing changes? Do they dismiss the mess, or get curious about how it developed? Can they separate a personal preference from a change that would help the team? Those responses tell me a great deal about how working together might feel.

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.

Of course, not every repository can be shared wholesale. Security, customer data, and intellectual property still matter. A safe, representative part of the code can create the same conversation without exposing what should remain private.

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?"

By the end, both sides have seen a little of how the other thinks. Which part of your codebase would start the most revealing conversation?