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

Good system design

seangoedecke.com

Post reply on HN
Print view View original

201–210 of 400 posts

Re: Good system design

#201

Post by RaftPeople »

santiagobasulto wrote: post #170
alixanderwang wrote: post #131

> I’m often alone on this. Engineers look at complex systems with many interesting parts and think “wow, a lot of system design is happening here!” In fact, a complex system usually reflects an absence of good design. For any job-hunters, it's important you forget this during interviews. In the past I've made the mistake of trying to convey this in system design interviews. Some hypothetical startup app > Interviewer…

I’ve been in software for 20 years and it’s the first time I hear “back pressure”. Am I too old already?

> it’s the first time I hear “back pressure”. Am I too old already?

It's the opposite, as you get older you will feel this more and more.

Re: Good system design

#202

Post by ninetyninenine »

A lot of backend engineers are obsessed with infrastructure.

I've seen engineers have servers spin up lambdas to do async jobs that are just database calls.

So the server essentially waits for lambda which waits for a database. Why? Why can't you just have the server wait for the database?

It's like I'm going to pay a person to wait in line for me while I wait for him. Why? You're waiting anyway!? And you just paid to involve an additional person to unnecessarily wait with you for what?

When I told the engineer that you can just spin up a coroutine or like maybe you can allocate some cores before you spin up a new server... he looked at me like I was crazy. He said I was doing things so low level it was like assembly language programming. Going to low level and that lambdas were so cheap it was inconsequential.

If you're reading this and you're thinking, wow that other engineer is right, well this quote from the article refers to you:

"I’m often alone on this. Engineers look at complex systems with many interesting parts and think “wow, a lot of system design is happening here!” In fact, a complex system usually reflects an absence of good design."

Re: Good system design

#203

Post by dondraper36 »

nlawalker wrote: post #200
Swizec wrote: post #162

Earlier quoted context omitted.

> These are not the answers they're looking for. These ARE the answers we are looking for. As the system design interview (I’ve done hundreds) I want you to start with these answers then we can layer on complexity if you’ve solved the problem and there’s time left to go into navel gazing mode. Seeing the panic slowly build in mid-level engineers’ eyes as it dawns on them that not every problem can be solved by cachin…

> I want you to start with these answers then we can layer on complexity if you’ve solved the problem and there’s time left to go into navel gazing mode. Do you tell people this explicitly? If so, good on you; if not, please start! I think one of the biggest problems with interviews these days is misaligned expectations, particularly interviewees coming in assuming that what's desired is immediate evidence that they'…

I believe even at FAANG-like companies, only a lucky minority is involved at that level of scale. Most developers just use the available infrastructure and tools without working on the creation of S3 or BigTable.

Re: Good system design

#204

Post by Swizec »

nlawalker wrote: post #200
Swizec wrote: post #162

Earlier quoted context omitted.

> These are not the answers they're looking for. These ARE the answers we are looking for. As the system design interview (I’ve done hundreds) I want you to start with these answers then we can layer on complexity if you’ve solved the problem and there’s time left to go into navel gazing mode. Seeing the panic slowly build in mid-level engineers’ eyes as it dawns on them that not every problem can be solved by cachin…

> I want you to start with these answers then we can layer on complexity if you’ve solved the problem and there’s time left to go into navel gazing mode. Do you tell people this explicitly? If so, good on you; if not, please start! I think one of the biggest problems with interviews these days is misaligned expectations, particularly interviewees coming in assuming that what's desired is immediate evidence that they'…

> Do you tell people this explicitly?

Yes and no. I give them rough scale numbers to design for. Part of the interview is knowing why I’m telling you this.

Re: Good system design

#205

Post by ninetyninenine »

bbkane wrote: post #110
usernamed7 wrote: post #35

One thing i would add, is that a well designed system is often one that is optimized for change. It is rare that a service remains static and unchanging; browsers and libraries are regularly updated, after all. Thus if/when a developer takes on a feature ticket to add or change XYZ, it should be easy to reason about and have predictable side-effects of how that change will impact the system, and ideally be easy to ch…

