[jacamera]

There's some good advice here but I take issue with this statement:

> I used to ask ‘tell me one of the SOLID principle you strongly agree or disagree with’ but I had to stop because it ended up with the interviewee listing/describing the SOLID principles rather than critiquing them.

How many people have internalized every part of SOLID such that they can immediately start critiquing one of the items?

I learned about SOLID in some book 10+ years ago and I'm going to need a minute to remind myself what the acronym stands for. It's a sign that I'm taking your question seriously rather than just giving pros and cons of the first random thing that pops into my head.

I think this is just a bad question and that it reflects poorly on the author that they automatically assumed the fault lies with the majority of interviewees.

[patrickthebold]

The author seems like a reasonable person. IMO the best response is something like: "I don't remember the acronym specifically, remind me of the principles and I'll tell you which I feel are the most and least important."

Interviewers aren't perfect. Most are happy to be asked clarifying questions.

[sumeruchat]

That’s exactly my answer every time.

[lopkeny12ko]

This is a gotcha question, but all things considered, a pretty good one. "I don't remember/know what SOLID is" is the wrong answer, and an easy way to screen out candidates.

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.

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

[buttercraft]

It's possible to understand a concept without knowing what names other people have attached to it afterwards.

[baby_souffle]

> It's possible to understand a concept without knowing what names other people have attached to it afterwards.

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.

[joquarky]

Being counted off for not "showing your work" even when you got the right answer was extremely frustrating.

[layer8]

Having a shared vocabulary is useful, though. That’s the whole point of design patterns, for example. That you don’t have to explain what you mean from scratch every time, but that you can say “decorator” and everyone knows exactly what you mean.

[cqqxo4zV46cp]

I pray that we never ever cross paths professionally then. This is absurd thinking that stinks of green behind d the ears hubris. I could easily see that one could internalised the principles of SOLID to such a degree that they can’t just list them off. Rather, they have ingested SOLID as one of the many sources of information that comprise their own internal sense of professional competency and judgement. In fact, I’d put myself in that bucket, as I’ve proven just now. I had to go to Wikipedia to refresh my memory, but at the same time no principle was new or surprising to me. If an interviewer reacted in the way you describe when interviewing me, it would to me be an extreme red flag, an indicator that my hiring manager would be an inexperienced rote memoriser that puts Uncle Bob on a pedestal in lieu of being to think for themself. Ridiculous.

[realusername]

I don't remember what it stands for myself and I conducted a good hundred interviews. All of those questions are useless to filter candidates and don't give you any insights either way in my opinion.

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.

[lopkeny12ko]

I lead a team of about 10 engineers, and have also interviewed hundreds of candidates over the last few years. I can tell you with certainty that the same candidates who say they don't know what SOLID, KISS, and DRY are, are the same candidates who are poor problem solvers and communicators in the more technical portion of the interview.

[spacedcowboy]

I've never heard of SOLID before today. I'm a senior engineer at a FAANG company - about as senior as you get, actually. I've designed operating systems for novel hardware, implemented kernel extensions, written device-drivers for hardware that doesn't even exist at the time, and debugged the same. I've changed shipping applications to run literally orders of magnitude faster by adopting new technologies, and I've written code in daily active use on hundreds of millions of devices today. I tend to be given exactly the multi-functional cross-team "difficult" system-design problems that you're talking about.

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.

[morgante]

I wouldn't put SOLID in the same category as KISS/DRY. The latter are pretty universally understood principles, but I've never used SOLID despite passing dozens of challenging technical interviews and leading teams across startups and Google.

It's jargon from a subculture of enterprise Java, not a universal term.

[mbrameld]

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

[cqqxo4zV46cp]

It genuinely sounds like you’ve been working in a particular sub-field for your entire career and have let yourself be convinced that its echo chamber is actually the entire field of software development. You’ve essentially touted the wisdom of one (incredibly far from perfect) tech influencer (Uncle Bob) as being some sort of sacred cow and self-evident truth. If you’ve had a successful career in software development it is in spite of your attitude, not because of it. All you’re asking of candidates is whether or not they follow the same cake-baking instructions as you. You’ve turned some guy’s list of tips and tricks into a religion. That’s not what engineering is.

