Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LeetCode for System Design

leetsys.dev

Post reply on HN
Print view View original

21–30 of 56 posts

Re: LeetCode for System Design

#21

Post by weq »

ddimitrov wrote: post #6
motorest wrote: post #4

Earlier quoted context omitted.

> In theory, this should be the easiest discussion to pass while interviewing if you've done some kind of related work or qualified. Instead it's just turning into another insane cargo culted game where you need to do things according to some weird rules and hit certain buzzwords. Your comment reads as if you think system design interviews are good if you can pass them but they are bad if you fail them.

I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store. They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram. I'm sure they hire…

Regurgitation what amounts to ai slop these days paints a clear picture of your Company to the market. Companies that use l33tcode are filtering out pools of talent, in exchange for monocultures of echo chambers. Makes it easier swing the layoff ax when they need to posture to the market differently.

The fact that this ^^^ is run by AI shows just how irrelevant technical interviews like this are these days. Why take a closed book test for a job that you never have to work a day in your life with the book closed?

If you are an experienced dev, u can rank other devs pretty quickly with a general conversation about any technology.

Re: LeetCode for System Design

#23

Post by markerz »

raincole wrote: post #20
nelsonfigueroa wrote: post #15

I have a lot of feedback. No links to the Terms of Service and Privacy Policy. No way to preview without signing in. Only way to sign in is with Google. "Trusted by engineers landing jobs at" ...given how new this is, is this line marketing fluff or is there evidence that engineers actually trust LeetSys? Finally, I'm worried that this will make system design interviews as miserable as coding interviews.

> "Trusted by engineers landing jobs at" Semi off topic, but is it really legal to put Google/Netflix/etc's logos on their website like that?

Probably a trademark violation to use their logos or branding for marketing purposes.

Re: LeetCode for System Design

#25

Post by vincnetas »

motorest wrote: post #13
clippy99 wrote: post #5

Earlier quoted context omitted.

What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion.

> What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion. I think you're trying to rarionalize away the fact that system design involves knowing patterns and how to apply them. In each and every single technical field, it's good to be able to improvise but it's even better to know…

I think OP is concerned about hiring person who read lots of wikipedia about all types of engines and a person who actually designed and built a simple engine himself.

First person can check lots of boxes in interview but could struggle when rubber would meet the road. Second one might look bad, but he can always check wikipedia when needed. (replace wikipedia with AI if needed)

Re: LeetCode for System Design

#26

Post by rbajp »

nelsonfigueroa wrote: post #15

I have a lot of feedback. No links to the Terms of Service and Privacy Policy. No way to preview without signing in. Only way to sign in is with Google. "Trusted by engineers landing jobs at" ...given how new this is, is this line marketing fluff or is there evidence that engineers actually trust LeetSys? Finally, I'm worried that this will make system design interviews as miserable as coding interviews.

Thanks for taking a look! I initially built this tool for myself and my friends to help us prep, and they're the ones who encouraged me to release it publicly. Good catch on those issues – will get those fixed soon.

The goal is absolutely the opposite of making system design interviews more miserable. Right now, preparing for these interviews is really gatekept – either you need friends in big tech willing to help you practice, or you have to pay hundreds of dollars for one-on-one sessions.

We're trying to change that, now that its possible with AI.

Re: LeetCode for System Design

#27

Post by sunrunner »

motorest wrote: post #13
clippy99 wrote: post #5

Earlier quoted context omitted.

What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion.

> What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion. I think you're trying to rarionalize away the fact that system design involves knowing patterns and how to apply them. In each and every single technical field, it's good to be able to improvise but it's even better to know…

> know what you are doing

Is blindly copying the same diagrams seen in various GOTO conference slides and ByteByteGo system design newsletters to make sure all the expected parts of your 'architecture' are there really knowing what you are doing, or is it just cargo culting at the level of system design?

I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but drawing out the same system diagram as Netflix without actually having measured a real system to understand where the hotspots are is ultimately just guessing, at best following a known pattern without evidence it's required.

Plus if the question is being asked by a company that genuinely could survive on HAProxy and a couple of efficient load-balanced monoliths then it really is cargo culting, especially if you end up with something more complicated then actually required.

Re: LeetCode for System Design

#28

Post by danpalmer »

ddimitrov wrote: post #6
motorest wrote: post #4

Earlier quoted context omitted.

> In theory, this should be the easiest discussion to pass while interviewing if you've done some kind of related work or qualified. Instead it's just turning into another insane cargo culted game where you need to do things according to some weird rules and hit certain buzzwords. Your comment reads as if you think system design interviews are good if you can pass them but they are bad if you fail them.

I've failed system design interview where they repeatedly asked me to design "for scale" but all the volume and latency requirements I could get from them could be handled by a single HA pair running a monolithic server+ external managed data store. They also seemed annoyed that I am asking them questions that are not part of the problem statement instead of getting down to drawing a fancy diagram. I'm sure they hire…

Latency and volume aren't the only requirements, perhaps you failed to discover the other requirements of the system?

- In a fast system most of the latency will come from geographical distance, an HA pair can't serve the whole world with low latency.

- How do you handle new releases? You can do HA with 2 machines, or you can do safe rollouts with blue/green machines, but you can't do HA and safe rollouts with just 2 machines.

- What if you want to test a new release with 1% of traffic? 100 small machines might be preferable to 1 big machine, or 10 medium machines each running 10 instances, or whatever.

- What does the failover look like?

- You use an "external managed data store", but often the tricky bit is the data store. Externalising this may be the most practical option, but it doesn't communicate that you know how it needs to function.

Alternatively this might have just been a bad interview. Many are.

Re: LeetCode for System Design

#30

Post by motorest »

sunrunner wrote: post #27
motorest wrote: post #13

Earlier quoted context omitted.

> What the poster is insinuating is that system design interviews may devolve into a scripted / memorized hoop-jumping experience rather than being a creative technical problem solving discussion. I think you're trying to rarionalize away the fact that system design involves knowing patterns and how to apply them. In each and every single technical field, it's good to be able to improvise but it's even better to know…

> know what you are doing Is blindly copying the same diagrams seen in various GOTO conference slides and ByteByteGo system design newsletters to make sure all the expected parts of your 'architecture' are there really knowing what you are doing, or is it just cargo culting at the level of system design? I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but dr…

> Is blindly copying the same diagrams (...)

Do you see any evidence that candidates are blindly copying stuff around?

Also, you fail to offer any explanation on why studying systems design topics is supposedly inferior to not studying and just expecting to wing it at job interviews. You only assert that hypothetical candidates indeed have a broader technical background than you, but their knowledge and expertise are useless when compared to your uneducated improvisation skills.

Explain why you expect it to make sense?

> I think the answer lies somewhere in the middle. I don't disagree that you should be aware of these things, but drawing out the same system diagram as Netflix without actually having measured a real system to understand where the hotspots are is ultimately just guessing, at best following a known pattern without evidence it's required.

Why do you believe this hypothetical scenario is a concern? I mean, either this approach is useless and candidates have no advantage in following it, or this approach is enough to get candidates to outperform you at job interviews. In both scenarios, why do you think that others regurgitating information is a problem?

Post reply on HN