What are effective interview questions? [closed]

Question

What questions will validly judge an individuals skills as a programmer? These should be applicable to a programmer using any language, and they should be aimed at entry level positions possibly questioning a recent graduate.

We're all aware of the various types of questions that interviewers ask, but specifically, which ones most effectively assess the real performance of an employee on the job?

Answer 1

Explain a linked list to a 10 year old.
Explain OOP to someone who doesn't know anything about programming.

Being able to communicate is important in most jobs. Programmers have the difficult task of explaining complex technical concepts to non-technical people. Questions like this test (to some degree) an applicant's ability to do that.

Answer 2

Give them a computer, a text editor and ask them to write some code in a suitable language that performs a common function like strstr()/string.IndexOf(str), itoa()/int.toString(). You choose - best to have a number of options if a newbie isn't familiar with the function.

Leave them alone for a few minutes to do this. The language doesn't really matter - something appropriate will do, as long as no library calls (at all). It doesn't have to compile and run - but you could do this together when they're done, just for kicks. Obviously, no access to the web for this exercise.

This should demonstrate:

1. Can the candidate write code at all.
2. Can solve programming/algorithmic problems. If they're nowhere near a reasonable solution, no point in continuing the interview.
3. Do they write maintainable code? Do they demonstrate an understanding that other team members might adapt their code?
4. Is there any consistent style to the coding? It doesn't have to match your in-house style, but do they write consistently-styled code that is easy to read.
5. Can they talk through their code? Do they get too defensive when you critique it? How do they respond to feedback?

Using this technique I have identified:

• Candidates that can talk their way through the interview and then crumble when asked to write code.
• Candidates that bought in print outs of someone else's code as an example of their own work.
• High-scoring graduates that couldn't get their head around an 'isUpperCase(char)' function.
• A guy who got aggressive and then then threatened the HR person and I who were interviewing him once we started to work through his code, giving him feedback on different approaches.

Answer 3

There's a really simple one that is sure to do the trick...

Ask the candidate about their previous projects.

Make the interview more of a conversation, and less like the SAT's.

Ask them what they did. Describe the parts of the project they worked on. Their responsibilities. Use follow ups to ask about what technologies were used and why they were selected. How code was arranged. How they tested. Design mistakes and what they'd do differently. Basically, learn why they made the decisions they made.

If a competent programmer is doing the interview it is very easy to separate the candidates who know what they are doing from the buzzword shoveling posers.

Answer 4

FizzBuzz

From CodingHorror, originally from Imran on Tech:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

When I first read the claim that over 99% of applicants to the average programming job can't complete this, I honestly didn't believe it. I ended up working at a small company that asked me this question, though, and talked with the CEO later; he told me that those statistics hold true.

As such, this is a great question to weed out a large chunk of applicants. It's short enough to make them do it on paper if that's all you have, and simple enough that a college kid should be able to code it after their first intro to programming course.

Answer 5

Design a hotel registration system.

The question is intentionally vague, since the point is to test the candidate's requirements elicitation abilities. Figuring out what a customer wants is non-trivial. So, the candidate that does well starts out by asking a pile of questions: "Ok, what functions does it need?" "What is your process like before this system?" "What types of users will be using it?" etc, to which the interviewer can make up and/or have prepared answers.

A good candidate:

• Avoids making assumptions about functionality, technical resources, users, etc
• Doesn't talk about specifics of implementation, but just what it needs to do.
• Asks good questions to draw out information.

Answer 6

A very interesting question and I am eager to see the answers to this. I think most of the times Puzzles/Algorithms and language knowledge are overrated.

1. Also the concept, I want to see how a candidate ATTACK's a problem is also overrated. Most Interviewers also say that if you have already solved this problem let us know so that we can give you another problem because all we are interested in is your approach. This is Bullshit. For eg. Ask yourself the first time you wrote a Program to write all possible permutations of a word recursively, how much time did it take ? 20 min, 30 mins ?? I bet a correct program took more than that,So if you are doing it for the first time in an interview and taking 30 mins to do it, I bet MOST Interviewers will run out of patience. What can be tested out of these puzzle questions is that whether someone knows these type of questions or not, someone who knows/practised these questions will be able to solve similar problems in Projects if needed. So in some cases if someone is not able to solve such problems doesn't mean he is NOT SMART he might not have practised enough.