[realusername]

Well to each their own, I've never seen any correlation between those and actual tech, product or interpersonal skills during the recruitment I've made.

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

[fsociety]

I’d rather see someone code, refactor, write tests, and debug than regurgitate acronyms like SOLID. In other crafts we accept that there is a difference between knowledge and experience. Software is no different.

[cqqxo4zV46cp]

SOLID is just some guy’s quote opinionated list of tips, which themselves overlap with KISS/DRY which are much more fundamental principles. This is either blatant moving of goalposts or (more likely) a glaring sign of inexperience on your part.

[toast0]

I can't say I have the slightest idea what SOLID is, but it hasn't been an issue for me. I even got an offer for a fresh grad position at a Software Engineering tools company around Burbank somewhere, whose name I can't remember, but my memory could be jogged.

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)

[rf15]

I'm almost at the point where my hiring decisions actually turn the other way - rattle down the SOLID principles and I feel like you're more occupied rote learning random SE bits than internalising what they were born out of. Every time I see the list of what SOLID stands for my eyes glaze over because, despite its name, it's not very solid (and frankly often awkwardly vague) advice on its own in my opinion.

[exe34]

Could you tell me what you think about people over process?

[hitchstory]

It's become almost a cliche as an interview question. That's the main reason I've thought about it enough to be able to critique it.

I think it's not necessarily a bad question assuming that the candidate can recite it. If they can, they probably should have thought about what it means.

I've met plenty of devs who can't recite it but who do it all instinctively though. That's why I'd rather see people demonstrate these principles while coding without using the term at all.

But, coding interviews are expensive and you need some way of sorting the 100 applicants into the 90 who can be ignored and the 10 who are worth an interview. This is a hard problem I've never found a really good answer to. OP's question isn't worse than most of the attempts I've seen.

[gopher_space]

> you need some way of sorting the 100 applicants into the 90 who can be ignored and the 10 who are worth an interview. This is a hard problem I've never found a really good answer to.

It's a solved problem but you need to take your engineers offline during the hiring process. This looks expensive if you're trying to increase headcount rather than fill actual positions.

[jupp0r]

I've also seen plenty of devs who can recite them and then blatantly ignore them when writing code.

[karmakaze]

This is a bad question in that most devs will have internalized several of the terms without attaching that unconscious knowledge with the SOLID terms. I'm always reminding myself which letter means which 'thing that I know'.

The stand-out one though is (S)ingle responsibility. (All the other letters (OLID) are mostly aspects of how to do interfaces/testing.) It means not only to pick an arbitrary thing and do that thing in a class/module. It covers the full gamut of naming things being hard. If you understand the problem, and how to decompose it effectively, then those are the things that get separated out as responsibilities. It's easier lower-down when you're working bottom-up.

Adherence to any buzzword has a potential for cargo-culting so always be aware of trade-offs and exceptions to the rule(s). An experienced dev should be able to convincingly describe the pragmatic benefits of any particular application of a rule.

A different thing that's rarely discussed which I find more valuable is distinguishing policy vs mechanism. This really gets to the heart of understanding and choosing your abstractions. If you do this part well, the things just name themselves.

I suppose then that I would respond to the question by picking one (if I have a strong opinion) and/or critiquing SOLID in general rather than letter by letter.

[mekoka]

My answer to this question would go along these lines.

SOLID is a flawed attempt at packaging "clean code" into a formula. The military sounding acronym itself is a stretch, as only the first principle is really of importance. Producing clean code in practice is going to be leaky. That's just a fact of life. It relies heavily on experience and tacit knowledge. I think it's the reason many senior programmers tend to repudiate (consciously or unconsciously) SOLID as their craft matures, and embrace instead a set of guidelines to produce code that (in more or less that order) works as expected, is bug free, is reasonably efficient, and is maintainable (i.e. is legible, understandable, testable, etc).

[layer8]

The author isn’t criticizing that an interviewee might not know the SOLID principles. They are criticizing interviewees who can recite the principles but apparently are unable to express an opinion on them.

