I wouldn't say that you don't need it, but I would say that most companies ask about the wrong bits.
I wouldn't say that you don't need it, but I would say that most companies ask about the wrong bits.
[1]: http://www.seattletimes.com/business/boeing-aerospace/dramat...
Somebody needs to know how to implement sorting algorithms too. It's just highly unlikely to be you.
If you want to have an engine with 60s power, weight and fuel economy, then sure you don't need to know the science behind it. Just throw some parts together, and you'll get something that works.
If you want to sort a list, balance a tree, multiply a matrix or find the shortest/cheapest path in a graph, you should use a library that already does that and is reasonably tested and optimized, certainly more than whatever you'd write today. Most likely you shouldn't even get to choose which algorithm to use for that, and if you need to then the choice should be based not on the O() measures you might remember but on benchmarking, since the constant factor often dominates.
I have seen quite a few very large systems in which the most complicated algorithm actually implemented in the system is a set of branching if-then conditionals for some business logic. There's no custom data structure traversal - yes, it needs some data processed, but all the algorithms for that are in the DB implementation and "do X for all selected items" is literally the deepest level of iteration anywhere in the system. There's cryptography, but that's in a separate library made by someone else. There's network algorithms with state in them, but that's managed by a separate layer.
In such data processing systems all the development does is glue code that specifies what exactly should be done, but all the how part (e.g. the algorithms) is already implemented by someone else and is reused.
There are fields and apps (parts of them) that are algorithm-heavy; for example, even simple games tend to pack a lot of interesting algorithms (but even there much of that is now handled by standard libraries/frameworks). But most developers don't work on that, the majority of software dev work is cookie-cutter data processing apps where all the algorithms are out of your scope.
Those interview questions aren't about "algorithms", they are about details of specific ones chosen by their complexity and that are rarely used in practice.