I’ve been writing software for a living for a number of years now. I have graduate background in mathematics and I am wondering whether knowledge of higher algorithms is utilized anywhere in industry. If so, where, outside of finance? Traditional software engineering is to algorithms theory what apples are to oranges.
A friend of mine works on the combinatorics of Sturmian words, and did so for years. A Sturmian word is typically obtained from a straight line drawn on a lattice: whenever the line crosses an horizontal edge of the lattice, output an 1; whenever it crosses a vertical edge, output a 0.
From my point of view, this is quite theoretical.
Yet, my friend was hired as a consultant by a cheese-selling company. They have these large circular cheeses to slice into pieces of 100 grams. Well, they guarantee that they provide at least 100 grams, no less; and they charge 100 grams only, so they want slices of at least 100 grams and as close to 100 grams as possible.
It turns out that Sturmian word algorithms are very close to what they need for their slicing problem.
This illustrates how knowledge of algorithms is useful in an incredibly wide variety of practical situations, even the most theoretical ones.
It really depends on what you mean with "higher algorithms".
I work in game development, and we use graph theory, linear and nonlinear optimization, computational geometry, dynamic programming, and lots of other fun stuff.
If you work in robotics, simulations, industrial control software, aerospace industry, etc., there will be plenty of stuff that needs a lot of knowledge of traditional algorithms.
As others mentioned, there are plenty of fields that deal with signal analysis. While not algorithms in the traditional sense, they may be part of your skill set. Anything that has to deal with analysis of image data, sound of video, but also weather analysis, seismic analysis, this all has a lot of signal processing.
More recently, there are lots of jobs that need statistical analysis. I'm talking about AI and machine learning. This is quite in vogue right now, and every company wants something to do with it.
As you can see, many industries, not just the financial world needs people with knowledge in algorithms and applied mathematics. That said, these modules are usually part of a larger piece of software, so general knowledge of software engineering are also very useful to become a successful working engineer.
In my experience (a few decades of "business" style IT, having studied CS myself) there were very few occasions where we actually programmed "interesting" algorithms, and a majority of my colleagues did not have a real CS background - if they studied it, then theoretical CS certainly did not interest them that much, judging by our non-communication about these topics.
I still regret nothing. Very occasionally, I got to create quite nice algorithms, and think long and hard about how to solve concrete business problems in a way that's not simple "if this - then that" with a few predetermined branches.
More importantly, it helps me tremendously to have a relatively deep background in theoretical CS. For example, when reading about the internal workings of RDBMS systems (with sometimes quite involved data structures and dynamic behaviour), I usually have very good intuition about whether what they write makes sense or is obviously dubious; when optimizing nontrivial data storage and processing, I can immediately fall back to plenty of advanced data structures I've met in the past. I have programmed small languages (more like domain specific scripting tools for less technically inclined colleagues); occasionally I use graph algorithms to solve relatively complex optimization problems, and so on.
Most importantly, I know what to do when I stumble across a really hard problem. I know how to find hints on proper algorithms, I know when something is NP hard, and have a good feeling on when to brute-force a solution, and when it makes sense to look for a smart algorithm. So nothing of my theoretical CS background is wasted, and I quite often see how easy stuff seems for me compared to colleagues who have little interest in these things.
I wouldn't know that there is a job description where you basically work only with "algorithms" all day long - it will always be in context of some business or science needs. To give you a better chance, look for jobs in very technical or mathematical oriented industries (maybe avoid classical business software where there's 80% just structured data presented in forms or web sites...). Automation, robotics, statistics, biology, chemistry, physics...
There are plenty of places that need algorithmic research in practical applications. Just to give you some examples:
- My current company makes a specialised machine learning supercomputer. Most of our engineers have primarily academic background; in fact, this is a particular challenge for us, since many of them are not used to doing software engineering, and thus aren't necessarily very familiar with best practices. We need all kinds of esoteric algorithms, not just those related to ML. We make use of graph theory, have many, many in-house compilers, numerical algorithms, plus everything you'd expect in a ML stack, plus everything that's likely to be employed by the kind of people who buy a ML-oriented supercomputer, because we need to ensure those work well on our stack
- My previous company made a flash memory-based storage product. We had plenty of algorithmic needs, from distributed consensus (everything becomes distributed when you're a highly-available system that's used over the network), to data de-duplication, to custom compression algorithms because, as it turns out, with enough logs to store, having an engineer and two interns work on a custom compression algorithm for a couple months to get extra 10% compression ratio makes financial sense
- Natural language processing, and in fact most of modern linguistics, is basically algorithmic research. So is genomics. A lot of it happens in academia, but a lot also happens commercially in the industry
- Programming language research is as close to theoretical CS made flesh as it gets, and there's a lot of it happening out in the industry. Every Microsoft, Google and Facebook has multiple teams dedicated to that. You're not likely to have a successful software business that's based on programming language research, but there are plenty of successful software businesses that need to do programming language research, and even more that need to write compilers
Whilst a lot of software engineering doesn't necessarily require a very deep understanding of algorithm analysis and algorithmic research, and primarily research-oriented jobs in the industry are relatively rare, the need for a strong CS background does come up a lot. Any sufficiently large project will eventually need algorithmic research to solve a problem.