[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.