I’ve been working professionally in application development since the fall of 1998. I’m a consultant, and I’ve been in quite a few environments over the years. However, I have also worked as a full-time employee in leadership positions in places. I began interviewing candidates for technical positions in 2007. Even after having been the interviewee many times before I quickly realized that asking the right questions isn’t nearly as easy as it looks.
The first technical interviews I conducted tended to be like quiz shows. All of the advice I could find on technical interview questions centered asking very specific technology related questions, or more academic questions on fundamentals of things like object orient programming. My problem at this point was that I relied strictly on these questions, and tailored them to my exact needs at the time. There is nothing fundamentally flawed with asking these questions. They are important in establishing somebody’s base line abilities, but they really don’t give the full technical picture by any means. This level of interviewing is a beginning skill set that is important, and I don’t mean to criticize, but was not nearly important as I thought it was at the time.
So, what was I missing? How could I be doing better? I try to be introspective, and I try to acknowledge when I’m wrong on an approach. I suspect that if you are reading this you may even be that way too.
The first piece of advice I got from a friend was to tailor my interview questions to the candidate’s resume. Don’t just proceed down a laundry list of technical questions you want answered. Typically in the interview process you are provided with tens if not hundreds of resumes. What was it that made you pick this candidate out of the stack of 50 resumes you had just reviewed for an interview? What interested you about them? What skills or experiences did you highlight on the resume? If they spurred you to interview the candidate then you definitely want to delve further into the skills. You want to make certain that what the candidate says on his/her resume matches your expectations. Many times I’ve reviewed resumes where a candidate states that they have worked on a project with Xyz framework. I get excited because Xyz framework is one that we are using on the current project, or very similar to it, and its hard to find people who are skilled in this area. So, I start to ask probing questions to find out how much the candidate really understands the framework, and/or has used the framework. More often than not one of two things winds up happening from my probing questions:
- It turns out the candidate has only used a very minute part of the framework, and its not one that’s even very meaningful to me.
- The candidate indeed used the framework, but it was indirectly through a wrapper API that somebody else created.
People seeking jobs are trying to catch your eye so they can have a conversation with you to prove whether they are right for your job. Its just human nature to exaggerate your skills at times on a resume to get that initial conversation started. Resumes are really just sales materials, and as the interviewer you have to probe those sales pitches from the resume to see if you will really be buying what you expect.
Another key skill to interviewing is to tailor your interview questions to the type of position you are hiring for. This may sound obvious, but its easy to get hung up in asking interview questions aimed at your ideal candidate, who you want to work with for years and years. These questions really may not be appropriate if you are looking to hire somebody temporarily for a 3 month project. In fact, questions for short term candidates should probably be much more technically specific. You don’t have time to train them up on your current technology stack. You need the candidate to be able to hit the ground running. On the other hand, if you are hiring for long term positions you should probably de-emphasize specific technical skills and concentrate on general problem solving skills, learning skills, and team interaction skills. Technical skills certainly still matter for long term positions, but you have plenty of time for the candidate to grow into some of the skills missing from your ideal profile.
Problem solving skills are extremely important for any candidate I interview. I want to work with people who have certain degree of self-reliance. Asking questions is always important, and something I value too, but the ability to solve a problem when there is no one there to help you can be extremely important too. One of the questions I like to ask in this area involves handling vague requirements. I want to know what a candidate will do if handed very vague requirements. Will they probe for more information, or just try to make things up as they go along. I like to ask the candidate how they would handle the following scenario:
A manager comes to you with the requirement to build a web page to collect a customers credit card information. This is the only requirement you have been provided. What would your next steps be? How would you go about solving this problem?
I hope that the candidate will say that they would ask for more information. Perhaps the candidate will suggest proposing more specific requirements to review with the manager/customer/end-user.
In addition, I like to ask candidates how they would solve a critical problem at 3 o’clock in the morning that has no easy solution. Honestly, all I’m looking for on this question is what resources a candidate will turn to when there is not a readily available answer to the problem, and no one there to just provide a solution. I want to know things like would the candidate go to Google, Stack Overflow, technical forums, etc. to help them in solving the problem.
Remember to ask fundamental questions of all candidates. I like to ask questions about OOP like describe the difference between a class and an object, or between a class and a structure. Another fair question is to ask about polymorphism. Design patterns can be a good thing to throw out to the candidate to. Design pattern knowledge helps establish whether a candidate is aware of common development techniques, and is willing to look at other ideas besides there own. I also like to ask about the difference between a clustered and non-clustered index. Asking questions involving string building can be useful too. I like to ask a question about how you would build a string coming back from database records. I’m trying to determine does the developer know that strings are immutable, and that they should be using a stringbuilder instead. If I’m dealing ASP.Net developers I like to ask questions like how do you handle object state between web requests. I try to keep the questions steered away from super nit-picky things that can be looked up on the internet anytime if you need it. I’m more concerned with do you know these basic fundamentals that will help you in knowing what to look for online.
Finally in this area I like to know how candidates handle learning new technologies they have never worked with. I have never worked on a project where I knew everything up front. At my current client they have many technologies that no one locally has worked with so these learning skills become even more important. Often times candidates say they will just look at the code and try to figure it out. That can be a very dangerous answer with third party libraries that aren’t readily obvious in their use. My hope is that the candidate would talk about finding tutorials on using the framework and online forums to help in learning the best practices. The answers may be very similar to the question on handling the critical problem at 3 AM, but in a way that’s part of the point. They should indicate similar skills.
The final area I like to emphasize in my interview questions involves the types of teams a candidate has worked on. I want to know things like every project you’ve ever worked on has been 1 person projects. This may be appropriate if I’ve got a small budget and can only afford one resource. I might need somebody who can be completely self-reliant. On the other hand, if I’m working on a large project that involves many people that same candidate may not as ideal. They may just like to go solve every problem on their own, and be incapable of learning to work within the confines of a team. I want to know is this candidate somebody who is used to having somebody direct them technically, and receiving quality assurance bugs that may or may not seem like criticism to them.
In the end, an effective technical interview should not have felt like a game show to either the interviewer or interviewee. The best interviews should turn in to more of a conversation rather than a quiz. Even in a technical interview you should strive to determine whether the candidate is somebody you have a rapport with. In particular, if you are not the only person interviewing the candidate you may not know if other the other interviewers have covered any of these issues. Candidates you hire are people you will have to work with for some time so you want to make sure they are more than just encyclopedias of knowledge. You want to prove in the interview that they know what to do with that knowledge, and that they can work with you.