Thanks ! Awesome article to which I can relate to. I keep doing interviews even if I don't want to quit my job, quite often and it is very enriching.
However I don't agree with the technical interview part. I've worked with very skilled people that don't know what a binary tree is. I've been working since 10ish years, and never have I re-coded a problem found in "Cracking the Coding Interview".
I think it is our duty as engineers to tell recruiters that real life problems can be close to those problems, but that systematically turning down a candidate because "he cannot solve this problem recursively" is wrong. Very wrong. Proof is, you know how to do it, cool (and I bet most interviewers mostly know it because you comfortably have the book's solution, or are used to showing the problem) and if really you do know, you can teach him, and he probably can teach you other cool things you don't know.
I personally rely on pair programming sessions for recruiting people, and never "binarily" refuse a candidate because he could not solve one problem. If he cannot solve all of them, then yes, probably. It is as stupid as denying someone because he or she does not know the shortcut to extract a function, or format code on the IDE.
We have the power to change ways we recruit people, so let's do it.
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.
Thanks ! Awesome article to which I can relate to. I keep doing interviews even if I don't want to quit my job, quite often and it is very enriching.
However I don't agree with the technical interview part. I've worked with very skilled people that don't know what a binary tree is. I've been working since 10ish years, and never have I re-coded a problem found in "Cracking the Coding Interview".
I think it is our duty as engineers to tell recruiters that real life problems can be close to those problems, but that systematically turning down a candidate because "he cannot solve this problem recursively" is wrong. Very wrong. Proof is, you know how to do it, cool (and I bet most interviewers mostly know it because you comfortably have the book's solution, or are used to showing the problem) and if really you do know, you can teach him, and he probably can teach you other cool things you don't know.
I personally rely on pair programming sessions for recruiting people, and never "binarily" refuse a candidate because he could not solve one problem. If he cannot solve all of them, then yes, probably. It is as stupid as denying someone because he or she does not know the shortcut to extract a function, or format code on the IDE.
We have the power to change ways we recruit people, so let's do it.