I agree with your concern, but also want to point out that SOLID principles does not apply to OOP only, but for Functional Programming as well as more higher-level design such as system architecture. If you take a look at the 12-factors, most of the concepts can be compared to SOLID principles as well as Q8 about nothing shared architecture.
So SOLID is actually a more general approach and the awareness of it is particularly useful. Maybe if the expected answer shouldn't be what every single one of them means, but maybe with examples of how applying those can help with building a better architecture/system/code.
You are correct. I shouldn't have gotten hung up on OOP. But my point still stands: Do you care about the ideas or about the acronym?
What about candidates that come from coding academies, or that went to school in non-english-speaking countries? If they understand the concepts but have never heard the acronym, are they at a disadvantage?
My guess here is that you will say "No, or course not", but that the very nature of the question itself will create scenarios where the candidate acts uncertain, and this will cause unconscious bias in your impressions as the interviewer.
But it's also means they don't speak the common idiom and it's going to be harder to integrate into the team/project/culture. It sucks to filter out those kind of candidates, but it's a heuristics to filter some candidates in case you have a lot. Depends on what kind of role you're looking to fill.
I would propose that if the idiom is so important to the integration of people into your team and culture, that your team and/or culture is exclusionary, and you have a much bigger hiring and staffing problem than "how to effectively interview developers".
Idioms and Acronyms that are unique to the team/firm are something every new hire has to deal with, but it's usually not hard to get up to speed, all it takes is an atmosphere where colleagues welcome questions (i.e. a "there are no stupid questions" attitude).
I agree with that, but that's the only differential in a candidate that is put to a scale, you choose the one that knows, so it's a priority criteria and not an exclusion one.
And you can say SOLID is not unique to team/firm but a more broad one. It's definitely weird to ask a candidate about unique stuff for your company (I've seen it and you shouldn't)
Respectfully, I think that's a poor criterion even as a "priority vs exclusionary" one - seems the risk is high - or at least makes the selection completely arbitrary - of missing on the better candidate on the basis of not recalling an acronym, which carries no practical value when the candidate understands and practices the concepts it represents. I truly hope not many think the way you do, and I mean that as kindly as possible. But something so trivial should never be "the only differential in a candidate" - you ought to find some more meaningful way to distinguish candidates if you want to be successful.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with your concern, but also want to point out that SOLID principles does not apply to OOP only, but for Functional Programming as well as more higher-level design such as system architecture. If you take a look at the 12-factors, most of the concepts can be compared to SOLID principles as well as Q8 about nothing shared architecture.
So SOLID is actually a more general approach and the awareness of it is particularly useful. Maybe if the expected answer shouldn't be what every single one of them means, but maybe with examples of how applying those can help with building a better architecture/system/code.
You are correct. I shouldn't have gotten hung up on OOP. But my point still stands: Do you care about the ideas or about the acronym?
What about candidates that come from coding academies, or that went to school in non-english-speaking countries? If they understand the concepts but have never heard the acronym, are they at a disadvantage?
My guess here is that you will say "No, or course not", but that the very nature of the question itself will create scenarios where the candidate acts uncertain, and this will cause unconscious bias in your impressions as the interviewer.
But it's also means they don't speak the common idiom and it's going to be harder to integrate into the team/project/culture. It sucks to filter out those kind of candidates, but it's a heuristics to filter some candidates in case you have a lot. Depends on what kind of role you're looking to fill.
I agree it's not perfect, but it's a trade-off.
I would propose that if the idiom is so important to the integration of people into your team and culture, that your team and/or culture is exclusionary, and you have a much bigger hiring and staffing problem than "how to effectively interview developers".
Idioms and Acronyms that are unique to the team/firm are something every new hire has to deal with, but it's usually not hard to get up to speed, all it takes is an atmosphere where colleagues welcome questions (i.e. a "there are no stupid questions" attitude).
I agree with that, but that's the only differential in a candidate that is put to a scale, you choose the one that knows, so it's a priority criteria and not an exclusion one.
And you can say SOLID is not unique to team/firm but a more broad one. It's definitely weird to ask a candidate about unique stuff for your company (I've seen it and you shouldn't)
Respectfully, I think that's a poor criterion even as a "priority vs exclusionary" one - seems the risk is high - or at least makes the selection completely arbitrary - of missing on the better candidate on the basis of not recalling an acronym, which carries no practical value when the candidate understands and practices the concepts it represents. I truly hope not many think the way you do, and I mean that as kindly as possible. But something so trivial should never be "the only differential in a candidate" - you ought to find some more meaningful way to distinguish candidates if you want to be successful.