How should I react if I'm given a problem I solved during my preparation for a technical interview ?

On one hand, the whole point of a technical interview is to asses my problem solving skills, so solving a problem that I know the answer to shows nothing. On the other hand, asking to change the question feels like asking your professor to change the test, because you know the answers to it. I did my homework, surely I might as well get the benefit from it?

  • Can you clarify the "problem"? Are you talking about those "logical thinking" puzzles? Or a practical/coding exercise?
    – Lilienthal
    Jan 17, 2017 at 21:43
  • Solving a problem that I know the answer to shows nothing. Untrue, if you explain how you solved it well.
    – Brandin
    Jan 17, 2017 at 23:52
  • Solve it, look good, get job. Simples!! Why are you even asking? May 4, 2017 at 15:53

5 Answers 5


I ask these questions not to see if you "know the answer" but to start a conversation. So I ask you to reverse a string in place or write a linked list class or whatever. And you maybe know how to do that or you have to figure it out on the spot. That doesn't really matter to me. You know what matters to me?

  • do you ask me any questions before you start writing code?
  • do you write tests? first?
  • do you comment code on the whiteboard? in the IDE?
  • if I interrupt you and ask you why you're doing stuff, can you talk and code at the same time? Some people absolutely shut down if you talk to them while they're coding and can't explain what they're doing. Others can pause, explain, and pick up where they were without a problem. And yes, some people can say "I'll just iterate through all the elements" while they type or write the for loop - but I don't expect everyone to.
  • if you forget something, how do you react and put it back in?
  • if I suggest you have a mistake, how do you react?

In all of this, whether you range from "doesn't even know what a linked list is" to "practiced this yesterday" doesn't really matter. Go ahead and tell me that you practiced it. Then we can start talking.

  • @Lilienthal I know several folks who can talk and code at the same time, and interviewed one who seemed to have trouble not talking while coding.
    – Paul
    Jan 18, 2017 at 0:36

To make an extra good impression, you say "sorry to say that I saw this exact same problem before, and this is how I solved it...". Now if your solution is good enough, but someone else found a better one, I would add that too - that shows you will use the best solution available and not insist on your own solution.


Ideally, knowing the answer to the problem shouldn't be an issue. Use the fact that you know the answer as a compass to help you walk though a possible 'solution', but don't simply blurt out '42' as the answer without showing your work. Really break down the problem solving process into basic steps, and work towards the solution you already know exists.

If you don't understand the steps that were taken to arrive at the solution that you've already seen, then you really haven't already seen a solution...You've seen a hypothesized solution, and that hypothesis must be confirmed. Often times, reinforcing something you already know by laying out how you learned it is just as difficult/insightful as solving a problem you haven't seen, so that should be no trouble. If you do understand how the solution was reached, try to walk through the problem in an 'explain-it-like-I'm-5' manner, making your entire thought process obvious.

To help communicate this point a little better, let's assume we're talking about a programming domain. Lets take a really really basic programming example. You may be asked to write a program that takes in a string and reverses it without using the 'pre-existing' StringBuilder.reverse()/StringUtils.reverse() facilities. Maybe you've seen approaches with the string as an array of characters, and looping from the last index back to zero. You know that this is where you want to end up. But instead of just writing that down and saying 'look how smart I am, I already know this', humor them and work through the problem. Setup a test harness or a REPL and start writing test cases. First write tests for the trivial cases, like "" and "a". Then test and implement cases where you have two character strings like "ab". Then test and implement cases where you have there character strings like "abc". Show them where the pattern emerges, and derive a universal solution from that pattern. Explain your reasoning each step of the way, which should be easy to do, because you already know exactly where you are going.

This need not be exclusive to programming either. The main idea here is to reflect on the solution you're already aware of, and work towards it in small steps, each time making sure it's very clear why you're making those steps. Even if you admit to the interviewer afterwards that you've already seen a similar problem before, they will likely be impressed with any sort of 'methodical' approach that explains the reasoning 'like I'm 5'.


If they ask a question that you know the answer to, saying so shouldn't hurt you. It's their responsibility to come up with good questions if they don't want you to use existing knowledge.

  • Good as a comment, but not enough for an answer.
    – Brandin
    Jan 17, 2017 at 23:31
  • I seem to get an equal number of complaints in both directions. That probably means I'm as close to making everyone happy as I will ever be.
    – keshlam
    Jan 17, 2017 at 23:57

If their test problem is relevant to the job, why should you be concerned that you have solved the problem before? If you are expected to solve this type of problem on the job and you've studied this type of problem and you can solve it efficiently, what's the issue?

Not the answer you're looking for? Browse other questions tagged .