2. Language concepts ? In my opinion these can be applied to most general concepts. If someone doesn't know an obscure concept in a language doesn't mean he is not good enough. If he knows the most popular concepts, let him in.

3. Approach ? how do you judge it ? What if someone is faking it ? For eg. it is not uncommon to see many guys in an Interview not being able to solve problems but when you want to move to something else, they have that AHA moment and seem to solve it instantly :) Also the smart programmers will always first give O(n^2) solution and then will keep on thinking and then give the O(n) solution, Most of the times they know both on the first hand they are clever enough to show that they are thinking through it :-)

I generally ask people to solve known or similar problems and ask them to write the code. I am mostly interested in how the Code looks at the end of the problem. Correctness of the solution/code quality/corner cases/ exception handling/ null references etc are what I look at. Sometimes I dont even mind telling the O(n) solution :-) the code is what matters to me. Also I like people who have a breadth of knowledge, these are guys who have been READING they will be able to research various technologies for you and come up with the best thing for the Project. Just my opinions though may be you hire a Mainframe guy differently.

Answer 7

Given a linked list with a loop in it, how would you measure the length of the 'stem'- the part before the loop starts?

This could really be replaced with any algorithmic question. What it needs is:

• It can't be one with a well known solution (eg, how do you detect a cycle in a linked list)
• It can't be too complex to do in an interview (eg, Facebook's Puzzles)
• It should have a few different solutions of varying complexity (this one can get down to constant space, linear time).

The point is to see how the candidate attacks the problem and thinks through it. Realistically, very few programming jobs (in my experience) really require much algorithmic analysis; rather, it's there to see if the person doesn't give up, and can keep finding new avenues to explore. Even if they don't get the question, do you think they'd get it eventually, or would they say "That's the best I can do- I'm stumped?"

Answer 8

One test I had which worked quite well was to given, on hard copy, a small program and the task was to determine the output of the program. The program implemented a linked list, added a set of values to the list then traversed the list outputing the values of each node. The catch was that the linked list implementation didn't behave in the standard way, it added new items to the front of the list so that traversing the list would output the values in a different order to the order they were added.

This would sort out people who can really read and understand code from those who jump to conclusions.

Needless to say, it didn't catch me out as I used the boxes-and-arrows method to track the behaviour of the linked list.

Answer 9

One question I have found very revealing for entry level is to ask the candidate to implement a blocking queue of objects.

I always try to get them to do it on paper. It can be in the language of their choice (or one of the languages they claim to know, or pseudo code, depending what want). This way less time is wasted on the syntax or exact names of the language/api features and more is focused on the choice of algorithm. They can even invent their own language features to allow them to do it if they can't remember.

I realise it is a textbook question, but we are usually recruiting people who will have to work on code with large amounts of concurrency. I have generally found that most people that cannot answer effectively also cannot answer the other more advanced and in-depth questions about how to deal with concurrency.

Answer 10

My favorite question to ask is "What are you passionate about?" or "What do you do in your spare time?". It doesn't have to be technology, programming, or software development. To know they have or are capable of being passionate is something that I have seen time and again that separates the great developers from the rest. The people who go to work to earn a pay check do not generally have much to fall back on here and can't fake it. The people who generally have something they are passionate about are very excited to tell you all about it.

Answer 11

I take real problems we had in the code and ask them in the interview. This way I have before and after code, it's already worked out and it's typical.

If you can solve the sort of problems we run into in an interview, it's a dead certainty you can do it every day.

This presupposes you have a bug tracking system tied to your VCS and make sensible commit comments; which we might term "wearing pants" in a work context.

Answer 12

How would you solve a problem you've hit a brick wall with.

Every programmer every now and again doing interesting work will hit a wall with something that goes beyond their experience and ability to independently think around, a decent programmer will have come across this and know how to deal with it.

Asking a coworker is the first and best answer but must be backed up by follow-ups like, MSDN/PHP Docs or whatever the authoritative documentation for your language/framework is, stackoverflow, MSN to old colleagues, twitter - the more the better.

I always ask this one and it gives good insight.