10 ms·
You're right but you or more precisely that interviewer is also wrong. Understanding the way your storage works is crucial, yes. But you ensure people understa
by p2t2p 5y ago
You're right but you or more precisely that interviewer is also wrong.
Understanding the way your storage works is crucial, yes. But you ensure people understand it not by asking "Explain ACID to me" but by asking to design a certain system and observing them figuring out requirements and asking questions. You then ask follow up question about consistency and reliability, you probably even can ask about benefits of using transactions but I wouldn't because there's plenty of databases that can be used reliably that don't have transactions.
Life is more complex than ACID, that's it. Investigate if person understands life, not that they were able to memorise bunch of magic acronyms.
For the life of me I don't remember what SOLID is and I totally fail to parse any written explanation of liskov substitution principle but whenever I see code that violates those I immediately go "please don't do this, that'll cause problems in the future".
- MauranKilom 5y ago> I totally fail to parse any written explanation of liskov substitution principle Off the top of my head, "all child classes should be usable interchangeably when dealing with an interface/base class". I guess that's too imprecise to qualify as "written explanation"?
- Koshkin 5y agoThis doesn’t sound correct to me. The original statement is, Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T. Here, objects of a base class are replaced with objects of derived classes.
- rfrey 5y agoI interviewed a guy once who used rho instead of phi when I asked this question. What a bozo.
- marcosdumay 5y ago> This doesn’t sound correct to me. Yet the GP says exactly the same thing as you said. He just ignored that the property belongs to the base class.
- kragen 5y agoThe GP said "usable interchangeably", which is vague enough to admit a wide variety of interpretations, including the more rigorous one Koshkin posted.
- marcosdumay 5y agoYet he got unambiguously declared wrong...
- karmakaze 5y agoOr 'is a' implies 'behaves as a'.
- tinco 5y agoExactly, the acronyms should be viewed as tools for the interviewer, not as trivia for the interviewee to know. Asking the interviewee to explain ACID or SOLID is fine, but if they don't know the acronyms that shouldn't be an instant fail, it just means the interviewer has to put in a little more effort. The interviewer should go deeper and say "Given we're using this data to do this, which of the options of the MongoDB insert should we use?" or for SOLID, show them a piece of code and ask "What criticism do you have for this code? How would you refactor it?". Given how some people study for these interviews, you might be better off going deep either way, to avoid getting rehearsed answers on these trivia questions.
- tchalla 5y ago> Understanding the way your storage works is crucial, yes. But you ensure people understand it not by asking "Explain ACID to me" but by asking to design a certain system and observing them figuring out requirements and asking questions. You then ask follow up question about consistency and reliability, you probably even can ask about benefits of using transactions but I wouldn't because there's plenty of databases that can be used reliably that don't have transactions. Who has time for that? Interviewers design interview for themselves, not for the interviewees. It's basically a trivia game at this point of time. A prime example of "Everything is obvious once you know the answer" syndrome.
- ivanhoe 5y agoNow that is up to the skill of an interviewer how will they approach it. Often you're time-limited and can't do actual code testing, and acronyms and buzzwords can be useful to do the initial filtering quickly. Of course, not expecting for candidates to reproduce what each letter means, but to show they've heard of it and have some idea what it's about. > For the life of me I don't remember what SOLID is and I totally fail to parse any written explanation of liskov substitution principle but whenever I see code that violates those I immediately go "please don't do this, that'll cause problems in the future". In my book this is a perfectly valid answer to that question, actually far better than just citing the book definition blindly. Interviews are all about trying to read between the lines, and often the whole impression of competence that candidate leaves to you is far more important than the actual answers.