I'll get myself some down voting here... I kind of like asking questions about data structures and algorithms. I don't see them as simple black and white questions though. I see several values: 1) If you're a "computer science" degreed person, I expect basic understanding of basic algorithms and data structures. As for your basic job stuff, things like Java have multiple implementations of maps or hash tables you should have some idea when to pick one vs the other. I don't think that's off limits. 2) I like to ask a couple challenges or questions that sort of make the interviewee a little uncomfortable, not to get the answer but to work with them on it and see how they work through that situation. I intentionally try not to be cruel but I want them to think, I want to communicate with them as they sort through it, I want to see how that stuff goes. I've had 60+ minute conversations about engineering a professional grade hash table and the different things you have to consider, that's good stuff. The 3rd thing, and this is maybe more subtle, there is a gigantic difference between implementing quick sort and qsort in glibc, the same can be said about most algorithms and data structures and I think at least a cursory knowledge of that is an indication of some wisdom. Should you be asked to implement data structure x or classical algorithm y, understanding the mechanics beyond simply copying it out of a text book indicates some wisdom.
jgmarcel|5 years ago
After a grueling interview process at Goldman Sachs, with 7+ technical interviews that required me to solve very specific questions on college-level Maths, Stats and Computer Science (admittedly, I was applying for a quant job position), I was eventually asked to interview candidates myself. While I did not feel entitled to change the current interviewing culture at the company by asking questions of a completely different nature from what I got asked in the first place, I conducted my interviews in a very similar way to what you described. By no means did I expect applicants to reach a definitive answer, but I instead worked on the problems with them to see how far their intelligence, creativity, curiosity and, most importantly, their ability to well communicate their thought process would take them.
Such interviews used to take a while hour of my time (which is a lot to afford when you work in a bank), but by the end of each I believed to confidently ascertain the candidate’s ability to thrive on our team. In retrospect, it has served me really well.
All in all, the problems posed (and the solutions given to them) might not carry as much weight in the final decision as the discussion held with the applicants. As long as the questions asked give them some material to work on, and DS and algorithms usually serve this purpose very well for us engineers and developers in general, one should be able to effectively select candidates given some time investment.