Some companies are sorely mistaken about what they actually need, though. I was once interviewed (and accepted) at a small company that apparently needed fundamental 3D skills. I ended up being grilled quite a bit about rotation matrices and the like.
The reason for this? They maintained an in-house 3D engine they use for various products they sell to important customers. What I only realised later was that a grand total of two people actually worked on that engine. The rest of us ended up just writing and maintaining large C++/Qt programs riddled with technical debt.
What they really needed were people who can wade through large code bases with significant tech debt. I wasn't interviewed for that skill however, and I happen to not be very good at it. (I'm especially bad at resisting the urge to fix tech debt that is currently hindering my own work, even though sometimes I have to let it slide because of deadlines.)
I didn't last long there, and learned later they weren't very good at retaining developers there.
I have pretty much the opposite of this story. I contracted with a company doing a fairly basic photo editing app, who had managed to code themselves into some godawful mess. Basic frontend changes took days or weeks because they had a handrolled layout / animation system from someone who had no idea you could a) specify complex motion of objects over time via linear algebra, b) sequence operations more easily by even just slightly reifying some state machines. Instead the whole code was full of hundreds of variations of "if picture.x != picture.goalX && picture.rotating { picture.x += 3; picture.angle += 1; }".
I have seen this pattern over and over, simple applications grown into complex unmaintainable garbage because they didn't have someone who could write a state machine, or a simple interpreter, or a constraint system. Or because they needed something small but reached for something big instead when they didn't know how to implement the small thing, e.g. a task queue that could've just been an array with locks around it instead turned into 0MQ (or worse, MySQL). And these are not companies with only interns/juniors, often people with 10+ years experience who think "fundamentals don't really matter."
> people with 10+ years experience who think "fundamentals don't really matter."
Sounds like people who think "programming is not math".
Granted, it's quite unlike the math we were taught in high school. But it does have patterns, opportunities for simplification, similar correctness problems, and sometimes good honest Math™ with geometry, linear algebra, and more. One can easily miss that when they assume programming is not math to begin with.
Even if those programmers didn't know the fundamentals behind animation systems, they could have reached for those if they recognised that this part may have some significant math behind it, and sought out relevant material.
The reason for this? They maintained an in-house 3D engine they use for various products they sell to important customers. What I only realised later was that a grand total of two people actually worked on that engine. The rest of us ended up just writing and maintaining large C++/Qt programs riddled with technical debt.
What they really needed were people who can wade through large code bases with significant tech debt. I wasn't interviewed for that skill however, and I happen to not be very good at it. (I'm especially bad at resisting the urge to fix tech debt that is currently hindering my own work, even though sometimes I have to let it slide because of deadlines.)
I didn't last long there, and learned later they weren't very good at retaining developers there.