I've been engineering systems for 25 years. On a macro level, most of my time is spent considering the right tooling and stack for a job, balancing budget and time constraints and efficiency against how things may need to scale in the future. On a micro level, in the data model and in the code itself, choosing the best structures for a task is important for maintainability and overall coherence.
In my experience with LLMs, I often need to guide them toward choosing the right ways to model data on the code and database level. LLMs seem to prefer json blobs of unstructured data, naming conventions that drift over time, argument structure patterns that change from one piece of code to another. The net result is a lot of tables and code that an LLM needs to read back through, find all the linkages, and recommit to its window before any debugging can take place. It makes human debugging very difficult if, for example, an LLM decides to just store all the userdata in some json column and then decides to add some kind of stateful preferences to that, and other state to something in memory, and then parse the memory falling back to the database state. I've seen a ton of things like this where weird ways of handling state kinda work, until they don't, and it's extremely difficult to figure out what is taking precedence when or where a thread race is coming from.
All this is to say that DSA knowledge may be even more important when LLMs are writing most of the code, because an unguided LLM will write stuff that can practically only be maintained by an LLM, and make design decisions that don't cohere or scale. If that's not really a problem, and you're certain that the code you're investing in writing will never need human intervention, then I guess it doesn't matter. But with a large enough system designed that way, the boundaries and edges of poor DSA choices aren't going to be apparent until either something breaks or you need to grow.
The reason more companies don't IQ test is that it's an ineffective tool for candidate screening. We all intuitively get that as software developers: imagine hiring off an IQ test rather than just having someone write code.
Regardless, you vastly overestimate how much effort is put into hiring. The vast majority of companies would never study the effectiveness of IQ tests to know if they are useful or not. If they had a gut feeling that an IQ test would be helpful they would try it on that basis, except they wouldn't try it because they've read online that IQ test use is illegal; meaning that it is considered to be legally indefensible.
So it's difficult to see how to square what was previously said on this thread, about IQ testing in employment being "illegal" or "legally indefensible". Those are trivially falsifiable claims. Every HR department in the world knows that.
What I said, quoting from earlier, was "considered to be legally indefensible". Whether or not it is legally defensible is for the courts to decide, but it is clear that it is considered to be. Unfortunately your full comment didn't arrive, but what we did get was "This is just a big Internet myth" which appears to have you echoing that it is considered to be legally indefensible. You cannot have a "myth" without belief.
Where the law is abundantly clear (YMMV, law is jurisdictional) is that hiring criterion must be related to the job. It asserts that selection tests must be reasonable, bona fide, and tailored to actual job duties. That does not strictly prohibit IQ tests, but there are effectively zero jobs where an IQ test would be seen as reasonable, bona fide, and tailored to the actual job. Whatever exception you can find is just that: an exception.
Moreover, on JEPS, Allstate does not use JEPS in my jurisdiction. There is no public knowledge as to why, but legal compliance would be a reasonable explanation. Use of JEPS may even be illegal.
Perhaps you had a different company in mind?
Could it be that you are using "IQ test" as some catchall term for any type of cognitive test? You could define it that way in a vacuum, but that is not how it is being used here. The initial comment was clear about how it was being used. In context, "IQ test" was being used to refer to IQ tests that are academically recognized as IQ tests (WAIS, Stanford–Binet, etc.). HR department pet assessments do not fall under that.
So to the extent that we software engineers were complicit in that myth, we can’t blame management for believing that AI can replace human software engineers now that AI is the best leetcoder.
The argument was dsa functions like an iq test. It’s not relevant to the job (in fact it’s harder than the job, far harder) such that if you do well on it companies can be confident you can do well.