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.
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 :-)