Hacker News Reader

Comment by bluetomcat | Hacker News Reader

Few people at software companies are designing systems from scratch nowadays. If they are, they'll be gluing together third-party middleware applications like database systems, queues, proxies, load balancers, etc.

A general understanding of computer architecture, programming language theory, networking and common protocols and formats is more valuable. At that fundamental level, they won't be using recent fancy buzzwords to sound cool, but could be using their brain to come up with something original.

View on HN

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.

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?

> database systems

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

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.

Reply on news.ycombinator.com