I have used multiple of these in my career. I have implemented few of them. I never got asked about any of them in interviews.<p>I would not expect people to know or even be able to explain those by heart, either. You just don't use them or even think about them often enough to internalize them. Or any complex algorithm for the matter.<p>This kind of interview only tests how much a person has prepared for an interview, not how well they can apply this knowledge in real life, or think outside the box when required.
This is kind of crap listicle.<p>From the title to the content, it's just bad.<p>A system design interview doesn't ask you algorithms. They're basically block diagrams. They're often the interview with the highest variance, because a successful one requires the interviewer to ask not only a fair question (e.g. isn't niche to their current job), but also recognize when a solution works, but isn't their implementation. This doesn't require any knowledge about algorithms beyond what types of algorithms exist. That's pretty much it. It's also the hardest to prepare for, because you could be asked pretty much anything, and there aren't very many medium level design docs out there for complex internet scale systems.<p>Now an <i>algorithm</i> design or coding interview will ask you to develop an algorithm with level of implementation, but if you not memorizing an algorithm is going to sink you, then you have crappy interviewer and shouldn't take the job anyway. A good interviewer doesn't want you to simply come in and spout out memorized factoids, they want you to develop it. A good interviewer will recognize that you memorized the answer, and ask a different question until you don't know it. Only then, will the interview be useful.<p><i>Everyone</i> should get the solution by the end. It's just how many, and how explicit of hints you need.<p>The list of algorithms is a complete grab bag of random stuff. There's nothing tying them together.
It's worth noting that the source of this is a someone who is hawking a pricey "cracking the system design" type interview book. I feel like these types of posts are intended to create anxiety in the reader - "oh my god I had no idea what a quad tree even was?!" I think much of the cottage industry that has sprung up about "cracking interviews" is predicated on maintaining a constant state of anxiety as well. If you look at something like Leetcode it's the same thing, there's something like 2,000+ questions there. So many that you can never feel confident. The job of preparing is never done. As long as people have anxiety about everything they don't and can't have any sense of confidence, they will be inclined to fork over their money in an attempt to assuage that anxiety created by such material.
Having done several system design interviews, most of the time they're badly executed. When I asked for some detailed requirements they cannot disclosure them. However in the end they have those hidden requirements and I've failed because my system doesn't meet those requirements.<p>It's a bad way to conduct a system design interview by having a design in mind and hoping the candidates will reach that with limited knowledge / guidance.
First time I saw geohashing. Can't this result in some lopsided squares? The way it is described has a standard rectangle projection. But those are inaccurate due to the earth being spherical. So the areas on top and bottom will be much larger.<p>To be fair I've heard of most of these in my career but they are fairly specialized. If you are conducting a system design interview and expecting the candidate to know one of these I'd suspect there is a bit of bias there (unless that is their area of study).
I weirdly only found out about a few of these rate limiting algorithms yesterday when I was looking at rate limiting Elixir processes for a small load testing tool. Merkle Trees, bloom filters, and raft/paxos are prevalent in crypto so if you read those topics you'd know them. Hyperloglog is an HN favorite.<p>Failed an interview for a test infra engineer because I couldn't implement a trie from memory earlier in the year -.-'
I was expecting to see idempotent consumer, circuit breaker, and a few others that I’ve used frequently when designing systems. Maybe not interesting enough to make the list?
I feel that if more interviews involved this sort of algorithm instead of the ultra-niche / only situationally useful, there would be way less opposition and much more signal.<p>At work, I have written and then used a bunch of these in production, just for the narrow scope of things I work on. Might be indicative of me being in a bubble though.<p>Please, ask me to make a bloom filter or show how consistent hashing enables sharding! I'll pass on yet another "Implement String.reverse()"
I see "systems design" tossed around a lot these days, and the phrase is taking on multiple meanings. What's the context here for this use?
I want to see how many people can recite Paxos/RAFT or "Operational transformation" on a system design interview... If you meet such people, start throwing gold at them as you found unicorns!
Thank you so much for all the suggestions. I'll update the diagram in the next few days.<p>We plan to go through the whole list with video explanations. So far, we have done two:
Consistent hashing: <a href="https://www.youtube.com/watch?v=UF9Iqmg94tk" rel="nofollow">https://www.youtube.com/watch?v=UF9Iqmg94tk</a>
Geohash/Quadtree: <a href="https://www.youtube.com/watch?v=M4lR_Va97cQ" rel="nofollow">https://www.youtube.com/watch?v=M4lR_Va97cQ</a>
When I used hyperloglog, count min sketch in system design interviews, I usually ended up explaining the data-structure from scratch as the interviewer had no clue what it was
system design interviews are weird. the best systems are designed by doing as much research as possible on relevant systems, techniques and tools; then using experience/skill to separate the good from the bad to come up with a solid plan, not some stupid real-time whiteboard performance.<p>that said, this is a collection of nice solutions to interesting technical problems that have come up in practice over the last 15 years. :)
I would add CRDTs to your list. They are a tool that, when they're applicable, are almost magical.<p>Overview link: <a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type" rel="nofollow">https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...</a>