Many of these questions are very vaguely scoped which gives the confident and familiar plenty of room to show how clever they are, but also makes it more intimidating for those who haven't seen them before.
Or, to put it another way, the linked site looks like a great way to make yourself look like you have a junior-to-mid-level understanding of a lot of different areas. But the process it's optimizing for starts to break down the more senior a developer you either (a) are or (b) are trying to hire.
If you're interviewing for a front end position, you can make a nod to interrupts and continue on with BGP, ARP, DNS, TCP, IP, routers, etc. If you want to show your knowledge of security you could mention heartbleed, poodle, or even say why this isn't vulnerable to shellshock. An overview will take a minute, and the interviewer will follow up with more targeted questions if needed. It's a chance for the candidate to shine.
I'm always ready when asking something very open ended to follow up after 15 seconds or so to say "let's talk about [area X] first." For URLs, maybe this is "let's talk about what the actual network request, if you sniffed the traffic, looks like."
Exactly :)
Well if someone claims to be "full stack" - yes.
"Every step?" Not at all true, in my experience.
What you need is a reasonable sense for the breadth and depth of the topic -- which quickly reveals itself to be far broader and deeper than what most engineers (including many very capable people I know) can hope to "absolutely understand every step of". And the ability to drill down (and go down rabbit holes) when needed. Combined with the experience of actually having gone down more than a few (and having from relatively unscathed, eventually).
In fact, if anything, your observation isn't just overstated - it actually misses the point of what makes some of the most effective people as effective as they are: their ability to manage complexity, and in particular, their ability to (reasonably) "connect the dots" in a complex system despite not "absolutely" knowing, at every level of detail, how every component in that system works.
Mind you, for the right value of "reasonably". It's when knowing when their level of understanding, while imperfect, is still good enough to solve the problem at hand - and when it isn't - is that makes these people so effective.
I don't see that question as being any different really. They're both just ways of guiding a conversation around the area we work in to gauge what candidates know / are interested in.
Personally, I've poked around in Postgres a bit because I find it interesting. And having deeper knowledge means that when you're about about to add a new not null column with a default value to a massive table you can stop and reason through how you're about to shoot yourself in the face :-)
You need to have a bit of an idea, sure.
But in order to give any kind of a meaningful answer to the question, you need to have not just a "bit of" an idea, but in act, a deeply solid and intuitive idea. Either that or -- crib the answer from websites like these, know that it's one of the top 30 questions you're likely to be asked.
Which, very sadly, is exactly what the modern interview process (greatly) incentives people to do, these days.
Do they talk about tables? What about indexes? How about sql? Do they ask enquire about the requirements / data model?
Interesting, because as soon as I got over the "why the hell do you want to create a new DBMS?" question, my first thought was about filesystems. I haven't digged into any DBMS to look at, but all those you point look so easy when compared to atomic data writing...
Questions are not inherently bad. It's how the interviewer interprets the answer, and whether it's used as a gateway to a discussion or a one way q&a session.
If your default answer is "Just use PostgreSQL until something screams at us that we shouldn't" then you are correct, you don't need to know about database systems.
Yet, these will be the same people screaming to use <flavoroftheweekQL> instead just using PostgreSQL.