Take the 2-minute tour ×

In a programming interview if I am asked a question I already know the answer for, such as giving an algorithm for a particular problem. Should I disclose that to the interviewer? This issue only makes sense when there's a novelty aspect to the question.

One example is "How would you reverse each word in a string, but not their order?". There also seems to be a division between easier stuff, that you are "supposed" to know, such as my example and harder more contrived problems.

Whats your policy and rationale for dealing with this issue? If you are already familiar with the question/brainteaser, should you disclose this in addition to answering the question? Is there any ethical dilemma involved with not disclosing your prior knowledge of the question?

share|improve this question
I am having trouble seeing the point in this question. If you know the question you answer it, if you do not you try to work out something reasonable. Should you tell them you know the answer instead of just telling them the answer? –  Chris Nov 15 '10 at 11:48
@Chris. the last question in your comment is really what the OP asks here :D –  Pavel Shved Nov 15 '10 at 12:12
And that is supposed to be constructive? I cannot think of when I would tell the interviewer "Yes I know the answer" and not tell them. –  Chris Nov 15 '10 at 13:16
I'm waiting for "Fishtoaster" to give his answer. –  Mark C Nov 15 '10 at 15:33
@Chris - Correct; the question here, as I understand it boils down to "Is there an advantage and/or ethical consideration to either option 1 or 2 if you know the brainteaser, and if so, how are they weighed?" The fundamental point is buried fairly deep, and it's phrased in an overtly subjective manner, but it seems useful (not least because I have no idea what the correct answer is, and it seems like I should). IMO this is a question in need of some light editing for clarity, not closing. –  Inaimathi Nov 16 '10 at 16:06

9 Answers 9

I'm in favour of open and honest communication, so I'd definitely say that I knew the question, and the trick involved.

I suppose for extra credit you could say "OK, this is how everyone else does it, but let's see if there's a different way." Or you could deconstruct the question in other ways, and show why people like the question, what the question's supposedly trying to get you to see.

(Edit: removed the reference to FizzBuzz, from other people's comments on this post.)

share|improve this answer
FizzBuzz is not about factoring. –  zvrba Nov 15 '10 at 10:03
I also think you might be missing the point of FizzBuzz. –  Tim Post Nov 15 '10 at 10:21
Well, then what is it about, if not avoiding the case of n mod 15? I said "factoring" because I can well imagine someone using two other primes for "Fizz" and "Buzz", thinking they were clever. The point is still that a number divisible by the N primes you use (for FizzBuzzBazz) is also divisible by any multiplication of those primes. –  Frank Shearar Nov 15 '10 at 11:01
Which totally doesn't matter since 3*5 does not need to be handled specially in a FizzBuzz implementation. –  Joren Nov 15 '10 at 12:42
Fair enough; the solutions I've seen did, but no, you don't have to handle 3*5 specially. –  Frank Shearar Nov 15 '10 at 13:23

I'd just answer it without much hesitation or screwing around. Knowing the answer to a question isn't something evil, it means you've encountered it before and know how to solve it. Fix it, move on to the next.

share|improve this answer
Yeah, I think this is fair. It's not like knowing the answers is cheating; if anything, it's a sign of experience. I mean, don't fake it, like pretending you just invented quicksort on the spot without ever having heard of it or something (bad example because everyone's heard of quicksort, but you know what I mean). Just answer immediately. It will probably be obvious you were familiar with the problem, but there's no need to say so explicitly, and if anything that could be taken as criticizing the interviewer for picking an unoriginal problem. –  Tim Goodman Nov 16 '10 at 14:37

I'd still answer the question. I interview programmers very frequently. I'm less interested in the fact that you can solve the problem (unless you simply can't) and more interested in how you solved the problem.

I ask lots, and lots .. and lots of annoying little questions during an interview that are specifically designed (and refined over time) to give me a very good understanding of your actual strengths verses what you put on your CV. I will do my very best to lead you along a trail of subjective banter and then hit you with increasingly harder problems.

Using Frank's example, FizzBuzz, the last thing I want to hear from you is "Oh yes, I know how to use the modulus operator ..." If I'm interviewing you, I know that. I might want to see how quickly your brain switches gears, or I might want to test how well you'll carry out an assignment that seems mundane and stupid. The point is, I'm not just testing your ability to solve problems.

I can make a mouse trap with hundreds of moving parts. If a company is in the business of catching mice .. well ... :)

