Interviewing is hard

Interviewing people for technical positions is hard, we all know that. In fact, I’ve been knowing that for some time, mainly because I was reading about it in various blogs. What I didn’t realize was how much difficult it was until I had to be the guy asking the questions.

Fast forward a few years and there I am, sitting with a candidate in front of me, trying to understand if I want to be working with this guy for the next months or even years. The interview typically lasts about one hour, during which we give the candidate the time to explain us his background, what he’s looking for in a new job (even though the answer is pretty much always “to work on interesting projects and learn new stuff”); then we set off to ask some technical questions.

In our work environment, where we manage a couple of mission-critical web apps for a big bank, there are no particular separations between developers: every one of us is expected to know how to build and fix things in the frontend, manage the algorithms in the backend, write database procedures and design new tables. For this reason, we usually ask both frontend and backend questions, in order to know if the candidate has at least a basic idea of how to iterate on a Java HashMap or if he knows the principles of AJAX requests. A lot of the times, we hear answers such as:

• “I’ve never used AJAX before”
• “I’ve been working mainly on the frontend, I’m not sure I remember how to write the code for iterating on a HashMap”
• “Database? Sure, I will just put everything on a couple of tables and then query the data everytime I need it”

When I hear answers like these, but the candidate up until this point is proving to be reasonably smart and quite expert in some specific areas, I start asking myself “is there a way I can get this guy to show me how good he is and how fast he can pick up new technologies?”.

1. Understand the candidate’s strengths #

Try to get a feeling for which area/technology the candidate is most expert in, either because he tells you or it’s written in the resume. Begin asking questions from there: in this way you can tell if the candidate is lying or not and how accurate he is in rating his own experience.

2. Ask general questions #

Basically you want to hire smart people. That doesn’t mean you need to hire only the best Ph.D.s around or someone that has developed a new framework on his own: there are cases when you don’t need that much skill, even though it’s certainly desirable. But you sure want to hire people that can understand new concepts fairly quickly: the banking world is full of content-specific things that are sometimes absolutely non-trivial and non-straighforward; still, you need to understand them in order to write the correct code for the application.

So how do you figure out if you’re talking to a smart candidate? We ask general algorithm questions, not so far removed from our work setting that might give the candidate a wrong idea of what we do (no point in asking how to implement insertion in a red-black tree if even our CTO has never had to write code for a red-black tree in production) but close enough that we can figure how the candidate would have solved a real problem that we had related to that algorithm.

3. Don’t forget the basics #

Whether you’re a new grad or a senior programmer, I’m going to ask you the asymptotic complexity of your solutions, time and space. This is because it’s highly unlikely you can figure out an efficient solution if you don’t have a mental framework for comparing it against others.

This might sound silly to you, but I have recently interview people who got extremely confused on the time and space required to sort an array (even after we suggested one possible sorting algorithm).

This is my experience so far; I hope it’s useful for some of you guys in your interviews. For comments, drop me a line on twitter.