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.
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.
To get into college, there's the SAT test with a minimum score.
To get a high paying software job, there's the leetcode test.
These are gates meant to filter out the obviously unqualified candidates. Unqualified candidates waste the time of the candidate and the company. The real interview comes after that.
And leetcode is not something you prep for once in your life, but every time you switch jobs.
So he did the three weeks, passed the leetcode, passed the interviews, and now makes 400k.
When I was 10 or 11, I asked my dad what MIT was looking for in a student application. He (an MIT alum) told me. I picked out the things I could do (being captain of the football team was never going to work for me), applied to MIT, and got rejected. But Caltech, Dartmouth and Johns Hopkins did admit me.
You do what you gotta do.
The biggest problem, of course, is that they also filtered qualified candidates (I personally got filtered out multiple times and I'd like to believe I was qualified!) But it is an understandable compromise whenever there is an extreme asymmetry in the volume of candidates and volume of interviewers, and the fix for that is simple: you study for the test (as you pointed out.)
Note also that as grandparent comment indicates, this test is a necessary but not sufficient condition; it's just to get your foot in the door for a deeper evaluation.
It's like "to get into Marine boot camp, there's a minimum crochet requirement".
Solving leetcode problems has nothing to do with commercial coding. It's an unrelated hoop that we make folks jump through, because it's easy to measure. It's like measuring developer productivity by LoC written.
Yes, it'll measure how much time the candidate spent preparing for the interview, and how well they can jump through hoops. But it'll also deter the actual people you want in the team, the folks who know that leetcode has nothing to do with commercial coding, and see the leetcode test as a sign that your organisation has no clue and a bad management culture.
It also reminds me of the "EE"s who carry around a card in their wallet with:
V = IR
I = V/R
R = V/I
> But it'll also deter the actual people you want in the team
All the FAANG companies do leetcode testing, so you can write off the high paying jobs.
I guess that staying as a valid test then - if a company uses leetcode for its interviews, it's probably somewhere I don't want to work.
People don't like Leetcode because it's insulting to treat them like freshmen that know nothing but algorithms that related poorly to the job at hand; can't judge them on coding prowesses, for most of them.
Wait, why am I explaining this to you like you're ready to listen beyond your monologue?
I have a friend who is a tech recruiter. There are an awful lot of frauds trying to land programming jobs. Hiring a fraud can cost a company a great deal of money. It shouldn't be any more insulting than applying for an accounting job and the employer does a routine background check to ensure that the candidate is not an embezzler, and not a drug addict.
I worked for a company that hired a coke addict. What a financial disaster that turned out to be.
Having a history of embezzlement or fraud is not in the same ballpark as struggling to whip up a DSA solution. One is a crime and one is a competence issue at best.
Too many frauds have managed to get degrees. I've worked with many of them. Degree'd engineers who cannot use a calculator, who cannot do basic geometry, etc.
If my Googling is correct, you will have chances to retake the strength test. Even if they only give you one try, you know exactly what is tested and can train to the point of near-certainty that you will pass, if your body is capable of it at all. (By contrast, leetcode doesn't care if you could learn a problem, it fails you for not figuring it out on a particular day with a particular interviewer.)
The best jobs can set an arbitrary high bar that loosely correlates with what they want, but it doesn't mean anyone who fails is unqualified to have any software job.
That's where studying it in advance comes in. Like for any test.
> but it doesn't mean anyone who fails is unqualified to have any software job.
It's pointless to argue absolutes when it comes to anything human. Filters do not have to be perfect to be effective.
For example, if I say "people like ice cream" and the pointless reply is "not everybody likes ice cream".
Indeed, but you're likely to end up a crappy for-profit degree mill that will be more of a negative signal than the positive one you wanted.
You got my vote right there. I also find it funny that LLMs can easily do leetcode problems, because there were so many examples and easy test cases.
> You do not get a better signal about that from asking harder leetcode problems.
I think this is a thing that needs bigger formatting for this statement or a feature to vote twice.
---
Only response I have to this:
There are many different schools of thought on how to architect systems. In many cases these different opinions don't have a lot of solid backing on why you'd do this. On top of that there is level restrictions that prevent talented individuals from being more influential. I.e. an Architect is less about technical experience and excellence and more about the abiltiy to communciate to high level stakeholds and having systems that can solve the problem [some what].
I have been looking for resources that tackle/teach/learn this translation part, but so far hasn't gotten any hits. Can anyone here point me to such a resource, if it exists?
The problem is that the compensation was so generous, and the kind of questions being asked so public, that your typical somewhat less talented, yet hard working grads would just cram for the interviews, and get past them, thus lowering the value as a filter. Leetcode and the like decided that there was an industry in helping you cram. The filtering got worse and worse, and the companies then decided to keep upping demands, hoping to still get the most talented. But there's nothing in a leetcode interview that cannot be trained. So the metric became the target, and we ended up in the current mess.
I agree with you but this is a "simpler" test with a subjective analysis. Big Tech works at a scale where they probably want to quickly evaluate based on objective results. Did they crack the problem or not? Imagine having a pool of 1000+ candidates for a single role.
To filter out the other 499, they can either ask a very difficult question, which based on the previous paragraph we have established is not a useful signal, or we can use a random number generator. Asking a very hard question also rewards luck in a different way, because a candidate who is lucky enough to have recently memorized that question or a similar one will be able to pass it. It does not generalize to anything actually useful for the job.
I submit that the random number generator is a faster and cheaper method.
What I want to know is whether someone has basic DSA understanding. Is the person familiar with any programming language. Can they translate business requirements into code? Can they disambiguate weird things PMs say into a viable plan?
You do not get a better signal about that from asking harder leetcode problems.
Never once in my career has writing a tricky algorithm under time pressure been relevant. The closest thing I can think of is debugging complex systems in an outage, but then it’s more like familiarity with bash commands and general debug skills.
As for LLMs and coding, companies need to figure out how to differentiate good and bad outputs here and what lasting engineer inputs to select for. And I don’t have any idea about this.