I feel that this is a perfectly good interview question for a so-called "full stack developer":
> Let's turn to databases now. Can you explain ACID to me?
I'm not saying that the original article on RoyalSloth was wrong, exactly. It has to do with the way the interviewer approaches the question. For instance, for that full-stack developer I would be PERFECTLY satisfied with an answer that went like this:
> Hmm. Well, I don't remember exactly what the letters stand for. Atomic, something something. But look -- some databases, like MongoDB, can sometimes lose data after it has been "committed". Other databases, like DynamoDB, can read just fine from one table but they can't guarantee some basic invariants when reading from multiple tables at once. And some others, PostgreSQL and most "relational databases" fit in this category, jump through hoops (I don't know quite how it works) to make certain that what you see is always consistent.
If I were hiring someone JUST to do front-end web design then this wouldn't be relevant. If it's someone more junior then the above sentiment but without the ability to name specific examples would be fine. But I don't want to hire someone to work on interfacing with the database unless they understand it to at least this level.
If I were hiring for a database specialist I would expect a much more detailed explanation.
> Let's turn to databases now. Can you explain ACID to me?
I'm not saying that the original article on RoyalSloth was wrong, exactly. It has to do with the way the interviewer approaches the question. For instance, for that full-stack developer I would be PERFECTLY satisfied with an answer that went like this:
> Hmm. Well, I don't remember exactly what the letters stand for. Atomic, something something. But look -- some databases, like MongoDB, can sometimes lose data after it has been "committed". Other databases, like DynamoDB, can read just fine from one table but they can't guarantee some basic invariants when reading from multiple tables at once. And some others, PostgreSQL and most "relational databases" fit in this category, jump through hoops (I don't know quite how it works) to make certain that what you see is always consistent.
If I were hiring someone JUST to do front-end web design then this wouldn't be relevant. If it's someone more junior then the above sentiment but without the ability to name specific examples would be fine. But I don't want to hire someone to work on interfacing with the database unless they understand it to at least this level.
If I were hiring for a database specialist I would expect a much more detailed explanation.