I think they're useful to know. I don't mind algorithms and data structure questions in interviews. I use them a fair bit even in some of my most benign, enterp

I think they're useful to know. I don't mind algorithms and data structure questions in interviews. I use them a fair bit even in some of my most benign, enterprise JSON-schlepping tasks. Indexes come up a bit. I've seen many junior engineers struggle when performance problems crop up over time. If they don't have a familiarity with data structures and algorithms their "fixes" never seem to work and they get frustrated. I enjoy taking the time to show them how indexes can speed up search and when they don't give you much benefit. At small companies getting off the ground I think it's less important to hire people for their algorithms/data-structures knowledge. At companies where the teams are working on high-performance or large scale problems it's quite essential. Being able to shave down build times, as in the article, is a big deal. Knowing how to scale a large problem is a big deal when the quality of the service depends on it. There are also some problems that require it. I'm building a key-value data store as one of my side projects and it definitely requires knowledge of data structures and algorithms. You can't even implement one efficiently without such knowledge! So I guess it depends on how much your team actually works with these concepts. If your hiring process is keeping the bar high but all you do is schlep JSON from one bucket to another you're missing out on a lot of good candidates for no good reason. If you're building networking products or databases then yeah, keep the bar high. But within reason. I agree with the OP -- the need for exotic structures and algorithms is so rare that it's not a terribly good indicator of anything to use them in an interview unless you're looking for researchers. update: spelling.