share|improve this answer
You won't find out how the interviewee solved the problem if he just knows the answer. –  Pavel Shved Nov 15 '10 at 12:12
@Pavel: Sure but you could ask them "What was the advantage of doing it this way instead of that way?" That way you can see if they really understand the thought process behind the answer, or if they just memorized the answer without understanding why. –  Tim Goodman Nov 16 '10 at 14:30
@Tim, so if you want to ask the "how to find out if linked list has loops in O(1) memory" question, and I know the answer (heck, I solved a lot of such kind of problems), what would your follow-up question be? –  Pavel Shved Nov 16 '10 at 14:52
Tim, I would be interested to watch you interview someone (or interview me, haha), just to learn. –  Mark C Nov 17 '10 at 2:56
@Pavel, I'd probably complicate the problem and introduce multiple writers to the list. If you took a minute and thought about that, I'd probably ask your opinion on lock free methods and ask the same question again, wondering if O(1) went to O(log n). If you completely blow me out of the water and we could afford you, I'll make sure you become my boss. Sorry for the delay, that 'orange envelope thingy' up top has been acting quite strange lately. –  Tim Post Nov 23 '10 at 15:08

As an interviewer, I am not asking the question to see if you know the answer to a tricky chicken and egg question. Instead I am looking to see how you work through a problem to arrive at an answer. Therefore, it is often easy to tell the difference between knowing the answer and arriving at the answer (unless, of couse the interviewee acts out to arriving to the answer!)

share|improve this answer

In my experience, for most technical interviews, the interviewee is really interested in you solution and how you came up with it and how you explain it, rather than whether you had heard the exact same thing before. Unless it was one of those "puzzle" questions that involves a "trick", knowing about the problem beforehand does not really give you a decisive edge unless you are able to solve it by yourself anyway.

For a sufficiently non-trivial question, the problem posed might actually be a well known one, or can be reduced to one. If someone asks about the way to find the shortest route between two nodes in a graph, do you pretend to not know BFS/Dijkstra? IMHO, for some problems it might even be counter-productive to hide the fact that you know your stuff.

share|improve this answer
+1 for trick questions. If you know the answer to one of those already, you can just say so. The purpose of such a question would be to watch the process when the pieces fall into place, and if you already know the answer that won't happen. –  Guffa Nov 15 '10 at 14:58

"Knowing" the answer is not the point. Communicating it in a way that the interviewer has a chance to understand the answer you are giving is. (Of course, the interviewer knows a bunch of answers, but as I said, that's not the point.)

So I'd try to communicate the answer framed into a reasonably didactic, or maybe humorous, frame, so the interviewer can see how I think and function, or don't.

For example, it might be fun for all of you (and informative for the interviewer) to take the question asked into a totally different context, showing that even though the problem at hand looks similar, the solution does not work in the new context. I think the art here is to find a somehow related context for the question in which the solution from the first answer does not work, and then propose spectacular solution ideas which the interviewer may chew on (or laugh about).

share|improve this answer

When in the interviewer seat, I've seen plenty of people say "Oh, I've heard this one", then struggle to remember or rework a solution. So in many cases, foreknowledge doesn't give you that much of an advantage. I'd recommend telling them you've heard it before, and proposing a solution. If it was too easy for you, they'll give you another question and appreciate your honesty.

share|improve this answer

I think telling the interviewer only applies to those goofy "gotcha" questions, like the round manhole and other stuff like that. Questions where once you know the answer it's completely obvious.

Reversing strings, etc, don't have an obvious "gotcha" solution that you can explain in 3 seconds if you know it.

share|improve this answer

So what's the alternative? If you tell the interviewer that you know the answer to a question that is posed and expect them to give you only questions that you don't know the answer to, what happens? Either

  1. They will respect you because you will only attempt to answer questions you have never seen/heard before,
  2. They will be blown away by your brilliance - after all, you already know the answers to the questions they're posing - and will immediately offer you a job
  3. They will think you're a smart-ass because you already seem to know everything - just ask you!, or
  4. They will think you're a fool because you don't know when things are going well.

I suspect that options (1) and (2) aren't going to happen - call me Mr. Cynical. So you're left with either being a fool or a smart-ass, neither of which is likely to land you a job. Hey, good luck!

The point of an interview, as others have pointed out, is to offer you a chance to demonstrate your technical proficiency by answering whatever questions are put to you. This kind of means that it's in your favor to be asked questions you're already familiar with. If you insist on sabotaging yourself, go ahead - nobody's going to stop you - but I suggest you don't.

Share and enjoy.

share|improve this answer

Your Answer


