System Design Misc Part 4

https://medium.freecodecamp.org/how-to-system-design-dda63ed27e26
This article is broken down into the following four sections:

Ask clarification questions
Use your background
Tackle a problem systematically
Keep your own notes

Ask clarification questions

A core aim of a systems design interview is to give the candidate an opportunity to demonstrate their knowledge.

There are no strictly right or wrong answers. A good system design question usually sounds very ambiguous, and the reason for that is it’s supposed to give you a chance to demonstrate the following:

How you would think about the problem space

How you think about bottlenecks

What you can do to remove these bottlenecks.

Imagine that you’re being asked to design a black box. How would you tackle the problem? There are no clear directions on what you need to build here, aside from the box being able to hold some items within it.

One of the most useful strategies I personally employ is to ask clarification questions. What are “good” clarification questions, you ask?

A good clarification question helps you achieve one, or more, of several things:

Helps you narrow the scope of what you’re supposed to do
Helps clarify what the user expectation of the system is
Gives you direction about where to proceed
Informs you of possible bottlenecks/problem areas
In the black box example, you might ask, “well, what does the box hold? How many items does it hold? And who is the intended user?”

To that I might say, let’s build a yellow box with a smiley on it that should hold at most 1 tennis ball. This is not an ordinary tennis ball, however. It will be at least 0.5m in radius and weighs about 1kg. It is meant to be hugged, not held, so I don’t want any handle on it.

There you go, this is the box.

Always ask clarification questions. You are not being judged on whether or not you asked a specific question during the interview, but you are judged on how you think about the problem space.

For example, if I were to ask you to design Twitter right now, how would you do it? Take a few minutes to think about it, and maybe even sketch it out on a piece of paper. 

If you haven’t realized it yet, the end result of the exercise above would yield significantly different results. For my own specific background, I might delve really deeply into API design and backend infrastructure. I’d probably explore iPhone-specific problems as well, due to my experience. I’ll talk about how the client interacts with the middle-tier endpoints, how logging would work, how I’d design the backend to ensure uptime, and so on.

Use your background to your advantage

Often times I see engineers trying to figure out what the interviewer is trying to ask, and then catering their responses to fit the expectations.

I actually highly discourage anyone from doing this for several reasons:

1. Everyone has a unique background. In a systems design interview, it’s an opportunity for you to demonstrate what your strengths are. Don’t waste the opporunity trying to figure out what someone else might expect of you.
2. The interviewer might have been nodding along to your answers, but they might’ve known that you’re just bluffing your way through and not actually thinking about the problem.

Your experience and background can vary widely from the next candidate. You bring a set of values and expertise to the table that no one else can. That is what makes you valuable and irreplaceable. Regardless of what field you’re in, people care about what you can bring to the table.

Tackle the problem systematically

Now, with my expertise in mind, there are several things that I think about when I’m tackling a new system. I highly recommend that you formulate a set of criteria or steps for yourself as well.

Some of the things in my mind when I work on a new system are:

• What is the goal of the system?
• Who are the users of the system?
• What is the scale we’re working with?
• Is this a new/old system? How do we handle versioning?

Among others…

See, my set of criteria will be different from a front-end engineer’s set of criteria. I use these criteria to formulate a picture in my head, and these will guide my decision-making process.

See, my set of criteria will be different from a front-end engineer’s set of criteria. I use these criteria to formulate a picture in my head, and these will guide my decision-making process.

My coffee-ordering service is a software as a service (SAAS). It offers an interface for various partners to plug into.

• It has an API, called addCoffeeForMerchant, that inserts coffee name, coffee price, and coffee ingredients.
• It has a GET API, called getCoffeesForMerchant, that returns a list of coffees for a given merchant ID.
• The merchant ID is a unique identifier (UUID) that is generated using some hashing mechanism, which can be further clarified with the customer.
• The software is optimized for read-only operations, because most of my customers create their menu once and read it multiple times throughout the day.
• It has a caching mechanism that uses Least-Recently-Used (LRU) eviction strategy, because if the menu item hasn’t been ordered in a while, my customer doesn’t care if it’s slightly slower in showing up on the menu.
• In case one of the data stores self-erupts, my coffee-ordering service will replicate data across different clusters across US west and US east coast because I am targeting the US market only for now.

Keep your own notes

As a software engineer, it’s a never-ending process of learning. I highly recommend that you use either Evernote or a Moleskin to keep notes. I personally carry a small notebook for quick ideas I need to jot down, and I keep various other things on Evernote whenever I can.

I break down my notes into:

1. Systems designs
2. Interviewing (experience + review of different interviews I’ve had in the past, grouped by company name)
3. Random tid-bits, CS good-to-know, like useful bash scripts or command-line tricks
4. Readings / YouTube videos