We have a list of the best interview questions people have been asked and the worst interview question you've been asked but what question do you believe sorts the chaff from the wheat?
One you've been asked, one you've asked or one you wish the co-worker from hell had been asked. There's no magic bullet but is there one question you think helps the process?
How many tables are needed for a many-to-many relationship in SQL? Or another way to say this is. Create a schema on paper for a many-to-many relationship between Students and their Courses.
If the applicant just looks at a diagram that shows --- they will think this is all that needs to be done. When the obvious answer is 3 tables.
No interview should only include technical questions/answers, but for developers in this day and age, you do really need to ask questions to make sure that they can back up the knowledge they claim on their resume... WAY too many people bending the truth these days not to do it.
It depends on the technology, but a few off the top of my head:
For example, assuming they knew that C# had a different use for "new":
public class parent
{
public void myFunction() { }
}
public class child : parent
{
public void myFunction() { }
}
Given the above code, will it compile (yes, with a warning)? How do you clear the warning (add the "new" modifier to the child function definition)? When would the parent's version of the function be called vs. when the child code would be called?
I think asking someone what they do in their free time to better their understanding of technology is a good one. It is definitely a positive sign if they read blogs, contribute to open source, or tinker with projects. Beware those who can come up with nothing they do in their free time related to technology.
C#: If they say they've been using it for more than 3 years, drill them on the "new" keyword, in the polymorphic sense.
I am not even sure what you mean @Greg, and I have been using it for close to 7 years now. :)
I think direct correct answer questions aren't that useful. It's relatively easy to memorise bullet points about a language or framework before an interview.
I usually ask questions that require a bit of thought to answer by the applicant.
Things like:
What do you do to stay current in software development? Elaborate.
From this question, I'll be able to judge how passionate they are about SD. Did they say books? Blogs? Forums? Then refine, and ask which ones. What particular passages/posts/threads struck an interest for you?
I'm not sure if just asking questions can really weed out the bad candidates. It's very easy to learn a bunch of stuff to do with .NET and C# for example and repeat it in an interview. In fact there are literally thousands of sites listing "interview questions and answers" that are easily googleable.
I personally think you learn more about a person's abilities by giving them a programming task to complete. Nothing too hard but enough to stretch them, they don't even need to complete it but at least show how they approached the problem and what depth of knowledge they have. If it's possible to actually sit with the interviewee and get them to talk through their approach to the problem as they go, with you asking questions along the way, you not only get an idea of their technical abilities but also how they communicate and if they are likely to "fit in" with the team.
If that isn't possible for whatever reason then I would suggest more open-ended questions and scenarios to get them talking rather than strict question/answer.
I actually find how people use language is one of the best indicators. When interviewees avoid technical terms and cultural/community lingo, I usually associate that with limited experience or a lack of confidence. On the other hand, jargon bombing is a dangerous sign as well. Much like the old adage that if you can teach it you know it, anyone who can keep up a substantive conversation on a technical topic, like you would have with a successful teammate, without being lead is strong candidate.
What is an SQL Injection attack, and what are the various means of protecting against them.
Any of the following might be good:
I can't find it at the moment (I'll do some more searching in a bit) but I recall someone's blog post a few months ago where the writer simply asked the applicant "what bothers you the most about other people's code" (or something along those lines).
The gist of it was that the "bad" applicants almost always would point out things like code formatting, and maybe slight syntax differences. The "good" applicants would point out things like what patterns could have been used, the KISS principle, etc...
This one has always stuck with me, and I've actually been asked it a couple times (maybe worded differently)
edit here is the blog post I referred to: The Perfect Interview Question
IF the candidate is relatively young, or just out of college: I would ask a candidate to see some projects / code that they have worked on outside of work. If they can produce that, you know that coding is more than a job; rather it is something that they enjoy doing, and probably excel at it.
@Greg
Given the above code, will it compile (yes, with a warning)?
What warning?
Checking knowledge of new vs. override is one of the things that I ask. Sadly, many .NET developers with years of experience can't answer the question.
This article, entitled "The Five Essential Phone-Screen Questions", by Steve Yegge, is a good read.
A former boss used to ask what I thought was a very simple programming question: Write a function that swaps the two bytes of a 16-bit value. About 75% of the people we interviewed couldn't do it.
Another "simple" question: What is the hexadecimal representation of the decimal number 13? Most candidates had no idea, including a candidate with a Ph.D. in Computer Science.
These candidates were applying for C/C++ embedded-systems development positions, so low-level questions about bits and bytes shouldn't have been considered tricky.
On the StackOverflow podcast, Jeff and Joel suggested that as an interviewer, going in having no set questions but just running through the resume is a bad thing. But in my role, I'm usually the technical interviewer, and I like to do just that -- I want the candidate to explain, in their own words, the architecture of each project they have worked on, and where the good, bad, ugly aspects of the architecture and the code were, and what they would do differently.
The other thing I am always listening for is a real understanding of OO principles. I have found that if someone has used interfaces, inheritance, etc. in their work, and knows intimately how to use them and talk about them, that is a sign that they have a really good grasp of software development in general.
This is the approach I use for interviewing junior to mid-level developers, and I have had a really good track record with it succeeding.
I've found that when in the situation of having a Human Resources person and a techie / IT manager etc. it can be effective to alternate between HR questions and IT questions. This can be a good way for the candidate to shine or alternatively come unstuck if they've been hanging on with their up to this point memorised list of ASP.net-isms.
I think that there are two things that quickly determine if the person is someone that would be good on our team.
How do you keep current with your skills? Name 3 examples of something you've done in the last few months that shows that.
Explain the difference between a class and an interface. What is polymorphism and how does it relate to those two?
There are other technical and personal questions, of course, but if I don't really get good answers to those two, the interview doesn't go very much further.
The first question is vital. Too many people allow their skills to get stagnant. The kind of person who is always seeking to make themselves better are the kinds of people that you can expect are going to give you a little something more.
The second question crosses many language boundaries and since OOP is at the core of almost all current language technologies, it tells you if the person has actually done any real programming in the past.
I'm interested in whether a candidate is a good engineer, as well as a programmer. I ask two things that make it clear whether the candidate is real or not:
"Give me an example of something you did that turned out to be a mistake, how you fixed it, and what you learned."
I'm really only interested in what they learned: learning from our mistakes (bugs, design problems, deployment issues) is critical. I find only about 1/3 of candidates have a good answer. Nearly 1/3 haven't learned anything!!!
Next, I'll pick something "big" from their resume and ask them to describe it in detail. Often this shows the real deals from the ones with the padded resumes.
Only after all that will I bother with the technical questions. If they fail on the first two I'll end the interview.
I think that the type of question that you ask is likely going to relate to the level of the position you are interviewing for, but there are some general questions that you can ask that should apply to all levels. For example:
Then, depending upon the position the person is being interviewed for you can start looking at more specific technology based questions. However, as some other posters have pointed out, just because you have been working with a language for awhile doesn't mean that you know everything about it, so you should be a bit forgiving if they don't answer everything off the top of their head.
Finally, I think that the ultimate interview question is to have the interviewee sit down at a workstation that is configured the same as they would be working at on day one and have the write a simple program. Ideally, the program would have some component in it that they need to look up so you can also see how they react when confronted with something they don't know off the top of their head.
"What books have changed the way you work and why?" is a favorite of mine. Since so few developers seem to read books these days actually getting an answer to that question that has any depth will be a good start for determining sheep from goats, so to speak.
A great indicator is the length of time people spend answering open-ended questions.
E.g.
If they are still going after 15 mins then you have a winner :-)
What programming projects have you done that are not on your CV?
If the answer is none or school projects only, this person is probably not passionate about programming. All good programmers I know have made dozens of various scale projects in their free time, some of which they might have even forgotten that they ever did.
Explain, generally, what the differences are between a value type and a reference type.
rp
Ask fundamentals about the internals of basic data structures or constructs within the language (or languages) that applicant is expected to know. "Writing code" over the phone is tricky but a lot of the basics can still be covered. Understanding Hash Tables, Binary Search, and a sense of run-time efficiency are good examples.
If given the opportunity for a face-to-face screening: Ask an open-ended design problem. That is, do not simply ask the candidate to "Make a class with member A, B and C that does X". In other words, instruct the candidate to write a class that satisfies a list of constraints. Even if the open-endedness of the question leads to confusion, how the candidate seeks clarification and thinks through the problem, when it is presented in this way, can be very revealing.
I don't bother with obscure language questions or general CS knowledge unless interviewing someone with very little experience. Instead, I go through their resume and for each significant "achievement" such as "wrote a whizbang processor in language foo" that they list I ask the following questions:
In general:
[I prefer developers over code monkeys]
I haven't tested this on anyone but I think you can weed out a bad applicant for a coding position simply by asking to implement an iterator for a tree data structure.
Possible responses would be..
Strangely enough: in the language of your choice, write function to solve
For instance: given two arrays, return an array containing all elements common to both arrays.
Great: solves it efficiently (O(n) solution, assuming proper hashing) Good: solves it better than brute force O(n lg n or better)) Eh : solves it with an O(n^2) loop (better than nothing) Bad: manages to botch it in some way unimaginable.
While the above is admittedly a very simple question, it's surprising the number of people who can't solve it. If you have a clue, you solve it in < 5 minutes and we move on to better topics. If you can't, it's telling.
Two questions that our company tends to ask is to write a random number (<100) in binary and after that do the same in hexadecimal.
It is surprising to see how many applicants cannot do this, though it's one of the most basic things that a developer should know (as in, have learned it in uni but not necessarily use in their daily job).
I had an applicant once who looked fine on the CV, and then I asked him this:
"In any languge you would like, write a function that takes a string input and returns the same string reversed."
My plan was to look for things like forgetting about terminating /0 chars, would it work with a zero-length string, unexplained oddities of approach, and even if they got everything right asking them if they could see the bug in their code just to see what they would do. It worked great.
This one guy, however, turned up, and actually just plain couldn't do it. At all. Had no idea where to start. Couldn't even write a pseudocode version. It was excruciating (especially for him; I made him suffer at trying it a bit.) My associate said to him "You do know this is a programming position, right?".
It was surreal, and shows how you can't trust a CV at all.
What's the difference between an interface and an abstract class? Why would you use one over the other?
That one right there eliminates half the people. It's so basic too.