Interviewing Programmers When You Barely Are One

I suck at writing code. It’s just not one of my strengths. This begs the question, how can one do a good job of finding someone who is good at the thing (programming) you aren’t? I know I’m not the only in this position. But this isn’t a question of finding people for a job that you know nothing about. This is about using the knowledge you have to help find people who are well suited for a position that you understand. More specifically, it’s about using that knowledge to find the right archetypes.

Me?

I can write functional code when I have to. But at best, it typically ends up being like duct tape that just gets the job done. It works sufficiently well to hang on long enough to be replaced by folks better suited for the task. I’ve been fortunate to have been able to find great people over the years to do those replacements (or just write better code to begin with).

Learning how to interview well takes a lot of experience in and of itself. Since that just takes time, there are some basic frameworks that I now follow. If I’m hiring someone to do a job, then I generally will have at least attempted to perform part of that job at some point. It’s difficult to know the focus of a position if you’ve never tried to do it yourself. A great example of this (for me) was writing Go (Golang) code. Though this example can really apply to any language that you’d like.

What I Know Generally

1. Most actual programmers use references (pronounced Google or Stack Overflow) almost all the time.
2. Interviews, for better or worse, are a bit of a pressure cooker. So getting people to talk more about their actual experiences and draw from things they’ve already done usually eases the tension a little.

Since I know I am not going to be able to (or want to) grade hard programming problems, I don’t need to ask any of them. So where does that leave me? I find that you can really learn a lot by talking to a person about their experiences. These questions typically lead down some really interesting rabbit holes.

Questions To Get People Talking

1. What was the first project you built in Go? What were your initial reactions to the language? How have those feelings evolved as you’ve gotten deeper into the language?
2. Tell me about 1 or 2 of the more recent projects that you’ve built in Go.
3. What notable changes did you make for these projects that are a direct result of something you learned the hard way from previous projects? Doesn’t have to be Go related necessarily.
4. What do you like and dislike about Go as a language (in terms of structural and syntax decisions)? Can you see why those things exist in the language the way they do?
5. What was the biggest mistake you made in Go and how did you correct it? How did you catch it?
6. What type of tools do you use in support of your development? Your environment? Why and how do they compare/contrast to other tools?

I’m usually (but not always because red flags can appear here) less interested in all the reasoning itself and more so interested on the level of critical thinking that someone is doing. Lots of people can write code. But not everyone thinks critically about their tools, process, and product.

Real Tests

If there is a reasonable approximation of a solution that can be given for a problem that the team has solved within the last few months, I would give the candidate some context and ask them to talk me through their ideas. I would give them as much information and context as the team had at the time. If they come up with a solution that seems like it would work on the surface or that we tried and it failed, I’d tell them what happened and why. The goal is to see how they think. I want to give them a solvable problem and see how their experiences help guide their responses. I don’t even usually care if they figure out correctly (though that’s always a plus). This process has multiple positive effects in my experience.

1. No candidate wants to solve your problems for you for free. Since you have already solved the problem, that’s a non-issue. But they may be able to give you interesting insight as to a similar or better solution. They can offer you insight into the pros and cons of your existing solution.
2. This also allows them to know the types of problems with which they may see on a regular basis while working for your organization. What better way to show a candidate their perspective workload than giving them a task that was just handled?

The main idea of this part of a job interview is that you want to know if the candidate knows what they are talking about. If they don’t, do you feel like they are capable of figuring it out and thinking critically about how to get there? You also want to make sure they’ve made some mistakes before or at least understand the pitfalls if they haven’t made the mistakes themselves. We all dig holes for ourselves, the question is whether or not we know how to dig out as well.