You're right, and I totally agree with you on what you're saying about the interview/job obtaining process, and that replacing the way this is done with something far more effective for interviews would be ideal. I also agree that actual experience using these types of things seems much more important than seeing if someone has drilled on quiz questions.
The question then for me is, how does one assess if someone can use these things in practice to make a difference for the business? I don't have a good answer for that right now. If anyone here knows a nice approach to use to assess this type of skill, I'd like to know more (to stop perpetuating the usual 'algorithms gauntlet' approach).
As somebody who passed out of university last year, I remember how we had to mug up most of the questions on this website (and practice topcoder + codeforces), so that interviewers could consider us smart.
IMO, algorithmic interviews are maybe a good way to filter for motivation rather than anything else. Candidates who are likely to learn all this are more hardworking and career-consciuos (placements correlated pretty strongly with how much you 'knew').
That said, there was this one interview I had where the interviewer asked me how to design a distributed log collection service. Basically you have GBs of log files being generated on hundreds of servers and you want them sorted and stored on a single central database. What sort algo will you use, why? How to reduce transmitted over the network etc.
It was a fun round and tested a lot of disparate concepts.
To my inexperienced self, this seems like a good format:
- First round: Ask stuff like fizz-buzz, trees, file I/O or string processing stuff. Basically ensure that they know how to code. Another way could be asking them to code the same question in functional, OOP and procedural styles
- Second round: Discuss some project done by the candidate or ask them to design something from scratch. URL shorteners, databases, REST apis are normal candidates. Spreadsheets, DSLs etc might be good to make things harder.
- Third round (If applicable) : Dig into any one specific domain most relevant to your company/team and make them architect* the whole thing.
Ofcourse, any system, once its established and well-known, can be gamed. Banking on open source projects or past achievements is then what remains.
* Very few entry levels jobs really require such skills but (IMO) it will help you get better engineers instead of coders.
The question then for me is, how does one assess if someone can use these things in practice to make a difference for the business? I don't have a good answer for that right now. If anyone here knows a nice approach to use to assess this type of skill, I'd like to know more (to stop perpetuating the usual 'algorithms gauntlet' approach).