I've also worked on some signal analysis stuff -- had to learn about FFTs and basic filtering (band-pass filters, etc.) -- it's all math. But had books and the internet to look up those algorithms.
I have several books on my bookshelf for these things, including an old copy of "Numerical Recipes in C" :)
As to the how, consider that if finding good software engineers is hard (debatable), finding them with clearances is even harder (definitely true). The interviews for defense and aerospace jobs are easy compared to your standard technical interview at Netflix, Google, et al. They really don't want to risk screening folks out for trifling things like "competence" when they have billets to fill (because they're selling man-hours of labor to the govt, even a mediocre engineer can be profitable).
But you should also know, that while working on a large satellite program may sound cool, the maddeningly slow and byzantine bureaucratic development processes (I'm currently on a waterfall-driven project) inherit in such programs will suck every last ounce of joy out of your working life. So, there's that...
Or my current favorite: a very senior and very optimistic person who apparently doesn’t believe in decidability, the halting problem, or NP completeness.
No, in fact we've proven there are a lot of things we can't do, and oceans of things that are theoretically possible but completely impractical to do (another class of people mistake intractable for impossible, but for small enough N sometimes it is both possible and worthwhile).
Undecidability and the halting problem is usually analysed for Turing machines (I am aware that there also exists literature on these problems for other types of automata). The problem is: It is impossible to build a Turing machine. Every computer that has been built up to know is just some kind of finite state machine. So the halting problem is perfectly (in a mathematical sense) deciable for real computer programs. The problem is: We have no idea how to do this in general in a timespan that is suitable for practical purposes.
You'll see many non-programmers assert that it's not necessary to get trained programmers to do a certain task (say, automation). However, they don't understand all the software engineering considerations and issues that you'll run into if you don't have a programming background.
It's only when you truly understand a field that you can see when that field is applicable to the task at hand.
One thing that wasn't mentioned: if you're doing any kind of graphics programming, you use a huge amount of basic linear algebra every day. Vectors, matrices, dot/cross products, affine transforms, spaces and subspaces, that kind of thing. If you're doing more advanced stuff, a working knowledge of how to solve large linear systems (i.e. things like Gauss-Seidel/Jacobi methods) and the physics of light transmission is also useful. If you're doing physics simulations, obviously you need a working familiarity with calculus.
Again, though, all of these things are massively deep fields that people dedicate their lives to understanding, but as a programmer you just need to skim the surface, generally speaking.