Interview Question Advice Needed

Question

I am tasked with hiring some new programmers for my software business, and need to solidity on an interview approach. I have been thinking about one of two approaches and have listed them below. Does anyone have any advice on which approach might produce better results?

Approach 1: Asking several question about the syntax of a particular language that can be looked up in a book. Trivia-like questions, such as the difference between ref and out or what is the difference between session state and view state.

Or

Approach 2: Present several real world programming problems and ask the applicant to write some pseudo code right there on the spot. Stuff like, show me how to implement the state pattern for a particular scenario or implement a strategy pattern with a factory to solve a particular problem.

Answer 1

If I was the interviewee, I'd prefer Approach #1!

Answer 2

In my opinion, Approach 1 is the most common and the least effective. Most of what you'll be asking is trivia (as you mentioned), which is (by definition) unimportant. When conducting an interview, I prefer to focus on things that are, I don't know, important ;)

Writing code should be an integral part to any development interview.

Answer 3

Start with Approach 1. Ask simple questions. 10 mins is enough to see if it worth it to continue this conversations. If yes, by all means Approach 2. Moreover, give him a laptop and ask him to write real code.

Answer 4

The vast majority of people hate trivia questions, what if I haven't read that page lately

Approach #2 has a far better chance of success, but I would suggest going to www.joelonsoftware.com and look at some of his writings re: hiring programmers.

BTW, trick questions suck too - they'll actually turn off the developers you want the most.

Answer 5

Approach #2. But, start with a question you think is too easy, like reversing a string or sorting numbers without using the framework. And despair when many, many applicants can't answer it.

Answer 6

I have attended several interviews and conducted many interviews for my firm. Here is what I see is effective.

1. Ask some trivial problem solving questions. Do not ask "What" questions (like what is List? What is Linked List? What is Vector?What is Index?). These questions can be answered even if the participant has never really worked. Example, do not ask what is index, instead tell them a problem, I have a student table which has 10,000 students name in it, I would like to search for a particular student, how to write the select statement ? Once she mentions the select clause, ask her how to improve the output, then slowly can go into what type of index she used - bitmap or b-tree? or why? did she take care of cardinality etc etc...Get into more discussion mode.

2. Write some piece of code which throws NullPointerexception or some such known error. Ask the candidate to show where the problem is ? This will help you to understand whether she has seen code or have basic analysis skills?

3. Write some small class or method to do some small task like finding the min,max and average values from an int array or some such small thing like StringTokenizer ... and do not finish the code, ask the interviewee to finish the code for the methods. This will help you to understand whether she can code? Ask them to find out the runtime complexity of the code, can they improve it ? If yes, what dataStructure will they use? etc etc..

I have seen this method brings great results.

Answer 7

To me, it depends on if you're looking for a problem solver or a code monkey. Do you need somebody to take existing requirements then produce a design and implement? Or do you need somebody to code an existing design. If you just need the latter, then syntax is mostly your friend. Ultimately, programmers hired through #2 are likely to look up syntax in a book when required.

To me, #2 is likely to produce better employees.

Answer 8

Number 1 is okay if you provide the text book, but preferably Google, unless it's something you've specifically put on the job posting.

Number 2 better be pretty basic, or in an area that you've specified in the job posting because domains of experience vary widely, or again, you'll need to let them Google it. You're also looking for good design, use of remarks, style, etc.

Do both, and if they don't pass #1, don't give them #2. Save yourself some time.

Anyway, I'd kind of hate you for doing either, but at the same time, I'd enjoy showing off.

Answer 9

Well, be prepared for a few different results with each:

1. If you are asking basic trivia, you may want to consider whether or not to drill down further beyond the definition,e.g. instead of what does ref or out do ask when would you want this. There could also be cases where someone is taking what they believe to be educated guesses to try to BS their way through the interview that could be an issue here. Another aspect is how experienced are the developers you want to hire?

2. In the second approach, be careful that you don't simply accept a parroting of what a book like "Head First Design Patterns" may have for pseudocode in using a pattern. Being able to use the knowledge, write the code, explain why it works and why this is a good solution are all different aspects you want to discover.

Know what kinds of skills you want to see, what kind of attitude you want, etc. This may also help in weeding out the undesirables.

Answer 10

Approach 3. I would use something like: http://codility.com/

You could spend 3-5 minutes with very basic questions like ( for instance for a Java programmer )

Is javascript the same as Java?

And if the candidate passes the most elemental questions, you can have him doing the test:

The application is very easy to use and have good instructions for anyone to use.

This is the test screen.

Answer 11

I would definitely go with #2. I think you will get a much better feel for the type of work they will be doing on a day to day basis this way. While someone knowing some obscure trivia type questions might seem impressive I don't think that its as helpful as actually seeing how they would approach a problem and implement a solution.

