There are literally millions of links on the internet about interviewing developers–interview questions, posts on why the way you do it is wrong, and even guides on making it through an interview process. Here’s one more, about the interview process at my current employer.
Before I joined my current company (back in 2012), before I even set foot onsite, there was a phone screen. At the time, there seemed to be one developer responsible for phone screening every prospective developer candidate for the entire company. If memory serves, the phone screen lasted around 45 minutes. The questions were challenging, but not impossible to answer. When the in-person interviews were scheduled, I had no idea what I was in for. Over the course of 5 hours, I spoke to 7 different people who had some role in 2 or 3 different projects or products within the company. The first hour, they put a laptop with Visual Studio in front of me and asked me to write a console app that performed three different tasks (I won’t go into too much more detail as we still use the same exercise to this day). I was able to complete the exercise with enough time to spare for my two interviewers to ask me questions about my solution (which while it worked correctly, was not the most elegant). The rest of the interviews were all questions, some behavioral/team/”fit”-related, but mostly technical. All the developer hires that came in after me presumably went through a similar process.
Fast-forward to the fall of 2013–we’ve won a contract that more than doubles the amount of work we need to deliver. The pressure is on to find, hire and onboard as many good developers as we can find. An interview process that works just fine when you only hire a new developer every month or two scales poorly when you have a month or two to hire a dozen developers. So we involve more developers in the interview process and cast a wide net for prospective hires. After spending many man-hours interviewing candidates who struggle with our programming exercises, we find a few external candidates to hire–but far less than the dozen we need. We end up grabbing people from other teams within the company to compensate.
So when our company changed the process again to involve developers in the phone screen process, I did some Googling to find out what sort of questions make an effective phone screen. By far, the most useful post I’ve found is Steve Yegge’s Five Essential Phone-Screen Questions. Reading (and re-reading) the whole thing is definitely worth your time. Our recruiters only allot 30 minutes of time for our phone screens (and I usually have code to design & write, or bugs to fix), so my phone screen generally only covers 3 of Yegge’s 5 areas–coding, OO design and data structures. In the coding area, instead of giving the candidates homework (or having them read the code over the phone), I started sharing a Google document with them and watching them write their answer to the coding question. This is a great way to get a sense of how quickly a prospective developer hire can come up with a solution on the fly. A more involved (and somewhat more buggy) approach, is to use the .NET Fiddle online console along with its collaboration feature. If it doesn’t crash on you during the interview, you’ll be able to see if the solution compiles and runs successfully on the spot. Thirty minutes has proven to be enough to get in a coding exercise and enough questions about OO design and data structures to have a good feel for whether or not it would be worthwhile to move someone on to the in-person interview phase of our process. Since in-person interviews are generally conducted in pairs, each 30-minute phone screen that properly rejects a candidate saves 2-4 man-hours of additional interview time.
If there is any revision I would make to the current interview process, it would be to push our simpler questions into the candidate “homework” idea Yegge mentions early in his post. Then we could preserve our 30 minutes of phone screen time for candidates who we already know have handled our easiest exercises.