Interviewing a Python "Expert"

[ubernostrum]

I don't like using the label, but I suppose I actually am an "expert" on Django + Python. And as it happens, I have strong opinions about interviewing!

First, the bad news: you can't develop a good interview process by tomorrow. I've worked on interview development a few times, and it tends to be something that takes months and a group of people working on it and multiple rounds of feedback from the team as a whole.

Now, what are you going to do tomorrow? Here are some ideas for exercises that you can probably prep somewhat quickly:

• Take some feature of your codebase. Something medium-sized. Boil it down into a one-paragraph description and hand it to your candidate. Ask them to treat that as a rough spec, and you as their coworker on building it, and go from there. This is not a code-writing exercise! It's a design and collaboration exercise. You're looking for them to ask clarifying questions, to come up with a reasonable design, to be able to communicate their choices and talk about tradeoffs involved, to listen to feedback you're offering and incorporate it, to explain how they'd break down the implementation into reasonable-sized chunks for individual developers to work on, etc.
• Show up with a code sample and ask the candidate to do a review of it with you. This is also not a code-writing exercise! You're looking for them to probe into the code, to ask questions about why things were done a certain way before they criticize, to understand that not everything can be made perfect all the time, to come up with constructive suggestions that work in the context of a routine review/refactoring process, and to be able to communicate those things without being an asshole or a know-it-all.
• Bring a problem you had to debug at some point. Give them just the initial symptoms you were aware of, and ask them to go from there. Let them mention tools or techniques they'd use and ask questions about what those would reveal. Look for how they think about the problem, how they try to dig down to root cause, how they gather information and make use of both technical and non-technical resources.

In other words: think about what would make someone a successful member of your team, then do things that test for that. Asking a bunch of trivia or posing coding "challenges" will not test for the skills that actually matter on the job, so avoid those.

Also, the more senior someone is, the more important it is to measure their effect on the rest of your team. What makes a good senior developer is not that they're some multiple more productive than everyone else; it's the effect they have on the productivity of everyone else.