←back to thread

38 points 3a2d29 | 1 comments | | HN request time: 0.253s | 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?

1. harrall ◴[] No.43358809[source]
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.