Based upon my three decades of programming experience, programming at rare times may require you to brush up on what you learned in engineering school, but essentially your degree is mostly a worthless piece of paper in terms of career usefulness. I've used much less than 5% of what I learned there, and probably more like less than 1%. My most useful class was software engineering, because it touched on the non-technical aspects of being a programmer.
There are small subsets of programmers that use geometry and calculus, but even if we only remember the basics those types of programmers don't need to worry about nit picky details because we all use libraries. You'd be absolutely foolish to open up a calculus book and write your own library function, unless you're doing something extremely novel. Novel is bad when you are trying to write maintainable code.
What is useful to you as a programmer is to understand what big O notation is. It's advanced math beyond calculus, but it always seemed like common sense to me. If you have to do n^2 operations for every n, that's worse than having to do n operations. In 30 years I've never had to worry about little o or logarithms. Google gets specific in interview questions about all of these notations, but I'm telling you what is actually useful.
What is not useful to you is mastery of the syntactical details of any language. Try to program as if you're writing English. Write software in such a way that you could be doing it in any language. Write software that the next person can read, instantly understand, and begin modifying.
Programming isn't purely doing Google searches. What I spend most of my time on is seeing how the software I'm working on already solves a problem and to use as similar techniques as possible, so that the next person who works on it will encounter consistency. Every change I make I make for a reason, and I understand every change I make well enough to explain it to my mom.
Another way of looking at it is the technical interview is almost completely useless. You can ace a technical interview and write the shittiest code I've ever seen. You can perform average on an interview and write the cleanest code I've ever seen. If anything, detailed technical knowledge should count against you. The next person to maintain your code might not know every trivial little feature of the language you're using and has no admiration for your cleverness.
Write software like Hemingway, not Thomas Hardy, and don't sweat the math.