Programmer: Lifelong Learning: August 2018

How to Land Your Dream Job Series

The Approach

It’s important to follow some systematic approach and drive/lead this conversation.
- SNAKE(Scenario, Needs, Application, Kilobyte(Data), Evolve)
- Requirements, constraints/estimates, high-level design, detailed design
- Talk about different approaches, pros and cons
It’s more important to follow the approach when you don’t have (much) clue or the interviewer wants to focus on specific domain or jump to detail too early.

System design interview is very important, as it’s usually conducted by managers or senior engineers who have more power to decide to hire or not, or the level.

Different from coding interview, how the system design interview goes varies a lot. Some companies(like Facebook) follow some good process, but others are not.

Depended on the interviewer, or what the candidate says, the system design interview may go wrong pretty soon.

1. Algorithm/Coding Question as a part of System Design

During the middle of the discussion, the interviewer may (unexpectedly) ask algorithm question.

Example: Autocomplete Service

As a system design question, the candidate may talk about: requirement
for a distributed prefix tree, how to shard data: consistent hash etc.
The interviewer may also ask and focus on how to Get top x word (ranked by frequency) from a single server trie: the algorithm question.
The candidate should be aware of the change, and approach it as an algorithm question and quickly give an optimal algorithm/pseudo code quickly.

2. The interviewer looking for specific direction/answer

Focus on detail too soon and too much

There are a lot of things the candidate can talk, but sometimes, the interviewer is looking for some specific direction/answer.
This is not good, as the system design is supposed to let the candidate lead the process, but you have to try your best when you are in this situation.

Example: One backend key value db server is slow, how to solve it?

The interviewer may jump to how to use cache, before you go that direction, make sure you also(still) talk about the scenario, outline other approaches first.

You may not have much time to go through those: you have to take and talk a lot about X when the interviewer is saying: let's go X approach, but still outline them in the whiteboard, at least you can resume those later.

Make sure ask these questions first
- does the backend provide client library?
- How many client apps? How easy to update them to new code/library?
- What’s the goal? How much effort? a short term fix to just make it work? or a long term invest
- What’s the team structure? Who is responsible to fix it (what team has the resource)? DB team or client team?
Potential solutions/discussion:
- local cache in client side or remote central cache
- request coalescing in client library
- distribute the db: shard the database and add a proxy layer which can distribute the request to the right shard
- Stability: rate limit, etc

What We Can Do?

Do Not Repeat Yourself

When asked the same questions after you already give (some) answer about it. Don’t just repeat your previous answer or try to expand it.
Usually, this means your answer is not what the interviewer is looking for at all.
Talk something meaningful and useful, that shows your skills.

Know/Guess what’s the interview is looking for

How vs Why and What

In system design, how to do it in detail is usually not important, instead focus on why and what info we are trying to get.

Between approach x and y, how you can determine which approach to take?
With the system is already running, how can you decide you should add local cache or centralized cache?
- THIS IS NOT IMPORTANT: ~~how to add the log, what to log and how to analyze log~~
- WHAT IS IMPORTANT: how to determine the cache performance: hit ratio.

Guide to Google Guice

Java subList Tips and Traps

When it Goes Wrong - How to Ace System Design Interview