What Questions an Interviewer Should Ask
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.
The interviewer have to find where the candidate’s passion lies. Good questions are ‘what was the last interesting technologies you’ve learned to work with’, ‘interesting problem you’ve solved recently’, as well as questions about spare-time projects. This way you’ll know if the candidate is learning all the time, or just know some programming language and do his job. Good question is to ask the candidate to solve a problem without giving enough constraints. And good questions are those, that have ‘Why’ in them – not ‘what is X’, but ‘why X is used in situation Y’.
Absolutely agreed. But that’s when you are looking for the “top developers”. If you are looking for someone “to do the job”, these are not always applicable.
You know the worst part is that 80% of developers (within the company/project budget) don’t know the basic concepts of Java and have been spoon fed with the pudding created by the heroes of the project.
I try to ask the so called not so important overloading/overriding questions for 10 minutes and if it goes well then only continue the interview otherwise within 10 minutes: bye bye!
Map these two web-service styles to programming language types. SOAP=statically typed, REST=dynamically typed.
I find this question really confusing. It might be good for spinning off a discussion related to web services and type systems (or programming language holywars for that matter), but the resemblance between web service implementation strategies and type checking is too hard to define univocally. I’ll give just the first couple of questions that popped into my mind as an example:
Statically typed languages are checked for type errors during compile time, while dynamically typed are checked during execution time. What is the analog of compile/execution time for WS? Time when the URL to access an endpoint/resource is constructed? In this case a properly designed REST service doesn’t even give you a chance to construct invalid URLs (given you are using a valid entry point). Or do you mean the payload passed into the endpoint/resource should be ‘type-checked’? Then there is no compile-time check whatsoever.
The correct answer is related to predefined contracts – statically typed languages and SOAP services have a strong, checked contract, while dynamic & REST do not. But any reasoning and interpretation of the question will give you credits.