Interviewers aren't perfect. Most are happy to be asked clarifying questions.
No, this isn't about rote memorization to pass an interview. It's about meeting basic qualifications to be a software developer. I can't imagine any reasonable technical manager wanting to hire an experienced dev who doesn't know SOLID.
I have been a software developer for >25years now and I have literally never found any of the SOLID principles that useful. Barbara Liskov herself says the Liskov Substitution principle is supposed to be an informal rule, not an absolute principle [1] for example.
I would consider any place that thought knowing SOLID was an absolute requirement to joining to be a place I would not want to work.
My guess is you actually apply them and find them useful every day that you work, you're just not thinking about them as "the SOLID principles", they're just the things you've learned through experience that make software easier to maintain.
I don't think it's a red flag if a candidate is unable to regurgitate the acronym, but it is a red flag if a candidate doesn't understand that it's generally bad to mix concerns, or generally bad to write software in a way that forces you to modify existing modules to add related functionality instead of extending them, or that it's generally bad to make your interfaces (lower case i) wider than they need to be, or that it would be generally bad to write a child class that can't be substituted for a parent class, or that it's generally bad for a unit to construct its own dependencies.
They became principles for a reason, they didn't just come to be so that interviewers can ask about them.
So the intellectual exercise leaves me cold. I, too, have read of them (SOLID) dozens of times and can never Remer them.
I just had another look and the Liskov one reminded me: Class derivation is bad, the reason one of the reasons OO is so awfully hard, so, no, i do not remember it
Sorry Uncle Bob. Love your work, disagree with your opinions
Single responsibility is a rock solid principle, and it's a shame it's included on a jargon that is almost completely about OOP ideology instead of good quality software.
I see what you did there :)
LSP is the most fundamental in my view, anywhere you have a distinction between interface and implementation, and developers should be aware of it.
DIP is not really a principle, but a recipe of how to invert a dependency when needed. This is also something a developer should know.
SRP is somewhat ill-defined, because there is no objective criterion of what exactly constitutes a “single” responsibility. It’s similar to Unix’ “do one job and do it well”, though. It’s at least a consideration one should be familiar with.
OCP is arguably the most vague one, and also the most impractical if interpreted literally (“don’t ever modify existing code”). In the prototypical example of the Unix file interface (open/read/write/close), it however describes a pattern of defining an interface that abstract over different (and, importantly, future) implementations (as afforded by Unix’ “everything is a file” abstraction).
ISP is a balancing act. Taken literally, it can result in an explosion of interfaces, one for each single use, in the extreme case. However, it points to the fact that “rich” interfaces create higher coupling between components.
All of this is not specific to OOP. It applies to the design of REST interfaces and to microservices just the same, for example.
While there is no special reason to group these five considerations in particular into one thing (it’s just what occurred to Robert Martin some 30 years ago), it at least gives well-known names to them, which is a useful thing in itself. Like design patterns, the valuable thing is that it defines a shared vocabulary to refer to the respective concepts.
A software developer doesn’t necessarily need to know these considerations by those names, but he/she should have an awareness of these considerations, and knowing some names they are commonly referred to is a useful bonus.
A lid for every pot. In such a workplace it probably is a good interview question, at least for a senior role where you’ll be expected to already know the culture, tools, and norms of that kind of place to hit the ground running.
This is especially true for self learners / autodidacts or anybody else that's struggled with a problem, invented a solution and the only later found out that their solution is one of a few widely accepted solutions to $problem.
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.
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
Whatever the principles are, I've probably got opinions about though, if the interviewer wants to hear my opinions to know if I've got independent thoughts (I do!) and if my thoughts are compatible with how the company runs their business (they might be, but I do swing hard cowboy on the process spectrum of cowboy to aerospace; I am somewhat adaptable though)