On (No)SQL being fast
During the last few design interviews I conducted, the candidate said something along the lines of
- I’ll use NoSQL because it’s faster
- I’ll use a SQL database because it’s more reliable
-
about some database
Throwing such a statement reflects poorly on the candidate in my opinion as it shows a shallow understanding of different types of databases and/or an attempt at showing off by throwing some buzz words.
For starters, the boundary between SQL and NoSQL became pretty fuzzy over time – e.g. PostgreSQL handles unstructured data fine and many NoSQL databases support SQL. I’m honestly not even sure it makes sense to classify databases as SQL or NoSQL today but with that being said, both technologies exist today because they have their pros/cons.
Rather than regurgitating some key words, candidates should understand them and figure out if they apply for their given problem (or interview). If they don’t understand databases deeply, it’s OK – I personally do not expect every candidate to be a database expert, but I do expect intellectual honesty.
For what it’s worth, design interviews are meant to evaluate a candidate, to find both their area of strength and weaknesses. If they venture into domains they are not familiar with (by throwing some buzz words), they will lead the interviewer toward their weaknesses. It’s basically a terrible strategy.
My recommendation is to study a few topics but study them well – if they are related to your personal experience/work it’s even better. Be honest during the interview about domains you are not expert with and lead the interview to places you’re more familiar/have more expertise.