[John23832]

If you want to explain what a timeseries db is to someone who has no clue in a 45 minute (already time constrained) systems design interview (where you’re supposed to be actually showing how you would design a system), be my guest.

[sophonX]

The issue could be time management and every database has same set of features but different implementations. One of my teammate keeps talking and sometimes loses the context. We usually step and get on track. He has improved a lot in past few months. You might be in similar boat.

[John23832]

I know how to give concise descriptions of complex problems. The issue was that the interviewer didn’t understand the proposed tool.

Every db definitely does not have the same set of features. The read and write characteristics of dbs vary widely, the underlying storage and indexes vary as well.

There’s a huge difference in usecases between postgres (relational), redis (in memory cache), and influxdb (timeseriese)

[sophonX]

You are supposed to structure it. I know their internals on a high level but I work with internals of a oss engine. I know how their read / write paths vary, data structures for storage, for locking, for request scheduling, checkpointing algorithms, scheduler, etc.

The point is you've to structure your knowledge in a way the other person can understand. There is no value for any company, if you can't share whatever knowledge / experience you've in a structured format.

Not everyone is familiar with internals of commonly used tools but the underlying patterns or concepts remain the same.

If you can't explain that, then you are lacking in communication skill or maybe no one ever gave you feedback. It's just a matter of time.