This is exactly why we do this. It gives candidates a chance to choose what they want to diagram for us. What do you know well?

If you havent designed a system from scratch, or designed a major change, you arent a senior engineer.

these "system design interviews" often focus on systems at the scale of major consumer internet companies, e.g. "design youtube", "design twitter".

How many systems of that scale even exist? 100? Only the core developers of those systems would be considered "senior engineer"?

Someone isn't going to design one of these system or has designed some of these systems themselves or during an interview. However for something like YouTube one could say Ok to start simply I would have a frontend form to submit videos, which sends it to a video conversion API queue that calls back when it is completed or could be polled for progress. Now obviously what YouTube really does is much more complicated. But the follow up questions could be like OK your form works and now your video site becomes enormously successful and your video transcoder is overloaded, what would you do? Well I could parallelize the consumers of the queue to some large number, and scale based on load...

So isn't going to be something like I would architect my own massively parallel converter database and binaries written from scratch to process all the various formats which is probably closer to what is done in reality. But senior and lead engineers should indeed understand tradeoffs, parallelization, queues, data storage concerns. They are given as questions because people know from a use case view how they generally work.

When I interviewed at Facebook my system design question was for a Yelp-ish clone that would be rolled out to Facebook as a whole. The interviewer told me the design had to be scalable to 1 billion daily users on day 1.

It doesn’t take a ton of scale to hit limits in traditional 3 tier architecture. I think many many companies have similar designs but built with OSS.

If you carry this attitude, you aren't a senior engineer.

> database systems

When was the last time building a database from scratch was a sane approach to building something?

In 2023 knowing which AWS database to choose, even if it’s hosted for you is probably ok for the system design level. Knowing when to use a queue or a load balancer etc is ok even if you didn’t engineer the queue. The company you’re going to probably isn’t implement their own either.

I agree that you need basic networking and protocol understanding etc still. And that being able to talk through problems conceptually is important.