I wish more companies would hire based on code that you've written, than a bunch of contrived puzzles you're supposed to know by heart so you can solve it on a whiteboard without blinking. But, since that's how the fucking system works, I'm forced to spend time committing these things to memory than writing actual code.
James Hague said it best, "Organizational Skills beat Algorithmic Wizardry". http://prog21.dadgum.com/177.html
These are the skills actually that are needed to implement an RB tree (lot of special cases to handle, hard to organize the code well), although I have never been asked to implement any balanced tree on an interview.
If you haven't done that, it is a good indication of how you will handing boring but necessary and important stuff at work. In all fairness, I think you can't fault people wanting to judge you based on that..
It's not about learning algorithms. If you do the Stanford MOOC on algorithms on Coursera, which is one of the best MOOCs I've ever come across, you'll find that the instructor emphasizes understanding over rote learning and implementation details. If you understand what data structures and algorithms fit where, you can look them up and apply them as and when you need to. Memorizing every nook and cranny of CLRS so you can reproduce it quickly in an interview is a terrible waste of time, imho.
Which Universities (that have students that participate in HackerRank) Have the Best Coders in the World (at HackerRank problems)
My business school had all graduating seniors take a similar assessment and liked to advertise that our students scored in the top 99% of all universities on the test. The thing they left out is that the top 50% of business schools did even bother with the test.
That didn't make the assessment totally useless, but it also didn't mean that our graduates were in the top 1% of business schools.
Edit: Upon some googling, this comes from the book "The Practice of Programming" by Kernighan/Pike.
You know what, f'it - just call me a guru. Sometimes I be in deep thought, meditating at my Amiga, but if an error happens, well...you know what that means.
I believe that more strongly now.
In fact, most of the people in the program were pretty bad at coding.
It's especially easy to do in this field, because there can be a strong disconnect between the business side and the tech side. Most everyone on here can name at least one person they've worked with that created more work than they completed. It would have literally made better economic sense to have them watch movies all day at work rather than mangle the code base.
Source?
I've observed a strategy of preferentially hiring competition coders have no discernible positive impact.
But if you asked him a question? He would literally stare at you and not answer. Couldn't get anything back from him in meetings. I believe he was hired from a very algorithms-focused interview. We had also hired a few folks who actually had MBAs with emphases on Information Systems. They were okay coders, but they communicated really well. They were by far the more productive team members the rest of the time.
While he may not have been "productive" in the traditional sense, it is quite possible that he saved the business and development team countless hours of lost time down the line by implementing the documented process to spec in such a manner as to not require future downtime or maintenance...