No Dijkstra?
or A*
Algorithms you should know before you take system design interviews
61–70 of 82 posts
Re: Algorithms you should know before you take system design interviews
#62Re: Algorithms you should know before you take system design interviews
#63It'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.
Re: Algorithms you should know before you take system design interviews
#64I 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. 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. Please, ask me to make a bloom filter or show how consistent hashing enable…
TBH reversing a string is probably harder than the others if you consider how strange unicode is.
How is string reversal is done with unicodes?
Re: Algorithms you should know before you take system design interviews
#65I 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.
Failed an interview for a test infra engineer because I couldn't implement a trie from memory earlier in the year -.-'
Re: Algorithms you should know before you take system design interviews
#66Earlier quoted context omitted.
It's for interviews that test your ability to design multi- computer program systems.
This has not been my experience, and I give "systems design" interviews. Generally the entire interview is, "Let's design an X", where X is some kind of system that has a substantial software component. The goal is to see how a candidate handles an open ended design problem of undefined size when we only have 45-60 minutes to discuss it. For example, do they expect to be handed requirements? Do they ask what the requ…
Well I don't know how you conduct the interview but in my experience from interviewee side, usually interviewer doesn't want to disclose information if it's not explicitly asked, which is bad. In your garage door example, it's better if you disclose the one button information when asked for "is there any more requirement?" or for any constraint, etc. If you only answer when asked "is it using one or two button" then it's a bad practice.
This practice makes those with only* a decent knowledge about the problem domain at disadvantage, because the interviewer doesn't disclose the requirement, even if asked (unless if asked specifically). In the junior case, it is possible that they know some garage door with two buttons, thus assuming the same since you don't disclose any information about it (assuming the junior asked). And thinking about it, one or two buttons operation should not be the top priority to be asked.
Re: Algorithms you should know before you take system design interviews
#67author wasted some stars, not an optimal algorithm :). He defined only 1, 3 and 5. he could simply used 3 stars
The difference between 1 star and 5 stars on a 5-star scale is greater than the difference between 1 and 3 on a 3-star scale
I doubt he surveyed and quantified the results to decide an algorithms importance is at 66.6666666667% instead of 60%
Re: Algorithms you should know before you take system design interviews
#68author wasted some stars, not an optimal algorithm :). He defined only 1, 3 and 5. he could simply used 3 stars
The difference between 1 star and 5 stars on a 5-star scale is greater than the difference between 1 and 3 on a 3-star scale
Only if you treat the number of stars as absolute values.
Re: Algorithms you should know before you take system design interviews
#69First 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. 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…
> So the areas on top and bottom will be much larger. Should be fine in practice, not much demand there.
I think the argument is that it wastes lots of code space on uninteresting parts of the world, and also has higher resolution there.
For the first, about ⅓ of the world’s population lives in 0110, and about 0 of it in 0000, 0010, 1000 and 1010, combined.
For the second, I would use an area-preserving projection of earth on a square.
Re: Algorithms you should know before you take system design interviews
#70If knowing these gets you the job and it can be crammed for, that's not an effective interview.
If the quantity and quality of knowledge is high enough, then “cramming” just means learning. This is how things should be.