Looks like I'm in the minority, but I completely disagree with this.
If I know the solution before hand then the interviewer is learning nothing about me other than my ability to recite canned solutions to existing well known problems. There is no chance to explore how I would think about a new unknown problem, approaches I would take, things I would consider. This is critical because, unless the job is mundane and repetitive, most real world tasks are not going to be found in a coding interview booklet. They are going to require that I think about things, not recite.
The interviewer does not need to know whether you know the question -- it's not relevant to their assessment.
They absolutely do need to know this. Just because I can give a pat answer doesn't mean I understand the concepts. It's incredibly misleading to insinuate that I've solved the problem on the fly when in reality I haven't. IMHO this is how you end up hiring someone that appears to be a rockstar, but then can't get anything done once hired.
Furthermore, I think it is dishonest. If you do this, what will you do once hired when I ask you for an estimate for a project you know how to do? Will you tell me two weeks when it takes two days and spend the rest of the time goofing off?
Honestly, I feel like a company that interviewed me in this manner and penalized me for knowing an answer to their quiz question and wasn't able to adjust the interview to discuss something more relevant in which we both learn more about each other and how things work isn't one worth working for. :two-cents:
An interview will consist of multiple questions. IT will not be based on a single question that you happened to have seen before. It's unlikely that you'll have been exposed to all of the questions before, and if you have, then it's just good preparations.
Your point about reciting from an interview booklet is why I advise against admitting you know it. Chances are the question is not the exact same one you've done before, in which case you have to adjust your knowledge. This shows thinking. Adjusting algorithms to new situations is a big part of programming.
Sure. I still think being honest is best. And I'd be happy to discuss the question if they want to and how it differs from my previous solution, etc. What I'm not willing to do though is "reverse a string in language X". Granted that's a horrible question, but I've gotten some like that, responded "i'd use the built in method, can we talk about something else?" and then gotten into much more interesting discussions :)
I've also been asked to solve Conway's Game of Life. And amazingly all I knew about it at the time was "it's that dot game." I didn't know how it worked or the rules. I'd like to think my solving that was more impressive not knowing anything about it than if I'd previously solved it several times and knew the edge cases. :shrug:
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Looks like I'm in the minority, but I completely disagree with this.
If I know the solution before hand then the interviewer is learning nothing about me other than my ability to recite canned solutions to existing well known problems. There is no chance to explore how I would think about a new unknown problem, approaches I would take, things I would consider. This is critical because, unless the job is mundane and repetitive, most real world tasks are not going to be found in a coding interview booklet. They are going to require that I think about things, not recite.
They absolutely do need to know this. Just because I can give a pat answer doesn't mean I understand the concepts. It's incredibly misleading to insinuate that I've solved the problem on the fly when in reality I haven't. IMHO this is how you end up hiring someone that appears to be a rockstar, but then can't get anything done once hired.
Furthermore, I think it is dishonest. If you do this, what will you do once hired when I ask you for an estimate for a project you know how to do? Will you tell me two weeks when it takes two days and spend the rest of the time goofing off?
Honestly, I feel like a company that interviewed me in this manner and penalized me for knowing an answer to their quiz question and wasn't able to adjust the interview to discuss something more relevant in which we both learn more about each other and how things work isn't one worth working for. :two-cents:
An interview will consist of multiple questions. IT will not be based on a single question that you happened to have seen before. It's unlikely that you'll have been exposed to all of the questions before, and if you have, then it's just good preparations.
Your point about reciting from an interview booklet is why I advise against admitting you know it. Chances are the question is not the exact same one you've done before, in which case you have to adjust your knowledge. This shows thinking. Adjusting algorithms to new situations is a big part of programming.
Sure. I still think being honest is best. And I'd be happy to discuss the question if they want to and how it differs from my previous solution, etc. What I'm not willing to do though is "reverse a string in language X". Granted that's a horrible question, but I've gotten some like that, responded "i'd use the built in method, can we talk about something else?" and then gotten into much more interesting discussions :)
I've also been asked to solve Conway's Game of Life. And amazingly all I knew about it at the time was "it's that dot game." I didn't know how it worked or the rules. I'd like to think my solving that was more impressive not knowing anything about it than if I'd previously solved it several times and knew the edge cases. :shrug: