Live data from Hacker News

Ask HN: How to study for system design that doesn't include front end/back end?

news.ycombinator.com

11–20 of 27 posts

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#11
System design is about connecting together black boxes that meet requirements. A black box is something with a certain defined behavior but you don’t necessarily care how it works.

Imagine if you got tasked with building an airport but you’ve never built an airport. Well, you’d have to first clarify requirements: What kind of planes? What’s on these planes? What kind of cargo? How many flights per year?

As you learn more about requirements, you need to start solving them, but remember to keep it at a black box level. Let’s say your airport will be moving both cargo. How will cargo come in? How will cargo get out? We probably need a “cargo movement sub-system.” A cargo conveyor sub-system is still a black box — you don’t yet know details but you do know, at this very early point in questioning, that you need “a system that moves cargo between the loading bays and the plane.” You don’t even know if it’s going to be a conveyor system or humans manually driving cargo yet. However, you are well on your way to building an airport system.

You keep at this and keep delving down deeper until you go from design to implementation. This is the process of how you build anything in any field.

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#12

Depends on how to study. Ive been working on this for years. Many people just jump into a solution (or what they think is a solution) to the problem (or what they think is the problem). And this usually triggers interviewers who are looking for that gotcha moment. So you have to treat it as a careful game of getting requirements, setting expectations, managing time, communicating and more. Source - I sucked at system…

Ok. What were the questions? What were your answers? What was the eureka moment?

Details are important.

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#13
post #8
post #6

When you get a question like this, you just reduce everything down to database design. Most systems are just wrappers around a database. You can tell because if you take away the database the system does nothing useful. Financial products are exclusively priced in databases.

I did this in an interview once, failed miserably and got the feedback, “we don’t care about the database.” I personally feel you aren’t wrong but you also aren’t aligned with what they’re looking for, like I wasn’t when I failed this interview.

You dodged a bullet.

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#15

Depends on how to study. Ive been working on this for years. Many people just jump into a solution (or what they think is a solution) to the problem (or what they think is the problem). And this usually triggers interviewers who are looking for that gotcha moment. So you have to treat it as a careful game of getting requirements, setting expectations, managing time, communicating and more. Source - I sucked at system…

> The key to these interviewers isnt just study but actually practicing mock problems. There are tons of those these days.

Do you happen to have any good sources or lists or anything?

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#16
Based on description I read this more like a framework rather than system design. Are the different pricers for the same product? Is there a dependency graph between pricers and/or their components (e.g. a MC simulation as input, an intermediate model for calibration, a database query for rates)? Is this an ad-hoc pricer? What is the use (e.g. for risk you might run the same across thousands scenarios etc.) This would not classify as general interview to me. To have an interesting discussion you need subject matter expertise, otherwise you merely define a function signature…

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#17
post #12

Depends on how to study. Ive been working on this for years. Many people just jump into a solution (or what they think is a solution) to the problem (or what they think is the problem). And this usually triggers interviewers who are looking for that gotcha moment. So you have to treat it as a careful game of getting requirements, setting expectations, managing time, communicating and more. Source - I sucked at system…

Ok. What were the questions? What were your answers? What was the eureka moment? Details are important.

Great point. I'm actually writing and putting things up in a blog. ETA end of april. If you are ok for rough notes happy to share high level notes over email (no I'm not planning on selling anything and frankly I didnt find any value in the paid platforms which were just doing an upsell).

For a very big tldr, Raghu Ramakrishnans Database book and designing data intensive applications by klepman were was amazing but they need a bit of time investment.

Raghus book especially on indexes was very useful. Not so much to understand how databases but specifically how indexes work and taking a quantitative approach to know which index works for what kind of use case. So in the Uber interview as I was rambling about key value stores and caches the interviewer decided to put me out of my misery with "enough of all that, what would the first failing request's latency be". that got me thinking about how to reason about slos and latencies in a design. And then seeing which index types gave what kind of perf characteristics and so on.

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#18
post #4

That’s back end no? unless you have to make a GUI for it, then it’s front- and backend.

The difference is if you are asked about the 5 (or however you slice it) layers vs just 1 or 2 it leads to two kinds different kinds of discussions. The latter gets very specific.

Re: Ask HN: How to study for system design that doesn't include front end/back end?

#19
I learned a lot about event-driven distributed systems by just building things with ZeroMQ. Even if you don't end up using it, learning its messaging patterns and the decisions behind them can give you a pretty solid mental framework.

The ZeroMQ guide really takes you through it in detail, for example check out Figure 19 here for a parallel job queue with cancellation: https://zguide.zeromq.org/docs/chapter2/#Handling-Errors-and...

Post reply on HN