6 ms·

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

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.

lopkeny12ko 3y ago
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.
- realusername 3y ago
  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 3y ago
    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.
    - realusername 3y ago
      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
    - morgante 3y ago
      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 3y ago
        > 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.
        morgante 3y ago
        > You don't need to memorize the acronym, but saying you've "never used SOLID" isn't the brag you think it is. You said that if "they don't know what SOLID, KISS, and DRY are, are the same candidates who are poor problem solvers." I've written plenty of maintainable software, but there are whole realms of software outside enterprise OOP. I have 0 interest in memorizing specific jargon.
        lopkeny12ko 3y ago
        > I've written plenty of maintainable software This may very well be true, and I'm not saying it is not true, but after working in software for multiple decades, I can tell you that many developers think they are much better than they actually are. > I have 0 interest in memorizing specific jargon. This isn't about memorizing jargon. It's about understanding the basics of enterprise software development. It is no more "memorizing jargon" than knowing the difference between private and public interfaces. Do you study and memorize the definitions of private and public methods in order to pass an interview? Of course you don't--this is something you know by virtue of having written production software. I would be hard pressed that you would even consider spending more time interviewing candidate who can't tell you the difference between private and public methods. "Tell me about SOLID, KISS, and DRY" is another question in the same bucket of fast screening questions.
    - spacedcowboy 3y ago
      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.
    - fsociety 3y ago
      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 3y ago
      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.
    - cqqxo4zV46cp 3y ago
      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.
- toast0 3y ago
  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)
- buttercraft 3y ago
  It's possible to understand a concept without knowing what names other people have attached to it afterwards.
  - baby_souffle 3y ago
    > 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 3y ago
    Being counted off for not "showing your work" even when you got the right answer was extremely frustrating.
  - layer8 3y ago
    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.
- seanhunter 3y ago
  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 https://www.youtube.com/watch?v=-Z-17h3jG0A
  - Retric 3y ago
    IMO an interviewer asking about SOLID is a great sign you should go work for someone else.
  - mbrameld 3y ago
    > 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.
    - nuancebydefault 3y ago
      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.
- exe34 3y ago
  Could you tell me what you think about people over process?
- cqqxo4zV46cp 3y ago
  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.
- rf15 3y ago
  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.
sumeruchat 3y ago
That’s exactly my answer every time.

lopkeny12ko 3y ago

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.

realusername 3y ago
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 3y ago
  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.
  - realusername 3y ago
    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
  - morgante 3y ago
    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 3y ago
      > 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.
      - morgante 3y ago
        > You don't need to memorize the acronym, but saying you've "never used SOLID" isn't the brag you think it is. You said that if "they don't know what SOLID, KISS, and DRY are, are the same candidates who are poor problem solvers." I've written plenty of maintainable software, but there are whole realms of software outside enterprise OOP. I have 0 interest in memorizing specific jargon.
        lopkeny12ko 3y ago
        > I've written plenty of maintainable software This may very well be true, and I'm not saying it is not true, but after working in software for multiple decades, I can tell you that many developers think they are much better than they actually are. > I have 0 interest in memorizing specific jargon. This isn't about memorizing jargon. It's about understanding the basics of enterprise software development. It is no more "memorizing jargon" than knowing the difference between private and public interfaces. Do you study and memorize the definitions of private and public methods in order to pass an interview? Of course you don't--this is something you know by virtue of having written production software. I would be hard pressed that you would even consider spending more time interviewing candidate who can't tell you the difference between private and public methods. "Tell me about SOLID, KISS, and DRY" is another question in the same bucket of fast screening questions.
  - spacedcowboy 3y ago
    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.
  - fsociety 3y ago
    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 3y ago
    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.
  - cqqxo4zV46cp 3y ago
    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.
toast0 3y ago
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)
buttercraft 3y ago
It's possible to understand a concept without knowing what names other people have attached to it afterwards.
- baby_souffle 3y ago
  > 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 3y ago
  Being counted off for not "showing your work" even when you got the right answer was extremely frustrating.
- layer8 3y ago
  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.
seanhunter 3y ago
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 https://www.youtube.com/watch?v=-Z-17h3jG0A
- Retric 3y ago
  IMO an interviewer asking about SOLID is a great sign you should go work for someone else.
- mbrameld 3y ago
  > 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.
  - nuancebydefault 3y ago
    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.
exe34 3y ago
Could you tell me what you think about people over process?
cqqxo4zV46cp 3y ago
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.
rf15 3y ago
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.

sumeruchat 3y ago

That’s exactly my answer every time.