Most engineers I know have not learned set theory or groups/rings/lattices. They still seem to be doing pretty well.
but as madhadron says, you can't read/write proofs of upper division or graduate level math without the "foundations" material, which includes naive set theory.
do you need any of that to do engineering math? well, there are a couple of standard quotes, relating to the fact that the technique taught is brittle, in weird and subtle ways. the claim is that understanding the proofs tells you what the limits of applicability are.
"[F]or more than 40 years I have claimed that if whether an airplane would fly or not depended on whether some function that arose in its design was Lebesgue but not Riemann integrable, then I would not fly in it." - richard hamming, "mathematics on a distant planet"
"It is customary to begin courses in mathematical engineering by explaining that the lecturer would never trust his life to an aeroplane whose behaviour depended on properties of the Lebesgue integral. It might, perhaps, be just as foolhardy to fly in an aeroplane designed by an engineer who believed that cookbook application of the Laplace transform revealed all that was to be known about its stability." - tom korner, fourier analysis
Although I wonder for 90% people of this world that math is just a tool to pass the exam at school, not any real application (or they just can't sense it).
Basic arithmetic: addition, subtraction, multiplication, division.
Some of the engineers who attract quantitative work are people who came from outside of the mainstream engineering training, such as scientists and math people.
When you're designing a real-world engineering project, the entire specifications are defined legally (through national, state and local laws) and technically in manuals/books. Many engineering specifications will describe the work done to a T before you even need to think about it i.e. "water main shall be constructed of 12'' coated DIP at depth no less than 2 ft". A lot of the challenges are managerial and logistical.
All of this is on purpose. "Traditional" engineering disciplines are more mature and have the constraint of being safe for the general public. There isn't much room at all to creatively deviate from what's already specified.
I've found software design to be a lot more technically demanding in regards to designing and building things. There's a lot less precedent, more moving parts and many different ways to do one thing.
And I'm not blaming anybody -- for one thing college math is often badly taught, and there's a pervasive message that you won't use any of your math or theory after you finish your degree. And then we get them so busy with CAD and bureaucracy, that they forget a lot of their school stuff.
But anything requiring calculus or above, goes to a handful of "math people" in the department, who accept those tasks in return for avoiding the CAD and organization stuff. (I'm one of those people at my workplace, my degree is in physics).
To make it a bit harder, virtually all math these days is done with computation, which means a person has to be good at both math and programming at some level.