> You need people who know how to find the answer to such questions.
You can't look for an answer if you don't know what question to ask.
This has to do with that whole "conscious competence learning matrix" stuff, more entertainingly described by Steve Schwartz as "shit you know, shit you know you don't know and shit you don't know you don't know" [1].
The purpose of interview questions about algorithms and data structures is to see whether the candidate has the basic understanding of how the most fundamental data structures work and when to use them; whether they understand the concept of complexity and why it matters.
If you think these things don't matter, you're taking them too literally. Knowing when to use a linked list, when to use a binary search tree and when to use a hash map might be the difference between your software being able to scale or not.
Asking algorithm trivia questions will tell you nothing about whether or not the candidate can apply that knowledge in the real world.
A large part of what I do involves coming into teams that are struggling with delivery, and helping them get back onto the path of productivity.
More than once, I have had developers that could (and have) leave and easily pass a Google interview. They knew more about computer science than I probably ever will.
And in many of these cases, the code they wrote was actively harmful. Unreadable, tangled messes, that nobody else on the team could unwind.
Knowing how and when to use monads, or bloom filters, or any number of other fun tools separates the supermen from the mere humans.
But before you need to care about that, there are more fundamental concepts that matter. Like being able to write readable code that conveys intent, knowing how to write tests that are flexible yet specific, and so on.
Who said anything about trivia? Asking trivia is pointless and any company dumb and/or lazy enough to base their interviews on trivia deserves the bad hires.
While we're at it, who said anything about monads and bloom filters? The former aren't really data structures or algorithms, the latter would hardly qualify as "the most fundamental data structures".
Also, I don't remember saying anything about the irrelevance of writing readable code and flexible-yet-specific tests.
In short, you're certainly disagreeing, but apparently not with me.
You can't look for an answer if you don't know what question to ask.
This has to do with that whole "conscious competence learning matrix" stuff, more entertainingly described by Steve Schwartz as "shit you know, shit you know you don't know and shit you don't know you don't know" [1].
The purpose of interview questions about algorithms and data structures is to see whether the candidate has the basic understanding of how the most fundamental data structures work and when to use them; whether they understand the concept of complexity and why it matters.
If you think these things don't matter, you're taking them too literally. Knowing when to use a linked list, when to use a binary search tree and when to use a hash map might be the difference between your software being able to scale or not.
[1]: http://jangosteve.com/post/380926251/no-one-knows-what-theyr...