"optimized for change" really only works well if you can predict the incoming changes. Common tools used for this "optimization" often raise the complexity and lower the performance of the system. For example, a db with a single table with just a key and a value is very flexible and "optimized for change" but it offers lower performance (in most cases) and is harder to reason about. I also frequently see people (me t…

>"optimized for change" really only works well if you can predict the incoming changes.

functional programming is the paradigm most optimized for modularity and therefore change. It's the best we have but it's limited in scope.

Re: Good system design

#206

Post by corytheboyd »

alixanderwang wrote: post #131

> I’m often alone on this. Engineers look at complex systems with many interesting parts and think “wow, a lot of system design is happening here!” In fact, a complex system usually reflects an absence of good design. For any job-hunters, it's important you forget this during interviews. In the past I've made the mistake of trying to convey this in system design interviews. Some hypothetical startup app > Interviewer…

As well as the “two-way street” point made in a sibling comment, I feel like a good interviewer would say “this is great, I would keep it simple too, but I am testing your knowledge of $thing right now.” If the person won’t stop talking about the wrong thing, that’s a bad sign of course.

Re: Good system design

#207

Post by chrisweekly »

anal_reactor wrote: post #111
nvarsj wrote: post #80

> Paradoxically, good design is self-effacing: bad design is often more impressive than good. Rings very true. Engineers are rated based on the "complexity" of the work they do. This system seems to encourage over-engineered solutions to all problems. I don't think there is enough appreciation for KISS - which I first learned about as an undergrad 20 years ago.

This is unfortunately true. People love complex solutions, and suggesting a simple one usually comes across as incompetent, while the reality is, simple solutions are easy to manage, which ensures the success of the project as a whole. Sure, there are problems that are inherently complex and require complex solutions. But most likely yours isn't one of them, most likely you have a basic web app.

One of the smartest engineers I've encountered in my 27 year career advised me to strive to do "the simplest thing that could possibly work" - not just to get unblocked on something new, but as a guiding principle. It resonated (and goes beyond "KISS", for me), and IME is real wisdom.

Re: Good system design

#208

Post by stavros »

dondraper36 wrote: post #184
UK-AL wrote: post #165

Earlier quoted context omitted.

These are the places that actually pay well.

There's another reason for that. Deep in my heart, I would love to be part of a team that works on truly data-intensive applications (as Martin Kleppmann would call them) where all the complexity is justified. For example, I am more of the "All you need is Postgres" kind of software engineer. But reading all those fancy blog posts on how some team at Discord works with 1 trillion messages with Cassandra and ScyllaDB…

I feel like the phrase "all you need is Postgres" has the (often unspoken) continuation of "until you actually get to a trillion messages".

In other words, the developers you're envious of didn't start with Cassandra and ScyllaDB, they started with the problem of too many messages. That's not an architectural choice, that's product success.

Re: Good system design

#209

Post by belinder »

atomicnumber3 wrote: post #185
_fat_santa wrote: post #169

Earlier quoted context omitted.

This goes back to "interviews go both ways". All those answers you gave are very reasonable and if I was your interviewer I'd pass you with flying colors. On the other hand if you're interviewing at a place that doesn't pass you with flying colors for those responses, that really says more about them than it does about you and may not be a great place to work. But to your point, many times one interviews for a job th…

If I was your interviewer, I would: respect your answers a lot, not be able to check off anything on my rubric, try to explain this in the debrief, get told we have to stick to the rubric to counter bias, and then watch while they pass on you for someone who decided to play architecture jenga instead. I would potentially even consider emailing you to apologize later, then not do it because I'd probably get in trouble…

Exactly, it would only work if you have enough sway with your boss and the willingness to take responsibility for the hire

Re: Good system design

#210

Post by jagged-chisel »

Lots of comments here decrying unnecessary complexity and the depressing reality of job interviews around the subject.

And I’m wondering why investors tolerate the expense: it’s surprising how much you can get done with simplicity and a small focused team.

It must be something about perception when they’re ready to sell the company.

Post reply on HN