Systems design questions are tricky. There are some key principles like how you handle scaling and how you estimate resourcing.
But it can really go awry. I've had this happen when asked to design something I have intimate knowledge of, more than my interviewer. I've had an interviewer ask what "reconiliation" meant when I brought it up in the context of a third-party payment system, for example.
Some basic advice: at least think about scaling and that really means horizontal scaling. I guess that raises the question of the difference between horizontal and vertical scaling. In case you don't know (or if anyone reading this doesn't) think of a server. Vertical scaling is buying an even beefier server. More CPUs, more storage, more RAM, that sort of thing. Horizontal servers is having more than one server and distributing the load somehow.
Horizontal scaling is what you want to concentrate on because it has a far higher upper bound on capacity than vertical scaling. So you want to think about how to distribute load. This gets into issues like sharding/partitioning, hashing, scattering, replication strategies and how to shrink or expand the pool.
Love this. What I like about system design is being aware of things like the 12-factor app but at the same time being aware of how much you can scale vertically before you need to scale horizontally, and avoiding any form of bikeshedding, premature scaling, and premature optimization.
Systems design questions are the only part of interviews that I actually like and find useful for evaluating actual knowledge - I mean, I think it’s harder to fake it than memorizing a bunch of problems and their solutions on Leetcode.
I have a better solution - ask a candidate to design a system that he helped design and present it. One of the places that I interviewed had me do it. Lot better than asking someone to design twitter or Netflix on the spot.
No. This gives a huge advantage to candidates that have been around something interesting or prepared a made up scenario in advance and are smooth talkers.
It's ok to ask basic details about previous projects but then change the requirements and ask the candidate to update the design on the spot multiple times.
I'd argue that if you can't tell the difference between a good system design and a bad system design other than "see if it works," you shouldn't be in a position to be giving system design interviews. The idea isn't to get a working system, it's to see how the candidate approaches a system design. If it's a problem you know how to solve and you can't see problems with their approach, they're probably at least as good at it as you are.
My experience is that you might be able to fake up to a certain point. After that, the interviewer can keep throwing curve balls and see how the candidate will approach those. Of course, it all depends on the problem given. I’ve seen system design questions that are way too abstract to be useful but the best ones I’ve been asked were very real life scenarios.
System design rounds are my favorite by far, on both sides of the interview.
If you're someone who likes browsing a lot of the engineering blog posts that come across HN, reddit, etc, there is a treasure trove of questions to be had.
Just look up a large company tech blog and read through one of their articles. Whether it's well written (you get to learn a lot from the trenches) or not (you have to think about the gaps that aren't explained) you win.
One thing I like to do is take a post-mortem or breakdown of a service (say messaging at slack, which has quite a few blogposts about it), read until they say "since we did not have X as a constraint", then mentally rewrite the rest of the article with that constraint put in.
One can usually find tons of these implicitly, or some explicitly stated.
Depending on the technology, you can also search specific forums to see other problems that things run into at scale. Which leads me to another fun source of system design problems:
* Find people talking about pushing the bounds of configuration values in production.
There are a _ton_ of config values in many pieces of software. Go check the software forums to see why the heck someone would be setting the value so high/low/strangely. An example of this are the elasticsearch or kafka forums. Find someone storing lots of very small things in elasticsearch and hitting scaling issues, or someone trying to maximize storing some very large things, and how they work around it.
Based on the title I expected a lot more specifics - the whole article is basically just "come up with a real world scenario where systems design might be new or challenging" and then ask that.
I came away with the same impression. The advice is good, but the answer to the title is still “you won’t find good questions, so go find inspiration for your own.”
I had the same "How to..." problem in the title, and actually collated a list of case study problems[1]. I have around 30+, some with a lot of technical detail aiming towards a solid solution.
And one of the worst interview questions is one that someone just pulled out of the air because it sounded challenging. Nothing worse than being in an interview and realizing the interviewer doesn't actually know what answers they're looking for.
The problem seems to be that "practice questions" imply having an accurate (if not completely formal) model of the world, and systems design is not enough of a science for that. Instead of a coherent model it's a disjoint collection of patterns, or perhaps many different coherent but small disciplines mushed together.
My problem with practice questions is they ignore practical realities. Instead of shrinking the problem they artificially shrink the solution space by telling you to ignore those problems (sometimes explicitly).
I wrote a practice design system with a test. It is called MTREES.io - Modular Transnational Robust Extreme Environment System. Its a funny not quite real but could be spec and story with lots of cool illustrations. Its free on Apple Books and Google Play. Just go to MTREES.io and play along!
I hope you take this in the spirit of helpfulness, but when I visit your site I have no idea at all what is going on. It's like timecube got a graphic designer. I'm sorry.
Seconding this, I got sensory overload lol. The screenshots are interesting but I'm lost if I should start clicking or if I should continue scrolling haha.
Thanks for the beta feedback. I dont get much time to work on it I have two developer jobs. I have a new version working on. Aware its hard to determine the "point". You are supposed to read the free ebook and then take the test.
Stoked to see hackpack on the front page of HN. Not affiliated with the company just a customer but they were critical part in my success prepping for technical interviews. Can't recommend them enough.
Great write up about a critical part of most interview processes without a chance to practice if you’ve never worked at an org that regularly implement complex systems.
But it can really go awry. I've had this happen when asked to design something I have intimate knowledge of, more than my interviewer. I've had an interviewer ask what "reconiliation" meant when I brought it up in the context of a third-party payment system, for example.
Some basic advice: at least think about scaling and that really means horizontal scaling. I guess that raises the question of the difference between horizontal and vertical scaling. In case you don't know (or if anyone reading this doesn't) think of a server. Vertical scaling is buying an even beefier server. More CPUs, more storage, more RAM, that sort of thing. Horizontal servers is having more than one server and distributing the load somehow.
Horizontal scaling is what you want to concentrate on because it has a far higher upper bound on capacity than vertical scaling. So you want to think about how to distribute load. This gets into issues like sharding/partitioning, hashing, scattering, replication strategies and how to shrink or expand the pool.
I hope that helps.