Software Interviews Without Code
The Dangers of Assessing Knowledge Instead of Productivity
It is amazing how many software interviews take place, and how many software engineers are hired without an actual assessment of their ability to write code. If you are hiring a software engineer, coding should be a key part of the assessment criteria.
I have conducted numerous interviews, and I have been a candidate for numerous other technical interviews. I am continually surprised when companies don’t attempt to assess coding ability. They will spend all sorts of time trying to determine how many specific nuances the candidate knows about a particular language, framework, or technology. They will ask obscure questions about various technologies in quiz-like fashion.
Often, the candidate could look up the answer in a few seconds. However, since they were not allowed to use their computer, they failed. That is their reward for not committing things to memory that can be easily looked up.
Does that seem strange? Why wouldn’t we allow a candidate use the same tools during an interview that they would have at their disposal during a typical day on the job? That’s a bit like assessing a race-car driver by having him pedal around the track on a bicycle.
Rule # 1 : If you don’t allow the same tools during the interview as you do during the typical workday, you’re probably not assessing the right things.
Knowledge is not an accurate predictor of productivity. Productivity is an accurate predictor of productivity. Why not give the candidate a problem to solve using the technology of their choosing? Give them a project that is going to take more than an hour to solve. Don't constrain them to a particular language or technology. You are trying at assess their problem solving abilities more than their knowledge of a particular technology. Give them time to finish it. Give them a day, a week, a month. If you are concerned that you’re going to scare off good candidates with all the effort, pay them for the project.
You’ll learn all kinds of things about the way they interact in a work setting that you won’t learn during a typical interview. You can fake behaviors and knowledge in a one-hour interview. It’s harder to fake knowledge and behavior when a candidate has to complete a real project that is representative of something they would encounter in a typical work day.
Rule # 2 : It’s much easier to fake knowledge and behavior than it is to fake productivity.
Keep these concepts in mind when you are looking for your next software engineer. While the ability to communicate is a valuable skill, interview talk is still cheap. A software engineer’s productivity is measured by what they produce, not by how well they talked about what they produce.