Also, just because someone doesn't know a trivia question doesn't mean they won't be a great programmer. These types of things can often be Googled (or StackOverflowed if you will) in a few seconds anyways, let them save their brain for more important stuff!

Answer 12

It has to be a mix of the two approaches. Approach 2 tells you whether he can find solutions Approach 1 tells you whether he has implemented solutions in the past (very important practical aspects)

Asking him syntactic (approach 1 style) questions around his past work, and asking him real world, analytical, problem solving (approach 2 style) questions, around the work he will be doing in your team is a good idea.

As has already been suggested. Codility.com is an awesome tool esp. for phone screening. Otherwise insist on writing (near) compilable code instead of pseudo code.

Answer 13

If you really want to hire talent, you'll make the interview 5-6 hours and do both 1 and 2 and more.

You didn't say what area, so I'll go with mine - databases.

I don't ask what, I ask how or why. Everyone seems to know that indexes make a query faster. To most people how they work is sheer magic. Which in turn means that when they fail to improve results, they are baffled. Draw one on the board, what's an index look like.

What kind of indexes are there and how do they differ? What kind of table are there and why have you used them in the past.

Then after that, I do logic problems. Frogs jumping on light switches, weighing 9 coins on a balance, stuff like that. I watch for what they do when they're completely lost. Do they clam up, do they actually enjoy it. Can they talk it through with me? Do they remember hints I've just given or do they keep going down the same dead-end? Can they think on their feet, aloud, under stress.

Answer 14

The codinghorror article here is a good wide-band article on this, not to mention the legendary fizzbuzz.

Answer 15

Both. The first is what you do in a phone screen to weed out the applicants who fibbed on their resumes. The second is the time-consuming approach you take on a 2nd or 3rd interview.

Answer 16

Add some open-ended conversation

For the Q&A part of an interview, I think a conversational approach can be good.

For example, if you're hiring a web developer, ask a question like, "When you type Google.com in your browser and hit enter, what happens?" Their answer could be as simple as "it loads that web page" or as involved as DNS lookup, IP routing, HTTP headers and cookies, server load balancing, caching on both ends, requests for related resources, page rendering, etc.

You can probe different areas with follow-up questions to see how deep they can go. If they know more than you do in some area, great! If there are obvious deficiencies, you'll notice. There are always more layers to the onion, and nobody knows everything. In fact, you should preface the question with "you won't know all of this - heck, I don't know all of it - but I'd like to get some idea of your knowledge." That way they don't necessarily feel like they're failing if they're weak in one area but strong in another.

Some things I like about this:

• It's non-confrontational. If the candidate obviously has shallow knowledge, you don't have to keep probing.
• It allows for "extra credit" - you can tell "OK" from "fantastic," unlike a right/wrong question.
• It's conversational. You may get to see the candidate get excited about something he/she knows well, and you may get to educate one another about something interesting.

Credit: Michael Gundlach gave me this tip.

Answer 17

Face-to-face, there's no point asking about syntax directly - I've seen several candidates pass that and then turn out to be hopeless. Getting them to solve a real (but doable in an interview) problem is much more revealing, especially if you get them to talk through their thought process whilst solving it.

If you can arrange it, take a laptop into the interview with their IDE of choice on it, and get them to code it in front of you (you can do this as a pair-programming exercise if you're into Agile). This shows you how well they really know the IDE, syntax, and framework as well as their problem-solving ability. The people that I've done this with and that enjoyed the experience were by far the best candidates.

Answer 18

I suggest you have them complete a code test. Then on the interview pair program with the interviewee, adding new features together to his code test. You should get plenty of info on how he/she is to work with from this.

Answer 19

Not all "I could look that up" questions are trivia questions. For example:

• What are the visibility modifiers in C#, and what do they mean?

Even if you can rattle them off (public, internal, protected, protected internal, and private), that doesn't mean you know what they do. For instance:

• Have you used internal to hide classes that other projects using your library don't need to see?
• Have you used protected to allow you to override the base class behavior of non-public members?

Whether you can describe what internal and protected do is a good indicator of whether you've done a lot of object modeling, or you're just writing procedural code that happens to be wrapped in classes.

Similarly for ref and out. If you can't explain what effect ref has, particularly when you use it on a reference-type parameter, you probably don't have a correct understanding of how objects work in C#. (You probably think, for instance, that when you pass a Customer object to a method, it copies the object.)

Now asking questions about specific class members is often trivial. No one cares whether the member that makes a Windows Form the topmost is called TopMost or FormOnTop or MakeUppermost. You can look that up on the rare occasion that you need to use it. But language concepts like those I've mentioned above are things you use every day of your development career, and they're the opposite of trivial.