When I was interviewing, I didn't look for the candidate who knew everything, I looked for the people who could think about new concepts, come up with new solutions to problems they haven't encountered before. Anyone can memorize and spit out some lines of code. If you want top talent, you have to see how they fail. So I go the extra mile... I ask increasingly difficult and obscure questions until I reach the interviewee's limit of knowledge. At that point the pass or fail can be determined by looking at how they respond to their own failure:
A. they don't know but they try to hide their lack of knowledge.
B. they don't know and just admit they don't know.
C. they admit not knowing and continue with "here's how I think it might work" and are genuinely curious as to what the solution is. This one is the winner.
Don't just memorize bunch of code. Learn how to approach problems you never encountered before. Granted, most interviewers aren't like me. Most interviewers usually just ask if you're good at regurgitating an algorithm and that's all that matters to them. You pass the interview if one of the algorithms you memorized is the one that they asked. That's why the software industry is full of copy & paste engineers who can do a fine job of applying existing solutions to problems but can't think themselves out of a paper bag when they encounter novel problems.
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.
When I was interviewing, I didn't look for the candidate who knew everything, I looked for the people who could think about new concepts, come up with new solutions to problems they haven't encountered before. Anyone can memorize and spit out some lines of code. If you want top talent, you have to see how they fail. So I go the extra mile... I ask increasingly difficult and obscure questions until I reach the interviewee's limit of knowledge. At that point the pass or fail can be determined by looking at how they respond to their own failure:
A. they don't know but they try to hide their lack of knowledge.
B. they don't know and just admit they don't know.
C. they admit not knowing and continue with "here's how I think it might work" and are genuinely curious as to what the solution is. This one is the winner.
Don't just memorize bunch of code. Learn how to approach problems you never encountered before. Granted, most interviewers aren't like me. Most interviewers usually just ask if you're good at regurgitating an algorithm and that's all that matters to them. You pass the interview if one of the algorithms you memorized is the one that they asked. That's why the software industry is full of copy & paste engineers who can do a fine job of applying existing solutions to problems but can't think themselves out of a paper bag when they encounter novel problems.