What’s the back-story?
About a week or two ago, I wrote a post in my Pittsburgh Software Developers Facebook group that I thought wasn’t particularly controversial. I basically said that, after finally implementing live coding sessions in our developer interviews, the notion of live coding sessions went from “a good idea” to “mandatory”. This was met will 100% disagreement in the comment session. They were called “tedious” and a “turn off”, and I was asked for validation. So, here it is.
How do I define a live coding sessions?
First of all, let me give my definition of “live coding sessions”. These are any sessions where the prospective developer is given one or more problems and is asked to write code (or pseudo-code) to solve the problem. During the exercise, the candidate is asked to talk-through their thought processes, and the interviewers will ask questions about some of the decisions the candidate has made. This is a VERY open-ended definition, and as I mature with this I will fine tune based on what works and what doesn’t.
What does it give me?
This practice gives me insights concerning the following:
- How the candidate solves problems
- How the candidate responds to being challenged
- How the candidate collaborates
- How the candidate codes
Are there alternatives?
Can I get these insights in other ways? Yes, but not in real-time, and not in a way the represents how they will be working with the team on a day-by-day basis. I may be able to make a decision without these sessions, but there is still risk that the “artificiality” of the interviewing process is leaving gaps in my understanding of the candidate. The “real-timeyness” of it allows me not to be influenced by the candidates’ ad hoc memory of things from their past than if I asked them about past issues they’ve encountered. And, it’s less “artificial” than giving the candidate a logic problem of some sort.
That all being said, live coding sessions should augment traditional interviews. I’m definitely not saying they should replace them.
What does all of this come down to?
Simple put…It’s Risk Management
The risk is that I am hiring a candidate that will be crucial to my team and will be getting paid very well for it, and there may be gaps in my understanding of the candidate that make them a poor fit.
This risk is exacerbated by the fact that software development is still in a “pre-professional” state. In other words, there A LOT of programmers out there and very few software developers that practice real craftsmanship. There are a lot of reasons for this, but that’s for another post. For now, we’ll just say it’s a young discipline and leave it at that (Hint: It’s not that simple!).
What’s your feedback?
Honestly, 10 years and 50+ developer interviews ago I may not have felt this way. Let’s just say, I’ve made a lot of mistakes and felt a lot of pain as a result. So, when a way to obtain better data comes along to help me make better decisions (and it’s essentially free), I’m taking it.
So far, all I’ve been given is that live coding sessions are “tedious” and a “turn-off”. That could be for a slew of reasons, and does not invalidate my statement. I would really like to hear about your experiences with live coding and what your thoughts are? What do you like them? Why don’t you like them? Are you convinced that they are important enough to be mandatory, or am I being a bit of a zealot? Let me have it.