Different interviewers have different styles of asking questions. Especially when it comes to technical interviews, the interviewer usually has more freedom to decide as to what qualifies as a good question. In this post, I would like to talk a little bit about what I think makes a good question.
In the wide spectrum of interview questions, we can distinguish three different areas that interviewers like to test: fundamentals, technology-specific issues, and problem-solving skills. Depending on the interviewer's style, you may see more or less focus on all three areas. Let's take programming as an example. Questions about fundamentals (i.e. theory) involve topics like object-oriented programming, recursion, data structures... etc. Technology-specific questions on the other hand tackle things like garbage collection in Java, delegates in C#, pointers in C++, update and draw in the XNA Framework .. etc. Lastly, to test problem-solving skills, you see questions that combine the application of fundamentals in solving a relatively abstract problem such as finding all the possible moves in a chessboard.
So, the question is how much focus should we give each of the three areas to determine if the candidate is a good fit for the job (technically speaking)?
Fundamentals
Fundamental questions are important because they tell you something about the background of the person at the other end of the table. If the person cannot tell you what a class is, or what we use inheritance for, then maybe they are interviewing for the wrong job. Having said that, I believe that we generally overdo it when it comes to this part of the interview. I honestly don't see the value of asking detailed questions like how the OS handles memory allocation and what the difference is between inner join and outer join and the like.. I know for a fact that many interviewers love to delve deep into such details but I think it is an utter waste of time, and even a risky approach. If an interviewee knows all the theory behind programming and databases, that does not tell you anything about whether they are a good programmer or not. It merely reflects their ability to recall information they read in textbooks. And using this approach you may run the risk of losing excellent candidates who do not necessarily have this information readily available in the back of their mind. I have seen many individuals who understand the theoretical concepts very well, but they simply cannot put labels on them. My 1-year-old boy just started to understand the physics of gravity. He knows that if he pushes my laptop off my desk, it will land on the floor (maybe in more than one piece.. but that's another law to learn). But does my son know that this is called gravity? Even long before Newton, people knew about gravity, and they used it in practical applications. But it was Newton who put a label on it and studied it in more detail. And it is really difficult to claim that no one before Newton understood physics because they didn't know the term 'gravity'.
To conclude this part, my recommendation is the following. Use some general fundamental questions as a quick filtering mechanism but don't go deep into any details.
Technology-specific questions
Avoid those at any cost. Unless you need to hire someone with a very specific experience in a certain technology, you want to try to stay away from language-specific or tool-specific questions. For example, if you need someone to maintain a SharePoint server, then they better know something about SharePoint. But if the scope of the job is not that specific, then what you should really be looking for is the ability for the candidate to learn on their own.
But how do you do that? Simple. Ask the candidate to accomplish a specific task using a technology they have never used before. Provide them with all the things that would be available in a real life scenario (e.g. API documentation, access to the internet .. etc). And see how much they can accomplish in a given time frame. You will be surprised by the vastly different levels of learning abilities of your candidates. This kind of exercise is also an excellent way to test their research skills, as well as their stress and time management skills.
In conclusion, what you want to avoid is rejecting a good candidate because they have been using C++ and C# instead of Java for the past five years.Or because they are used to an IDE to build and run their projects instead of a Linux command line.
Problem-solving questions
This should be the main focus of your interview. However, the objective of a problem-solving question should not be to test whether the candidate can reach the correct answer. Simply because if a candidate has heard or read about the question before, they would have a significantly higher chance of getting to the right answer than someone who did not. Also, how you phrase the question might lead different candidates into different directions. What you really want to look for here is whether the candidate is capable of analyzing the problem and communicating their thought process. You want to see if they are able to apply the fundamentals (e.g. recursion, arrays .. etc) to solve the problem at hand. Ask them follow up questions as to how they could improve a given solution, or whether there is a better way of thinking about the problem. Stimulate their brains, and don't hesitate to give hints or put more obstacles depending on how well the candidate is doing.
To summarize, this part of the interview should give you and the candidate a chance to communicate at an intellectual level. The onus is on the candidate to demonstrate that they are capable of using a number of leads to head into the right direction of thinking about the problem at hand.
Finally, as an interviewer with a hiring authority, you will find that it is very tempting for you to show off that you know more than the person in front of you. Interviewers usually like to have fun in interviews by asking all kinds of ridiculous questions and maybe discuss controversial topics. There is nothing wrong with that as long as we draw a clear line between having fun and getting the job of hiring the best candidate done.
No comments:
Post a Comment