Before I start reading (and being influenced by) Joel Spolsky’s book about technical recruitment, I’ll share a thought on one important aspect of technical interviews.
Whenever I happen to be interviewing someone, there are three types of questions I ask.
First, the core questions. I’m not very much into computer science either, but you should know what a hashtable is. Or that your languages is statically/dynamically typed, and what polymorphism is. But they ask these questions everywhere.
Second, questions about abstract thinking. You should test how the candidate can relate concepts and layer abstractions. A question that I once asked is, after the candidate answered what SOAP and REST is: Map these two web-service styles to programming language types. SOAP=statically typed, REST=dynamically typed. But this is also not rare on interviews – there are plenty of “thinking” questions.
A third type of questions that are often asked are related to technologies that the company is using. You are using spring and hibernate – ask about session and transaction management. Using Swing – ask about layout managers. Even though the candidate have not used these technologies some interviewers often insist on the candidate trying to think of an answer. This is all not very good. Why?
Because programming is a profession where you are learning all the time. And there are so many technologies that you can’t be experienced with all of them. So what difference does it make that the candidate doesn’t know what lazy collections are, how A* works, or what options exist for distributed caching? It may look like the candidate does not have the knowledge for the position, but especially if he has done well in the other types of questions (noted above), then you should not worry about this – he will learn the technologies. Or will he? And how well? Here comes the type of questions I tend to ask. They are not about the technologies our company works with. They are about the technologies the candidate has worked with. Most interviewers go through the candidate’s resume just to understand the role of the candidate. I go through the technologies the candidate has used and ask questions about them. And then I get the answer – will the candidate cope with our technologies or not. If he doesn’t know very well the technology he has been working with most, then he most likely won’t be good with our stack. And if he knows “his” technology in good details, then he has had his interest invested in that technology, and is likely to go into the new thing that we’ll give him.
There is one caveat here – the interviewer must have good knowledge of a very broad range of technologies in order to ask good questions about them. But he has one advantage – he can prepare the questions before the interview. If the candidate has indicated experience with a technology you haven’t used, sit down and read a tutorial. It won’t take more than an hour to get into it enough to formulate some good questions (if you are a good interviewer, that is)
So to conclude – don’t expect candidates to know what you know. Expect them to know what they must know based on their experience.
Before I start reading (and being influenced by) Joel Spolsky’s book about technical recruitment, I’ll share a thought on one important aspect of technical interviews.
Whenever I happen to be interviewing someone, there are three types of questions I ask.
First, the core questions. I’m not very much into computer science either, but you should know what a hashtable is. Or that your languages is statically/dynamically typed, and what polymorphism is. But they ask these questions everywhere.
Second, questions about abstract thinking. You should test how the candidate can relate concepts and layer abstractions. A question that I once asked is, after the candidate answered what SOAP and REST is: Map these two web-service styles to programming language types. SOAP=statically typed, REST=dynamically typed. But this is also not rare on interviews – there are plenty of “thinking” questions.
A third type of questions that are often asked are related to technologies that the company is using. You are using spring and hibernate – ask about session and transaction management. Using Swing – ask about layout managers. Even though the candidate have not used these technologies some interviewers often insist on the candidate trying to think of an answer. This is all not very good. Why?
Because programming is a profession where you are learning all the time. And there are so many technologies that you can’t be experienced with all of them. So what difference does it make that the candidate doesn’t know what lazy collections are, how A* works, or what options exist for distributed caching? It may look like the candidate does not have the knowledge for the position, but especially if he has done well in the other types of questions (noted above), then you should not worry about this – he will learn the technologies. Or will he? And how well? Here comes the type of questions I tend to ask. They are not about the technologies our company works with. They are about the technologies the candidate has worked with. Most interviewers go through the candidate’s resume just to understand the role of the candidate. I go through the technologies the candidate has used and ask questions about them. And then I get the answer – will the candidate cope with our technologies or not. If he doesn’t know very well the technology he has been working with most, then he most likely won’t be good with our stack. And if he knows “his” technology in good details, then he has had his interest invested in that technology, and is likely to go into the new thing that we’ll give him.
There is one caveat here – the interviewer must have good knowledge of a very broad range of technologies in order to ask good questions about them. But he has one advantage – he can prepare the questions before the interview. If the candidate has indicated experience with a technology you haven’t used, sit down and read a tutorial. It won’t take more than an hour to get into it enough to formulate some good questions (if you are a good interviewer, that is)
So to conclude – don’t expect candidates to know what you know. Expect them to know what they must know based on their experience.
Recent Comments