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

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.

This is big. Often will be on the senior plus rubric. "Did they ask clarifying questions?". Tick.

It also gives you constraints. Which are your friend.

I can't find it now (I tried but it was a year ago) but on YT there are some excellent example system designs where someone does it and then they talk about it. What was good. Why it was senior vs junior or senior vs principal.

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.

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.

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.

> 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?

System design has tonnes of YT videos. Watch them.

https://m.youtube.com/@SDFC

https://www.youtube.com/@jordanhasnolife5163

Pricer would have some kind of human interface. Even if just CLI that called API endpoint using some kind of SSO staff authentication. Then it is just a back end.

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...

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…

There are two aspects to systems design.

* Flow control - This is the logical path the software takes from input, through computation, to output.

* Division of effort - This isn’t your division of labor but the organization of parts to account for reuse, documentation, testing and so on.

With enough practice writing and refactoring original software you just build a vision for it through repeated practice. If that isn’t you then this job may not be a good fit for you.

Can this insight be applied to human resources or business organization?

Business organization is similar but people management is different. With people management you are attempting to ascertain their goals and constantly reading their communication to determine their motivation. As a leader it is up to you to set expectations and it is up to them to rise to those expectations. As for business organization the chief difference is with subordinate leaders, to put the right people in the right seats.

Maybe 'Design of computer programs'? https://www.udacity.com/course/design-of-computer-programs--...

Or study some of Peter Norvig's code for solving poker hands, sudoku etc.?

It's not obvious how to build abstractions at the right level, or to change those abstractions as requirements change.

It has been said that a system is not the sum of its parts, but the product of the interactions between its components. I hope someone can remind me who said this.

You might be thinking of Donella Meadows.

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.

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.

Most of the time the interviewer is determining how you think, whether they can interact with you easily, how you react to uncertainty, how you react to feedback, how you react to a superior saying “I don’t know”, your resilience in the face of incomplete information, your calmness under stress, and then finally, your final solution given the time constraints and pressure you are under.

The goal is not really to get an A+++ on the final product (although that’s nice) but the goal is to communicate that you work well under non-ideal conditions and you’re not a total F*ing nightmare. So take a big breath and engage that lovely neocortex and let your intellect be driven purely by curiosity, a desire to do good, and kindness, and you will get far.

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.