Are algorithm questions good interview questions?

Question

I've had an argument recently with a fellow programmer. He was interviewing for a new position and was asked this question:

Give a sequence of numbers starting at X and ending in Y but with one element missing so N is Y-X-1, find the missing element in O(N) or better.

Now, the answer is irrelevant here (but interesting). This started a discussion on whether this was even a good question to ask during an interview.

One side: Algorithms are an inherit part of programming and a candidates ability to answer this question supports that this candidate will be a good programmer and be able to solve larger problems and can handle most programming tasks which are ultimately easy to understand and answer.

Other side: Writing algorithms from scratch is rarely used in modern programming and therefore is irrelevant in the bigger question of whether the person will be a good programmer. A person could successfully answer this question yet still not be able to do more common programmings tasks.

Your thoughts? Good interview question or not?

Answer 1

I agree with asking a algorithm question, but I disagree with insisting on a specific big-O quality level.

Asking this sort of question is interesting to see how the person approaches the problem and what pitfalls they consider in their attempt, but unless they are writing something insanely incorrect or inefficient the actual detail of what they write is not as telling as the fact that they get through the problem solving / design steps in a coherent manner.

I ask a similar question, but the people that I have had the best luck with after hire are the folks that gave flawed answers but had the correct idea in their approach.

Answer 2

I would disagree with the idea that the ability to write algorithms is irrelevant in the bigger question of whether the person will be a good programmer. Even if he never has to use it, (which is doubtful,) it still shows if he has the mental flexibility required to work out a logical solution to a problem that's more complicated than a simple set of requirements that's already written up and laid out in detail by the client.

I'd definitely not want to hire someone who doesn't know how to think and analyze. That's what makes the difference between a code monkey and a computer programmer.

Answer 3

I have several algorithm-like questions that I use on a regular basis, some of which are very difficult. I use them to see how they mentally attack a problem and to see if they grok certain concepts. (I've seen way too many developer candidates who just don't understand pointers.)

Answer 4

I agree that programmers must know algorithms very well, even with fancy new frameworks, but I'm not totally convinced about a brain teaser in an interview. My biggest concern would be that in a real environment, you write algorithms under very different conditions; aka, not under pressure with someone watching you every penstroke, with at least several minutes to think it over in silence. For those who advocate this evaluation method, how long do you generally give the person to solve it? I believe code is not so much about cranking out a solution in a feverish 3 minute terror, so convince me that this is actually a good way to see how someone will handle an everyday task.

Answer 5

The problem with that specific question is that it's almost a trick question. With one particular insight, you'll easily come up with O(n), otherwise you'll struggle to get better than O(n log n). It almost reduces to "Have you seen this one before?"

I'm not sure there are any good algorithmic questions. If you asked one based on graph theory, say, it would depend on how familiar the interviewee was with graph theory - and, if you hire him or her, he or she could be up to speed on graph theory fairly quickly. Again, we're back to "Have you been exposed to this before?"

There isn't time in a regular interview to do serious problem-solving, and I approach things differently when I can sit down, use Wikipedia, and generally take some time to figure things out. There probably isn't time for the interviewer to carefully discuss what the interviewee knows in detail and pick out a suitable algorithmic question.

Answer 6

I like algorithm questions, because it's what we do. I like constraints, because it's what we use. Big-O is especially relevant in my industry.

I do not like requiring the answers to these sorts of questions to be "write the code on the whiteboard". The interviewee should be able to talk intelligently about the approach to the solution and engage in an ongoing discussion as the interviewers change the requirements while the discussion is underway.

The original question is asked, the interviewee says, "start at the beginning and march toward the end looking for the 'hole'". Interviewer says that's too slow, because N is gargantuan. Interviewee starts discussing binary search. Interviewer says that all of the sudden the data is no longer sorted. Interviewee says "sort then search". "Now it's too slow". Etc., etc.

Answer 7

Unless you are asking questions about algorithms/formulas the candidate needs to know for the job (fluid dynamics, for example, if the position requires that), I dont see their value. The candidate is already likely worrying about how they're dressed, how they're speaking, etc... whether they can answer a math question on the spot doesnt prove anything other than maybe how they might fare on a tv game show.

When I interview, I dont even ask 'programming' questions per se. I have the candidate describe their past projects, how their code achieved goals, what their approaches are, etc. From that I can tell pretty quickly whether the candidate knows what he's doing or if he's a poser.

Answer 8

You want a question that will give you insight into the candidate. An algorithm question may give a good response, or it may not. And I'm not referring to them being able to answer it or not. If they work through it, and you understand and follow their reasoning, that's a good indicator. If they just sit there, no real response, don't seem to even know where to start, that's a bad indicator (maybe). The problem would be that some people freeze up, and differentiating freezing up from not having problem solving skills may be difficult.

People will complain about asking just about anything in interviews, for various reasons. The applicant may freeze up, the applicant could have just looked that question up, the applicant may not know that particular piece of trivia/tech/whatever. All this is true, but an interview still needs to happen, and many of us in this profession hate that. We hate the idea of someone sitting in judgement of us. We immediately conjure up reasons why we could be judged unfairly, or how the test could be bogus or gamed. Bottom line is, it doesn't matter.

What you really want is an interviewer with the ability to determine skills that may or may not be presented during the interview. Questions are just the tools. To me, all hammers look the same. But to someone skilled enough with them, I'm sure there's difference.