Live data from Hacker News

Algorithms you should know before you take system design interviews

blog.bytebytego.com

71–80 of 82 posts

Re: Algorithms you should know before you take system design interviews

#71

TIL that rsync is an algorithm, not just a program that makes it easy to sync content across hosts.

There is a paper called "The rsync algorithm" https://scholar.google.com/scholar?start=10&hl=en&as_sdt=0,5...

Just FYI ... Or just for trolling ;-)

Re: Algorithms you should know before you take system design interviews

#72

Earlier 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…

This sounds like a Software Architect role. Is that correct?

Re: Algorithms you should know before you take system design interviews

#73

Earlier quoted context omitted.

These are more "patterns" than "algorithms"...

Is there a place where you can see a list of system design patterns and their use cases?

The AWS builders library has quite a few good patterns / design principles

https://aws.amazon.com/builders-library/

Re: Algorithms you should know before you take system design interviews

#74
post #4

Earlier quoted context omitted.

Yeah I can look these up no problem but links to articles would have been rad.

Did you try scrolling down to the links?

ah yeah, the list is nice, would be better if I could click on the sheet though

Re: Algorithms you should know before you take system design interviews

#75
post #72

Earlier quoted context omitted.

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…

This sounds like a Software Architect role. Is that correct?

It can be used for a software architect role, but in general I'm just trying to poke at systems design ability regardless of the job level. Expectations are different for different job roles, obviously. If a software architect didn't do well on this question, for example, it would be very likely be a "no hire", but for a junior engineer their performance just needs to be appropriate for their level.

Re: Algorithms you should know before you take system design interviews

#76

Earlier quoted context omitted.

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…

I'll happily disclose anything if they ask about, but the goal I'm trying to get to is that you land at requirements through conversation. Starting with a blank slate and saying "Give me all the requirements" and expecting that list to be complete, accurate, and never change is, at best, a complete fantasy when dealing with actual customers. If you did that to an actual customer, half the time they would blankly stare back at you with no idea what to say.

Now, if that's the level they engage at, that might be ok for a junior role. I expect juniors to require projects to be spelled out in excruciating detail, and to not deviate from exactly what they were told to do. That's what, by definition makes them junior.

A senior engineer on the other hand, can generally be given vaguely defined tasks and has the initiative to figure out what actually needs to be built in the first place, before launching into building something.

I don't have a specific threshold of performance I'm expecting for passing or failing the interview. It's about gauging where a candidates skills are on a spectrum, and then seeing if that skill level lines up with their experience and the job level the are interviewing for.

If you have senior experience and are interviewing for a senior role, my expectations are higher. If you perform at a junior level, then either we'd offer you a junior role instead or not make an offer. If you have junior experience and do well, then it might be time to make the leap to a senior role, or we'd make you a very attractive junior offer because we see that you're likely to advance quickly.

Re: Algorithms you should know before you take system design interviews

#77

Earlier quoted context omitted.

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?

Combining characters are the most obvious problem.

Both of these are visually identical as "naïve", however the first is written with "ï" being a single code point, while the second is an "i" followed by a combining dieresis. In the first example, the dieresis correctly stays attached to the i, while in the second dieresis incorrectly moves to the v. To do it right, you have to scan through the string and keep the base character and all combining characters in order.

"na\u00efve".split("").reverse().join("") // CORRECT: "evïan" "ev\u00efan"

"nai\u0308ve".split("").reverse().join("") // INCORRECT: "ev̈ian". Should have been "evi\u0308an", not "ev\u0308ian".

Re: Algorithms you should know before you take system design interviews

#79
post #72

Earlier quoted context omitted.

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…

This sounds like a Software Architect role. Is that correct?

A software architect does system design, but lots of developers do system design without being architects.

Re: Algorithms you should know before you take system design interviews

#80

TIL that rsync is an algorithm, not just a program that makes it easy to sync content across hosts.

There is a paper called "The rsync algorithm" https://scholar.google.com/scholar?start=10&hl=en&as_sdt=0,5... Just FYI ... Or just for trolling ;-)

Was not trolling, thanks for sharing the paper.
Post reply on HN