The SOLID principles are actually a good example, because some of them are so ill-defined, and they are such an uneven combination of items, that it’s hard not to have second thoughts on them.

[csydas]

it’s just a bit too much for the question i think and it asks for opinion on a subject in an already stressful situation where the candidate is very eager to please and also had their mind in the context of answer with well reasoned technical arguments. I can easily imagine and many times have seen interviewers try to propose an opinion question like this only to spend time explaining to the candidate why the candidates answer is wrong.

It probably seems like a trap to many candidates and often it is a trap whether the interviewer meant it to be or not.

This isn’t to say that there shouldn’t be opinion questions but I wouldn’t position it like the author did in. at least how it’s presented it seems like it’s a fairly “big” question in the interview which candidates will pick up on as being important and questions of opinion can be nerve wracking in such a situation.

I also think that what the author is trying to test can be handled better; i am pretty sure the question is a measure of does the candidate think through their positions and can they defend it professionally, but i think there are better approaches, for example picking a common task with many ways to accomplish the task and asking the candidate how they’d do it and why it’s useful for them to use that method. For me at least i understand their approach a bit more and i like to hear about how they handle such situations in the way that’s most comfortable for them. that the task is one with many possible ways to accomplish it helps take the burden off the candidate in many cases as likely they know there are many approaches and it usually gets candidates to open up and talk about their projects and workflows. I often learn new perspectives on such tasks and telling the candidate as such calms them down a lot also since i genuinely like to hear new approaches. if there are elements i don’t understand, it’s a great question “oh that’s a new approach for me. can you explain a bit more how this method is useful for you?” (not exact words) which usually is a great way to get candidates to talk more as they see i want to hear their thoughts, not a specific answer; they know their answer is one of many right ones so there less burden there too.

i think the authors question is good intentioned but poorly executed.

[FireBeyond]

> How many people have internalized every part of SOLID such that they can immediately start critiquing one of the items?

There was a post here the other day (https://news.ycombinator.com/item?id=39460829) where someone was giving advice about interviewing at Amazon and knowing their "sixteen principles" because "they're not just words, here more than anywhere we live and breathe them". He even went on to talk about how they specifically used them all in interviewers, and "bar raiser" interviewers were chosen for their "deep and profound" understanding of them all (there was more than a slight narcissism and smug superiority in the article, if you ask me).

My thoughts were: "Quick, you work at Amazon. Name all sixteen principles that you live and breathe every day. That people are expected to have a deep and profound understanding of."

(My other favorite quote in that article: "I have certainly referenced Amazon's Principles when discussing parenting techniques".

[deathanatos]

> How many people have internalized every part of SOLID such that they can immediately start critiquing one of the items?

You don't need to have internalized every part of SOLID to answer the interviewer's question. You need to have internalized a single part.

I can only remember two letters myself: the "S" (the Single Responsibility Principle) — which seems like the unforgettable letter in the thing — and the L. That would suffice to answer the interviewer's question.

(I'm not sure I agree with the interview question, as I'm not sure what I, as an interviewer, would hope to glean from it.)

[UncleOxidant]

For fun I just asked BingChat/Copilot this question and it really likes the Single Responsibility Principle - it wrote a couple of paragraphs on it and then offered a code example in PHP. I'm looking forward to the day when we can just sent our AI avatar to interviews, it'll save so much time and stress. ;-)

[baby_souffle]

> I'm looking forward to the day when we can just sent our AI avatar to interviews, it'll save so much time and stress. ;-)

We already can! I recently went through the "can you code?" phase of the interview pipe and they had me use a shared code IDE thing that ... had chatGPT integration.

The prompt was simple and I put in a paraphrased version of it into the chatGPT pane and ... the proposed solution was _almost_ correct. The coding question had one small wrinkle that could be accommodated by making a small tweak to the proposed solution.

I don't know if this was "free" gpt or the version that has code execution; I didn't bother pushing GPT to run and evaluate the code / correct its proposed solution against the test cases that the interviewer provided... but it almost certainly would have quickly figured out the wrinkle and adapted.