http://blog.gainlo.co/index.php/2017/03/24/chapter-5-system-design-interviews-part-complete-guide-google-interview-preparation/
That’s also the reason I never worry about if the interviewee has seen the question before. Let’s take the question “Design a web crawler” as an example. As an interviewer, I can make the interview focused on the overall crawler infrastructure, I can discuss how to dedup URLs in detail, and I can also ask how to detect if a page has been updated.
First and foremost, I’ll evaluate if the design actually works. Although there’s no implementation to verify that, based on work experience and some common sense, I would ask myself if I would try the proposed approach if given this problem. More often than not, it’s quite obvious to tell if the design is problematic and I’ll just use some examples to challenge the candidate. For example, if I ask him to check if an URL has been crawled before, I’ll see if the solution handles short URL like t.co/xyz or URLs with UTM params. This is the bare minimum requirement. If the candidate can’t make it work, I won’t go deeper or I may switch to a separate question.
Secondly, I would check feasibility. Some candidates will come up with solutions that only work in theory. It may require infinite memory or the system is unnecessarily complicated. In either case, I will ask him to fix it. A good way to verify this is to ask yourself how much time and how many engineers do you need to implement this design. Personally, I prefer designs with ease and simplicity. If you can’t make a prototype within one or two weeks, I might ask you to simplify it.
Thirdly, I expect the candidate to be clear about what he’s talking about. More specifically, I want to make sure that he’s aware of why the system should be designed in a specific way, what the constraints are, and whether there’re any other solutions. Usually, the design questions are vaguely described. Good candidates are able to tell you what assumptions are made and how this design is compared to others. To make it even clearer, ask yourself what are alternative solutions and why you make the system in this way instead of others.
The reason I think this is important is that you won’t know if your design would work without actually working on it. With some hands-on experience, you’ll soon realize that a lot of things are really hard to implement but seem reasonable at first glance. For example, if you want to check if a page’s content has been updated since the last time you crawled and rely on if the HTML content remains the same, you’ll notice that many pages have the same content but things like comments, sidebars have been changed. This is a design I don’t think it works, although it may sound reasonable.
Curiosity
It’s important to be generally curious about everything. One great practice is to pick whatever product you are using every day like Youtube and think about how would you design the system from scratch.
Sometimes the product can be really complicated, you can also just design one of its features like Facebook friends recommendation. If you have time, writing some code to implement a prototype would be a plus. But the point is that you should try to get down to the detail.
Although system design questions don’t have any standard answers, you can still search for how these products/features are implemented. Compare it with your own designs and understand the difference.
High Scalability is highly recommended, but don’t spend too much time on the particular tools (see the point “What’s Not Important”).
NOTE: One trick is that a lot of interviewers like to ask design questions that are related to the company. For instance, you are more likely to design a Google product/feature in Google interviews. It’s not always the case, but it doesn’t hurt to pay a little more attention to products of this company or similar products.
What’s not important
One common mistake is that many people pay too much attention to particular technique. For instance, they have spent a lot of time on how to use AWS, how to config Google cloud platform and how to use a specific web framework.
I’m not saying these are not useful, in fact, these are definitely good things to learn. However, from system design interview’s perspective, I would say interviewers care more about the understanding of knowledge than particular technique.
For example, when discussing processing large data, as an interviewer, what I would like to discuss is about how to distribute the data to multiple machines, how to aggregate them together later and how to equally distribute the load. If someone just tells me that he’ll use Hadoop on AWS, I’ll ask for more details and he would still end up answering all questions above.
The rule of thumb is to focus more on how each tool is designed than what tool to use.
http://blog.gainlo.co/index.php/2017/04/13/system-design-interviews-part-ii-complete-guide-google-interview-preparation/
Simple, High-level solution
Systems that are simple, straightforward and efficient really win.
Some people really want to show off that he can design something complicated and would just start with an overly complicated system. This is the completely wrong mindset.
What interviewer cares is not what cool technology you’re using, but whether you can design a system that works. I’ve seen so many candidates that kept saying all kinds of buzzwords without thinking about the question for seconds. You know what, I think those buzzwords are just bullshit and please forget about it in interviews.
The recommended approach is to start with something as simple as possible and try to design a high-level solution. If you are asked to design Google autocompletion system, you can just start from suggesting the most common queries with the given prefix so that all you need is a log processor and a suggest server.
Of course, the solution won’t work in many cases like sometimes we need personalization and the data may exceed memory limit. Then we can prioritize the problems and address one by one. Never shoot yourself in the foot by over-complicating the problem.
Don’t Rush
A common pitfall in coding interviews is to start coding without much consideration and discussion. The same problem happens in system design interview as well.
Remember that no one would expect you to come up with a design within seconds. See the whole interview process as a discussion rather than an exam. If it’s a discussion, you are encouraged to think loudly. You don’t need to point out a solution quickly, but you can talk about how you think about the problem, what you are trying to solve at the moment and what you are stuck with.
As an interviewer, candidates that I would give strong hire usually make the whole interview process very comfortable. It’s completely a discussion process and it’s like we are working on the problem together. They won’t pretend to know everything. Instead, they will always tell me what they are stuck with and how they are approaching the problem.
Trade-offs
Remember that your solution highly relies on the restriction, which can be both explicit and implicit. Explicit restrictions are ones set by the interviewer like you have only one machine. However, most people don’t pay attention to implicit restrictions.
A lot of times we are just making assumptions without knowing. Uncovering those hidden assumptions can help you better understand your solution. For example, time and space trade-off is a common theme in design problem. At some point, it’s okay to be a little bit slow but you can save a lot of memory. If you have a clear reason that speed is not important in particular circumstances, your design is reasonable.
A good practice is to think about what alternative approaches are and why the approach you picked is better. Usually, the reason it’s better is due to some constraints and assumptions. So it’s important to validate those assumptions. Changing your mind during the interview is completely okay. In fact, it’s a good sign that you are considering all scenarios.
Numbers
In other words, sometimes whether to scale or not is not told by the interviewer. You can get the answer by making reasonable assumptions and do the calculation.
This is a very important point because in real projects, good engineers are making a lot of decisions in this way. And this certainly needs some practices.
“There are some libraries out there”
One common pitfall is that many candidates like to tell me “there are some libraries to do this out there” as an excuse to not design this function in detail.
Do interviewers know there are existing libraries? Of course. But there are many reasons why it makes sense to ask candidates to design particular functions as well:
- Existing libraries might not do a good job. For example, a lot of libraries are able to extract date information from web pages, but none of them does it perfectly. In fact, just this feature itself can be a big team in many companies.
- There might be better solutions given the particular problem with constraints.
- In the end, there are existing systems for every design questions but it still makes sense to discuss the problem.
However, I’m not suggesting that you should never use any existing tools in system design interviews. What the design question is focused on matters. If it’s a common tool or something trivial comparing to the overall question, it’s completely fine to use existing tools.
https://hackernoon.com/anatomy-of-a-system-design-interview-4cb57d75a53f
- How to approach a problem in a systematic way to maximize your chances of success?
System Design interviews are less about getting lucky and more about actually doing the hard work of attaining knowledge. At the end, your performance in these interviews depends on the following 2 factors.
- Your knowledge — gained either through studying or practical experience.
- Your ability to articulate your thoughts.
When companies ask design questions, they want to evaluate your design skills and experience in designing large scale distributed systems
7 steps to approach a System Design Interview
Step 1: Requirement Gathering:
Many candidates think that system design interviews are all about “scale”, forgetting to put required emphasis on the “system” part of the interview.
You need to have a working “system” before you can scale it.
As the first step in your interview, you should ask questions to find the exact scope of the problem. Design questions are mostly open-ended, and they don’t have ONE correct answer. That’s why clarifying ambiguities early in the interview becomes critical. Candidates who spend time in clearly defining the end goals of the system, always have a better chance of success.
Here are some questions for designing Twitter that should be answered before moving on to next steps:
- Who can post a tweet? (answer: any user)
- Who can read the tweet? (answer: any user — as all tweets are public)
- Will a tweet contain photos or videos (answer: for now, just photos)
- Can a user follow another user? (answer: yes).
- Can a user ‘like’ a tweet? (answer: yes).
- What gets included in the user feed (answer: tweets from everyone whom you are following).
- Is feed a list of tweets in chronological order? (answer: for now, yes).
- Can a user search for tweets (answer: yes).
- Are we designing the client/server interaction or backend architecture or both (answer: we want to understand the interaction between client/server but we will focus on how to scale the backend).
- How many total users are there (answer: we expect to reach 200 Million users in the first year).
- How many daily active users are there (100 million users sign-in everyday)
It’s a hypothetical problem geared towards evaluating your approach. You are just asking these questions to scope the problem that you are going to solve today. e.g. you now don’t have to worry about handling videos or generating a timeline using algorithms etc.
Step 2: System interface definition
If you have gathered the requirements and can identify the APIs exposed by the system, you are 50% done.
Define what APIs are expected from the system. This would not only establish the exact contract expected from the system but would also ensure if you haven’t gotten any requirements wrong. Some examples for our Twitter-like service would be:
postTweet(user_id, tweet_text, image_url, user_location, timestamp, …) generateTimeline(user_id, current_time) recordUserTweetLike(user_id, tweet_id, timestamp, …)
Step 3: Back-of-the-envelope capacity estimation
It’s always a good idea to estimate the scale of the system you’re going to design. This would also help later when you’ll be focusing on scaling, partitioning, load balancing and caching.
- What scale is expected from the system (e.g., number of new tweets, number of tweet views, how many timeline generations per sec., etc.)
- How much storage would we need? This will depend on whether users can upload photos and videos in their tweets?
- What network bandwidth usage are we expecting? This would be crucial in deciding how would we manage traffic and balance load between servers.
Step 2: System interface definition
If you have gathered the requirements and can identify the APIs exposed by the system, you are 50% done.
Define what APIs are expected from the system. This would not only establish the exact contract expected from the system but would also ensure if you haven’t gotten any requirements wrong. Some examples for our Twitter-like service would be:
postTweet(user_id, tweet_text, image_url, user_location, timestamp, …) generateTimeline(user_id, current_time) recordUserTweetLike(user_id, tweet_id, timestamp, …)
Step 3: Back-of-the-envelope capacity estimation
It’s always a good idea to estimate the scale of the system you’re going to design. This would also help later when you’ll be focusing on scaling, partitioning, load balancing and caching.
- What scale is expected from the system (e.g., number of new tweets, number of tweet views, how many timeline generations per sec., etc.)
- How much storage would we need? This will depend on whether users can upload photos and videos in their tweets?
- What network bandwidth usage are we expecting? This would be crucial in deciding how would we manage traffic and balance load between servers.
Step 4: Defining the data model
Defining the data model early will clarify how data will flow among different components of the system. Later, it will guide you towards better data partitioning and management. Candidate should be able to identify various entities of the system, how they will interact with each other and different aspect of data management like storage, transfer, encryption, etc. Here are some entities for our Twitter-like service:
User: UserID, Name, Email, DoB, CreationData, LastLogin, etc.
Tweet: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp, etc.
UserFollows: UserdID1, UserID2
FavoriteTweets: UserID, TweetID, TimeStamp
Which database system should we use? Would NoSQL like Cassandra best fits our needs, or we should use MySQL-like solution. What kind of blob storage should we use to store photos and videos?
Step 5: High-level design
Draw a block diagram with 5–6 boxes representing core components of your system. You should identify enough components that are needed to solve the actual problem from end-to-end.
For Twitter, at a high level, we would need multiple application servers to serve all the read/write requests with load balancers in front of them for traffic distributions. If we’re assuming that we’ll have a lot more read traffic (as compared to write), we can decide to have separate servers for handling reads v.s writes. On the backend, we need an efficient database that can store all the tweets and can support a huge number of reads. We would also need a distributed file storage system for storing photos (and videos) and a search index and infrastructure to enable searching of tweets.
Step 6: Detailed design for selected components
Dig deeper into 2–3 components; interviewers feedback should always guide you towards which parts of the system she wants you to explain further. You should be able to provide different approaches, their pros and cons, and why would you choose one? Remember there is no single answer, the only thing important is to consider tradeoffs between different options while keeping system constraints in mind. e.g.
- Since we’ll be storing a huge amount of data, how should we partition our data to distribute it to multiple databases? Should we try to store all the data of a user on the same database? What issues can it cause?
- How would we handle high-traffic users e.g. celebrities who have millions of followers?
- Since user’s timeline will contain most recent (and relevant) tweets, should we try to store our data in a way that is optimized to scan latest tweets?
- How much and at which layer should we introduce cache to speed things up?
- What components need better load balancing?
Step 7: Identifying and resolving bottlenecks
Try to discuss as many bottlenecks as possible and different approaches to mitigate them.
- Is there any single point of failure in our system? What are we doing to mitigate it?
- Do we’ve enough replicas of the data so that if we lose a few servers, we can still serve our users?
- Similarly, do we’ve enough copies of different services running, such that a few failures will not cause total system shutdown?
- How are we monitoring the performance of our service? Do we get alerts whenever critical components fail or their performance degrades?
https://hackernoon.com/how-not-to-design-netflix-in-your-45-minute-system-design-interview-64953391a054
The key here is to understand what your interviewer is looking for. He wants you to give him a 50,000 ft overview, identify high-level components and describe the interactions between components as succinctly as possible. Here are 3 phases of such a discussion.
- Draw a big box that represents the system.
- Zoom-in and break that big box into 5–6 components.
- Briefly discuss the role of each component e.g. compute, storage, front-end, back-end, caching, queueing, networking, load-balancing, etc.
Your interviewer would want you to discuss 1–2 components in more depth and he is going to specify which one. You are rarely expected to write any code during these discussions.
Only use buzzwords and in-fashion technologies e.g. “GraphQL” if you understand them well and can justify and defend your approach.
- He has probably asked this question a 1000 times and is well versed in the possible solutions. He’ll quickly find out how much you actually understand.
Rule 2: Never pretend to be an expert. The person interviewing you almost always understands the domain better than you and can even be an industry expert.
This is really my domain. I’ll be done in 15 minutes
Good for you but slow down. Instead of jumping to the solution that you already know, do the following:
- Gather requirements.
- Ask Questions. Your interviewer is interested in understanding your thought processes.
- Evaluate multiple solutions, discuss pros and cons and see where the discussion takes you.
In reality, it is a good idea to do this whether you know about the domain or not.
Rule 3: Don’t rush to a solution. Gather requirements, suggest multiple solutions and evaluate them. It is meant to be an open-ended discussion.
How to Ace a Systems Design Interview | Palantir
WE’RE MEASURING THREE THINGS
Nominally, this interview appears to require knowledge of systems and a knack for design—and it does. What makes it interesting, though, and sets it apart from a coding or an algorithms interview, is that whatever solution you come up with during the interview is just a side effect. What we actually care about is the process.
In other words, the systems design interview is all about communication.
Do you know the constraints? What kind of inputs does your system need to handle? You have to get a sense for the scope of the problem before you start exploring the space of possible solutions. And remember, there is no single right answer to a real-world problem. Everything is a tradeoff.
- Concurrency. Do you understand threads, deadlock, and starvation? Do you know how to parallelize algorithms? Do you understand consistency and coherence?
- Networking. Do you roughly understand IPC and TCP/IP? Do you know the difference between throughput and latency, and when each is the relevant factor?
- Abstraction. You should understand the systems you’re building upon. Do you know roughly how an OS, file system, and database work? Do you know about the various levels of caching in a modern OS?
- Real-World Performance. You should be familiar with the speed of everything your computer can do, including the relative performance of RAM, disk, SSD and your network.
- Estimation. Estimation, especially in the form of a back-of-the-envelope calculation, is important because it helps you narrow down the list of possible solutions to only the ones that are feasible. Then you have only a few prototypes or micro-benchmarks to write.
- Availability and Reliability. Are you thinking about how things can fail, especially in a distributed environment? Do know how to design a system to cope with network failures? Do you understand durability?
How do you get better at something? If your answer isn’t along the lines of “practice” or “hard work,” then I have a bridge to sell you. Just like you have to write a lot of code to get better at coding and do a lot of drills to get really good at basketball, you’ll need practice to get better at design. Here are some activities that can help:
- Do mock design sessions. Grab an empty room and a fellow engineer, and ask her to give you a design problem, preferably related to something she’s worked on. Don’t think of it as an interview—just try to come up with the best solution you can. Design interviews are similar to actual design sessions, so getting better at one will make you better at the other.
- Work on an actual system.
- Contribute to OSS or build something with a friend. Treat your class projects as more than just academic exercises—actually focus on the architecture and the tradeoffs behind each decision. As with most things, the best way to learn is by doing.
- Do back-of-the-envelope calculations for something you’re building
- and then write micro-benchmarks to verify them. If your micro-benchmarks don’t match your back-of-the-envelope numbers, some part of your mental model will have to give, and you’ll learn something in the process.
- Dig into the performance characteristics of an open source system. For example, take a look at LevelDB. It’s new and clean and small and well-documented. Read about the implementation to understand how it stores its data on disk and how it compacts the data into levels. Ask yourself questions about tradeoffs: which kinds of data and sizes are optimal, and which degrade read/write performance? (Hint: think about random vs. sequential writes.)
- Learn how databases and operating systems work under the hood.
- These technologies are not only tools in your belt, but also a great source of design inspiration. If you can think like a DB or an OS and understand how each solves the problems it was designed to solve, you’ll be able to apply that mindset to other systems.
The systems design interview can be difficult, but it’s also a place to be creative and to take joy in the imagining of systems unbuilt. If you listen carefully, make sure you fully understand the problem, and then take a clear, straightforward approach to communicating your ideas, you should do fine.
https://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/
Jeff Dean makes similar points in his
LADIS 2009 keynote (which I unfortunately wasn’t able to attend). In particular, he gives a useful table of “Numbers Everyone Should Know” — that is, the cost of some fundamental operations:
| Operation | Time (nsec) |
| L1 cache reference | 0.5 |
| Branch mispredict | 5 |
| L2 cache reference | 7 |
| Mutex lock/unlock | 25 |
| Main memory reference | 100 |
| Compress 1KB bytes with Zippy | 3,000 |
| Send 2K bytes over 1 Gbps network | 20,000 |
| Read 1MB sequentially from memory | 250,000 |
| Roundtrip within same datacenter | 500,000 |
| Disk seek | 10,000,000 |
| Read 1MB sequentially from disk | 20,000,000 |
| Send packet CA -> Netherlands -> CA | 150,000,000 |
| Operation | Time (nsec) |
| System call overhead | 400 |
| Context switch between processes | 3000 |
| fork() (statically-linked binary) | 70,000 |
| fork() (dynamically-linked binary) | 160,000 |
https://www.jiuzhang.com/qa/1713/
首先，HR指出，Facebook 的 System Design 面试时长为45分钟，主要考察是是，求职者能否处理 Large Scale 的问题。在面试过程中，面试官会让你为Facebook设计一个feature。通过设计一个复杂的系统，面试官主要是想考察你在 consistency, availability 和 partition tolerance 之间如何做 tradeoff，进而评估你的思考、实践能力。在这里，Facebook HR 着重要求面试者，一定要看以下的资料：
【1】Dropbox Large Scale 相关视频：http://t.cn/zQUvcsq
【2】Facebook 关于Scaling Memcache的文章：http://bit.ly/1zqgW4p
其次，HR姐姐还给出了一些可能会考到的系统设计热门topic哦：
【1】Concurrency (threads, deadlock, starvation, consistency, coherence)
【2】Abstraction (understanding how OS, filesystem, and database works)
【3】Real-world performance (relative performance RAM, disk, your network, SSD)
【4】Availability and Reliability (durability, understanding how things can fail)
【5】Datastorage (RAMvs. durablestorage, compression, byte sizes)
http://blog.csdn.net/u013007900/article/details/79008993
https://www.hiredintech.com/courses/system-design
最后，请记住，根据面试官的目标，关于同一个系统设计问题的讨论可能会有不同的方向。他们可能愿意看到你如何创建一个涵盖系统各个方面的高层架构。也可能，他们会更关注一些特定的领域并深入研究。无论如何，你应该有一个如何处理不同情况的策略。
第一步：限制与用例
就像算法设计一样，系统设计问题的细节也很可能会被弱化。考虑关于URL缩短服务的问题（“设计一个像bit.ly的URL缩短服务”）。题目的信息非常少，如果不知道更多限制和要求，是不可能设计一个合适的解决方案。事实上，面试官并不会一开始就告诉你所有的信息，很多人都忘记了这一点，并立即开始设计解决方案。
对任何系统设计问题你应该做的第一件事是明确系统的限制，并确定系统需要满足哪些用例。花几分钟询问你的面试官，并统一系统的规模。我们在讨论算法设计时所讨论的许多相同的规则也适用于此处。
通常情况下，面试者希望看到的是你能收集到关于问题的要求，并设计一个能很好地覆盖这些要求的解决方案。永远不要假设面试官没有明确说明的事情。
例如，缩短网址的服务可能只能为几千个用户提供服务，但每个用户都可以共享数百万个网址。这可能意味着要处理数百万次缩短网址。该服务可能需要提供有关每个缩短的URL的统计信息（这会增加需要处理的数据大小），或者根本不需要统计信息。
您还需要考虑预期会发生的用例，您的系统将根据预期的目标进行设计。
限制
一般来说，大部分限制是来自于数据规模的限制。比如每分钟的数据量，访问人数等等。
如果你去问面试官，他可能直接给你数据，比如，我们每秒要处理400个请求；或者，他会说一些更笼统的信息让你去估计，比如，这个网站不是top 3但是却是top 10的。
在估算的时候，一定要注意合理。通常而言，用
二八定律是一个非常重要的准则。
关于这些限制的估计，人为主观因素有较大影响，不过在面试的时候除非估计得特别离谱，面试官一般不太会纠结于这方面，基本按照二八原则来估计就行了。
第二步：抽象设计
一旦你确定了你要设计的系统，你应该描述一个高层次的抽象设计。这步的目标是概述您的架构将需要的所有重要组件，而不是深入到抽象设计的某个方面，或者，直接一部分一部分来设计。
你可以告诉面试官，你想这样做，并画出你的想法的简单图表。勾画您的主要组件和它们之间的连接，在面试官面前证明你的想法，并试图解决每一个约束和用例。
如果你这样做，面试官会很快也很轻易地给你反馈。
通常，这种高级设计是人们已经开发的众所周知的技术的组合，比如，缓存，数据库读写分离等等。你必须确保你熟悉那里的东西，并且能够流畅地使用这些知识。这个地方就需要大家去多看书或者技术博客了。
值得注意的是，如果您的设计不能改满足面试官的要求，如，面试官要求高度的一致性约束，而您只能做到基本一致性，这是绝对不允许的。
第三部：理解瓶颈所在
考虑到问题的限制，您的高层设计有可能会有一个或多个瓶颈。这其实非常好。没有人能够一步到位地设计一个能够直接处理世界上所有负载的系统。我们希望的是这个系统具有可扩展性，以便您能够使用一些标准的工具和技术来改进它。
现在你有了高层次的设计，开始思考它有什么瓶颈。也许你的系统需要一个负载平衡器和许多机器来处理用户请求。也许需要存储的数据量太大了，系统应该使用分布式的数据库。这样做有什么缺点？分布式数据库是否太慢，是否需要一些内存中的缓存？
这些只是为了使您的解决方案完整而必须回答的问题的示例。面试官可能会希望在一个特定的方向上进行讨论。那么，也许你不需要解决所有的瓶颈问题，而是更深入地讨论一个特定的领域。无论如何，您需要能够之处系统的弱点，并能够解决这些问题。
请记住，通常每个解决方案都是某种权衡：改善一些方面会导致其他方面的恶化。然而，重要的是要能够谈论这些权衡，并根据所定义的约束和用例来衡量它们对系统的影响。
很多考察内容
比如面向对象，接口设计，设计模式，数据库表，分布式。
- Cache：缓存，万金油，哪里不行优先考虑
- Queue：消息队列，常见使用Linkedin的kafka
- Asynchronized：批处理＋异步，减少系统IO瓶颈
- Load Balance: 负载均衡，可以使用一致性hash技术做到尽量少的数据迁移
- Parallelization：并行计算，比如MapReduce
- Replication：提高可靠性，如HDFS，基于位置感知的多块拷贝
- Partition：数据库sharding，通过hash取摸
很多考察内容
比如面向对象，接口设计，设计模式，数据库表，分布式。
这里是个人观点：
1. 熟悉常见的 Web 应用架构模式。比如你经常刷知乎的话，知道知乎的时间线怎么设计嘛？可以到题库里面搜。
2. 如果你拿到了比较熟悉的题目，把它当成一次展示。因为系统设计面试很需要项目经验，很多公司在系统设计面试的同时会考查你项目经验。什么叫展示，去看看 QCon，PyCon 的视频。
3. 如果你拿到了你不熟悉的题目，但你还记得一些东西，把面试官当成你的同事，把面试当成共同解决这个问题。许多公司会在这里考查沟通能力，而且这样也会得到面试官的引导，让面试更愉悦一点。
4. 这个前面也有人提到了。先考虑单机情况，然后扩展。这样有个好处就是，一般来说系统设计问题的单机版本就是面向对象设计问题。你起码可以告诉面试官，你单机上是完全没问题的。
先考虑大方向（BigPic）然后划分角色（数据库、缓存、消息总线等等）。最后再谈具体的技术（比如 Redis），许多人一谈到具体的技术，就说可以用它解决，但不谈技术的原理，这个非常麻烦。
Read full article from
How to Ace a Systems Design Interview | Palantir
