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

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?

APIs are just building blocks and blobs of single-ish responsibility. It's good to ask lots of different questions to understand the actual question being asked, what the desired capabilities of the thing being asked are, etc.

From there, you should be able to start laying out the different components and how they interact.

Edit: here's some areas of consideration when designing a system:

  * what does this thing do?
  * what are the expected inputs and outputs of the whole system?
  * what operations are we wanting to be able to perform against it?
  * how frequently will each of these operations be done?
  * how quickly do we want a response from this whole system?
  * what different sorts of integrations do we expect for this system? Any?
  * how often do we expect the system to change?
  * where do we expect to expand the system the most in the future? What will that look like?

I'm sure others will have many, many more things to add

IMO domain knowledge is crucial here. I don’t know anything about pricier or financial products so hard to reason about the system.

But to give a general advice, I’d approach it by trying to break down the domain into concepts, then think about how those concepts can be turned into abstractions. Then you can think about relationships between those abstractions and engineering solutions for those relationships.

Also, systems all take inputs and produce outputs. Validating those would be another interesting aspect given its finances related.

One general tip is to always ask (credible) clarifying questions. A lot of interviewers look out for this - they want to see you dissect the requirements a little bit, not just jump straight to solving the problem based on a bunch of assumptions you've made that might not be correct.

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.