LINQ Ruined My Favorite Interview Question
Scott Chamberlin (via Hacker News):
The question is “Return the top 10 most frequently occurring words in a string.” This year a couple candidates gave me a solution which I haven’t seen in 5+ years of asking this question—they solved it with a couple lines of LINQ. I decided to dig deeper in to these solutions post interview and I’m writing up what I learned.
See also: NSEnumeratorLinq and RXCollections.
That thread is fascinating and an example of why LINQ should definitely be "allowed on the test" and in the job itself - it gives you the ability to not shy away from the right solution because you are wary of the complexity of efficent implementation of the right solution.
None of the below is written as a reply to anyone in particular and I'm definitely not saying these points were made by anyone linked above. But the following are alternative reactions that I've frighteningly *actually all heard myself* in different circumstances from people who have not been so progressive.
--
Worth mentioning is that while LINQ may have ruined a particular question, its presence is not necessarily evidence of a worthless new generation of copy paste programmers or whatever terms we're using this week.
* If someone gives a LINQ answer and LINQ is not even an available technology in the codebase they will work with, that answer is nonsensical, as if replying in BASIC.
* If someone gives a LINQ answer and they are meant to use LINQ, good! It precisely matches what they'll do when you hire them. If solving this problem manually was previously the hardest sort of problem in your codebase, let me congratulate you on how much more productive your programmers will be. If it wasn't, maybe you needed a new question that matches the sort of hard work people will be supposed to solve anyway.
* If someone gives a LINQ answer and they may be supposed to optimize the LINQ in your codebase, ask them to do this analysis and provide a manual solution. You're not going to hold their hand and do their analysis when you've hired them too, are you?
* If someone gives a LINQ answer and LINQ is available and fast enough but you're not letting them use it because kids today don't know how hard you had it back in the day, please list the other conveniences you have arbitrarily outlawed in the interest of building a monument over your own resume. Are functions or interfaces okay? Will we have lunch room discussions that turn into battle royales over brace layout or tabs vs spaces?
All in all, LINQ's prevalence (even before LINQ was coined, competent languages had good solutions to these problems) has made these problems easier to solve. If determining how the code would be written in lieu of LINQ was a good chest hair counter approximation, the question is still available to you. If it's still actually relevant, by all means, force the issue because it's going to make a difference. If it's not, do as you will, but note that you are literally wasting interview time and money over nostalgia.