I know of the KISS and DRY principles - I think they're widespread, I've just gone and looked up SOLID and it seems like "sensible object-oriented design", but it's not an acronym I've ever come across in the last 30-odd years of professional software development. I don't think it's in the same category as the first two.
It's jargon from a subculture of enterprise Java, not a universal term.
The name itself might be, but the principles apply to software development in general. You don't need to memorize the acronym, but saying you've "never used SOLID" isn't the brag you think it is. If you can get past the acronym and understand the actual principles I think you'll find they apply to most software you write. Unless you never have to maintain the software you write, then it's super easy to go a whole career without understanding the SOLID principles. It's the "20 years of experience" vs "20 * 1 year of experience". Folks in the former group generally understand the SOLID principles even if they can't name them. Folks in the latter group will insist they don't apply to the software they've written in their long and storied careers of job hopping.
You said that if "they don't know what SOLID, KISS, and DRY are, are the same candidates who are poor problem solvers."
I've written plenty of maintainable software, but there are whole realms of software outside enterprise OOP. I have 0 interest in memorizing specific jargon.
This may very well be true, and I'm not saying it is not true, but after working in software for multiple decades, I can tell you that many developers think they are much better than they actually are.
> I have 0 interest in memorizing specific jargon.
This isn't about memorizing jargon. It's about understanding the basics of enterprise software development. It is no more "memorizing jargon" than knowing the difference between private and public interfaces. Do you study and memorize the definitions of private and public methods in order to pass an interview? Of course you don't--this is something you know by virtue of having written production software.
I would be hard pressed that you would even consider spending more time interviewing candidate who can't tell you the difference between private and public methods. "Tell me about SOLID, KISS, and DRY" is another question in the same bucket of fast screening questions.
Google3 is one of the biggest repositories of enterprise software in the world.
I've been in dozens of engineering design reviews and SOLID has literally never come up.
> Do you study and memorize the definitions of private and public methods in order to pass an interview?
There's a pretty major distinction: public and private methods are part of the language.
SOLID is a set of buzzwords invented by a random influencer and propagated through a subculture. I glanced at them quickly and the principles seem generally sound, but I wouldn't interview based on knowing them by name.
Probably a better programmer than you. Do you know who is Linus Torvalds?
Do you even have a Putnam?
I'm not sure how knowing the SOLID acronym would make you a better communicator anyway even in theory. Maybe you could argue for tech skills even if I disagree but the other ones aren't even remotely close.
To gauge for problem solving skills, asking for problem solving on examples proved to work very well in my experience, you instantly see the candidate's priorities and thinking flow.
Edit: Also I do think KISS and DRY are much more widespread terms across the industry than SOLID is but I would not use them either in interviews personally
What I'm trying to see is the problem solving thinking flow, interpersonal skills, culture fit and the level of product skills. None of the trick questions help on that. We're living now in a world where the small details are a Google search away anyways.