←back to thread

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

38 points 3a2d29 | 2 comments | 13 Mar 25 23:32 UTC | HN request time: 0.001s | source

I got a system design interview where I was asked to build a pricer for a financial product, then expand it to multiple pricers that might share inputs.

This was not the typical system design interview where you have to deal with APIs / load balancers / latency / etc

I have studied that a lot, but what about these type of general interviews?

Show context
flashgordon ◴[14 Mar 25 00:42 UTC] No.43358614[source]▶
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 designs for a good 5+ years until I had a ah-ha moment thanks to a couple of questions an Uber interviewer asked me (that interview sucked but I found my mojo after that). And back in that time I did not have the plethora of resources that are available now (not even mentioning GPT's ability to come up both problems and solution formats).

The key to these interviewers isnt just study but actually practicing mock problems. There are tons of those these days. Another way to learn is to - teach. Start writing up posts for each Design X kinda problem where you would lay it out as if you were presenting it in an interview, ie Requirements, Entities, APIs, High Level Design, Scalability Barriers, Deep Dives etc. Keep at it. A few failures isnt that bad.

replies(2): >>43359010 #>>43359116 #
1. geuis ◴[14 Mar 25 02:19 UTC] No.43359010[source]▶
Ok. What were the questions? What were your answers? What was the eureka moment?

Details are important.

replies(1): >>43359208 #
2. flashgordon ◴[14 Mar 25 03:00 UTC] No.43359208[source]▶
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.