[seanhunter]

I find that genuinely absurd. Knowing SOLID is very very far from being a basic qualification to be a software developer. It's a specific piece of jargon that's used in a particular type of place that goes for the whole Java/Agile thing for the most part.

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.

[1] https://www.youtube.com/watch?v=-Z-17h3jG0A

[mbrameld]

> I have been a software developer for >25years now and I have literally never found any of the SOLID principles that useful.

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.

[worik]

I gave up on OO programming over ten years ago (twenty mayby)

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

[n_plus_1_acc]

That would ironically be a good answer to the interview question

[nuancebydefault]

I think application of principles and best practices are often overrated. For one, best practices change over time. This means they were not best. Also, principles are just principles, they are rules with exceptions and apply in contexts and limitations. I find the DRY principle very useful for keeping code maintainable, but if applied at absurdum, the code becomes too abstract to be even comprehensible.

[Retric]

IMO an interviewer asking about SOLID is a great sign you should go work for someone else.

[marcosdumay]

> I have literally never found any of the SOLID principles that useful

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.

[alfons_foobar]

> rock solid principle

I see what you did there :)

[layer8]

Not all of the five “principles” are created equally.

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.

[bradleyjg]

It's a specific piece of jargon that's used in a particular type of place that goes for the whole Java/Agile thing for the most part.

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.