Ask real-world problems

We have set of pre-compiled questions and tests asked to each candidate to see how well he meets minimum requirements for position. We expect good understanding of the required technical topics.

We start our face-to-face interview (after a pre-screening phone interview(s) of course) with a question on what are the interests of the candiate, and continue with basic fundamental questions and then adjusting the level on how deep we would like to continue with that topic.

Our guidance in technical topics is candidates resume. Thus, spending 10 minutes to read resume before interview is more than important. We try to check important stack of technologies by real-world daily routine questions, that only hands-on experienced candidate may have glue about.

I would suggest to combine some real-world problem solving questions and try to see how candidate reasoning of problem work. If candidate answers honestly, and saying he does not know topics that we ask, we really appreciate honesty and not bullsh**ing.

As an example: if some candidate claims 6+ months of work with jQuery, but can not explain what is "selector", i would just stop asking further. Because, power of jQuery is coming from good understanding of selectors.

Same thing holds true for other topics like indexes in Database. If someone memorized what is cluster and non-cluster index is, but could not give proper explanation when and where we need indexes, by claiming 2 years of experience in DB development then everything is clear.

What I mean is not just collecting good questions to be asked I am
asking about strategy for evaluating a candidate and find out if he
really good or just just studied well questions and answers.

Well, if he studied the right questions/answers, that’s already a plus for him.

Then, there’s this: http://www.codinghorror.com/blog/2012/03/how-to-hire-a-programmer.html

But, you know, that might not be the right strategy for you.
What exactly are you looking for? Is it someone who has a lot of experience in a certain technology and knows its gotchas or someone who can adopt to new things quickly? Or someone who’s creative and can think outside of the box?
When you realise what you need, it shouldn’t be too hard to find the right questions for the candidate. If you’re looking for questions on the internet, and are concerned that someone might actually learn the solution by heart (or something silly like that), you can always modify it a bit, or come up with your own questions.

Having said that, you shouldn’t expect too much technical knowledge from a junior developer. Just make sure that he’s bright and interested.
When it comes to senior developers, they should already have a lot of experience, so you can always ask them to talk about what they’ve done before.

Consider studying Programming Interviews Exposed, 2nd Edition by Mongan, Kindler, Giguère.

Chapters 3 through 11 are strongly recommended reading for interviewers – these give an excellent reference on how to do technical questions. These chapters also make good reading for hiring managers – to get an idea of how much effort might it take to prepare a good question.

I would avoid rote, memorization type questions. IMO, all they tell is whether or not the programmer has hit that particular situation before or if they found the “right” question to study ahead of time.

Providing technical problems to solve is a good approach – it gives you an opportunity to see how they solve new problems and what their approach will be. Pick something related to your program’s domain. The difficulty or scope of the question can be scaled based upon the position you are hiring for. Junior developers should have questions that you would expect them to be able to solve. Senior developers should get the more challenging, open-ended type questions since you would expect them to lead product development.

To gauge personality, I’m a big fan of behavioral based interviewing. Instead of asking “what would you do” it’s asking “what did you do?” Since it’s from the past, all the candidate has to do is recount what actually happened they don’t have to think through a situation and determine what is the “right” answer. It’s okay for candidates to bring up bad situations they were in so long as they explain how they would do things differently the next time. BBI is a great way to figure out if the candidate is going to be a good fit for your team. It does take some practice to get used to, but it’s the best technique I have found to understand the candidates personality.

Have them write code on a whiteboard or on paper for something like
1. Reverse a linklist without using built in method in the java/std/.net API
2. Design/Create a stack using a linklist. For this they will need to understand some design patterns.

The two main points to consider, in my opinion, are these:

1. Is the candidate a good cultural fit?
2. Can your candidate program?

Nobody wants a great programmer with an ego twice the size of your company (at least not if you’re going to have a team of developers) or someone who’s too shy to share ideas with others. And even the most likeable person is rather useless to you if they can’t program their way out of a paper bag.

Cultural questions are ones you’ll have to decide for yourself; after all, it’s your culture the candidate needs to fit into.

As for programming questions, I recently had a good interview with some guys who gave me a FizzBuzz test (or maybe try some alternatives) while asking me a bunch of other questions. Sometimes it’s good to see how candidates perform when you take them out of their comfort zone; this can trip up even some “senior” programmers. The last time I interviewed candidates, I put some intentionally bad code in front of them and asked them to point out how it could be improved. The point of FizzBuzz questions and code-on-paper type questions is to weed out “pretenders” who are good at theoretical programming but can’t perform when they have to write or analyse actual code. It can also stump veterans who are too used to writing code exclusively with their favourite IDE and forget the pen-and-paper basics. How much you read into their performance is up to you (in my case we hired a guy who drew a complete blank when looking at the code sample, because he did really well in all other questions and we could tell from other questions that he was technically quite capable).

Whether you’re interviewing for a junior or senior developer role, I would also recommend not wasting too much time going into detailed questions about specific technologies. Once you know they’re technically good programmers (with good core Java skills), and have made sure they didn’t just put buzzwords in their resume without really knowing anything about them, you should be confident that they can pick up skills in the relevant frameworks relatively quickly. If you can program, you should be able to program irrespective of what technology stack is used.

Last but not least, go with your gut instinct and try to see past artificial facades interviewees tend to put up.