Fixing impostor syndrome in coding interviews
Sometimes impostor syndrome doesn&#x27;t need to be fixed. I am beginning to think there&#x27;s one UC system school which is afflicted by Teaching assistants who shouldn&#x27;t themselves be able to pass a programming job interview.<p>I&#x27;ve pointed out to interviewees that user input in one problem can result in circular references. I point out, as a hint, that thing A can refer to thing B, then thing B can refer to thing A, and you&#x27;d wind up with an infinite looping execution in one part of the code. How can we detect this? So then these 3.8+ GPA Comp Sci grads tell me to write a conditional that detects a 2-element loop. Not an algorithm that can detect the cycle, but just a conditional that only detects the 2-element cycle. Then I have to ask, well what about a 3-element cycle? To the credit of most of the applicants, they then try to incoherently describe an algorithm involving some kind of hash table, but then never give anything which is implementable. Once, the applicant didn&#x27;t yet realize there can be n-element cycles, then proceeded to literally handwave away all graph algorithms.<p>These same applicants usually have a hard time writing their own recursive algorithm. Would you want to trust your startup coding to people who don&#x27;t habitually think at least one step ahead? Come on! These things used to be covered in the first algorithms class! This should be Freshman Year stuff!