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

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