面试官说你java基础薄弱

面试官说你java基础薄弱

Usually, the System Design interviews are lengthy and cover a lot of complex components. This makes it very easy to get lost in small things and miss out on the big picture. Therefore, it becomes very important to structure your interview in a way such that you can easily convey the whole picture without wasting time on anything which does not add value.

通常，系统设计访谈的时间很长，涉及许多复杂的组件。 这使得很容易迷失在小事情上而错过大局。 因此，以适当的方式组织面试变得非常重要，这样您就可以轻松地传达整个图片而不会在没有增加价值的事情上浪费时间。

Below is the structure that I follow, and you could try the same.

下面是我遵循的结构，您可以尝试相同的方法。

推动面试 (Drive the interview)

Make sure you are the one driving the interview and not your interviewer. This does not mean that you do not let them speak, but rather, you should be the one doing most of the talking, proactively calling out issues in your design before the interviewer points it out, handle the edge cases that the interviewer might poke you on etc.

确保您是推动面试的人，而不是面试官。 这并不意味着您不会让他们说话，而是您应该是大多数人中的一个，在面试官指出之前主动提出设计中的问题，处理面试官可能会戳您的极端情况等等

FR和NFR (FRs and NFRs)

Clearly call out the Functional and Non-Functional requirements. The intent is that the requirements should be big enough that makes the problem challenging and also finite enough that you can build a system that fulfills those requirements within the stipulated time. From the Non Functional side, try to make a system that works at a very large scale. What’s the fun in designing a system which works at a low scale?Before finalizing the FRs and the NFRs, get them reviewed with your interviewer to make sure they do not want to add/ remove something. At times, interviewers do have some particular use cases in mind that they want to go over.

明确指出功能和非功能要求。 目的是要求的大小应足够大，这使问题具有挑战性，并且也应足够有限，以便您可以构建一个在规定的时间内满足这些要求的系统。 从“非功能性”方面，尝试使系统能够大规模运行。 设计小规模工作的系统有什么乐趣？在最终确定FR和NFR之前，请与面试官进行审查，以确保他们不想添加/删除某些内容。 有时，访调员确实会想着一些特殊的用例。

容量估算 (Capacity Estimation)

Check with your interviewer if they want to get into this. A lot of people prefer to skip the calculations and focus more on the design, assuming a large enough approximate number for the number of cores required or the amount of disk required etc.

请与您的面试官联系，以了解他们是否想要参与其中。 许多人更喜欢跳过计算，而将更多的精力放在设计上，假设对于所需的内核数量或所需的磁盘数量等足够大的近似值。

计划 (Plan)

Based on the FRs and NFRs, come up with these things:

根据FR和NFR，提出以下这些内容：

User Interaction Points.

用户互动点。 Latency/ Availability/ Consistency requirements at each of the user interaction points.

每个用户交互点的延迟/可用性/一致性要求。 A quick analysis estimating if it’s a read-heavy interaction or a write-heavy interaction.

快速分析，估计是重读交互还是重写交互。 Based on the above three, come up with what all services you’ll need and what kind of databases you can use to store the data that each of these services owns.

在以上三个基础上，提出了您将需要的所有服务以及可以用来存储每个服务拥有的数据的数据库类型。

HLD (HLD)

Come up with a high level component diagram, that covers the following:

提出一个高级组件图，其中包括以下内容：

What all services are present? Make sure you divide the flow into multiple functional components and see if a microservices based approach makes sense or not. Usually, using a microservices based approach is a good idea in SD interviews.

提供什么服务？ 确保将流程分为多个功能组件，并查看基于微服务的方法是否有意义。 通常，在SD访谈中，使用基于微服务的方法是一个好主意。 How do the services interact with each other and what kind of protocols are used for inter service communication like Async/ Sync — Rest, RPC etc?

服务之间如何交互，以及用于服务间通信的哪种协议(如异步/同步-休息，RPC等)？ How would the users interact with the whole system and what all services are user facing. Do you need a Cache to reduce latencies?

用户将如何与整个系统交互以及用户所面临的所有服务是什么。 您是否需要缓存来减少延迟？

Which service uses what Database and why? You can refer to this video that can help you choose the right database based on your use case

哪个服务使用什么数据库，为什么？ 您可以参考该视频，以帮助您根据用例选择合适的数据库

See if you need caching anywhere and if you do, then what shall be the eviction policy, do you need an expiry for the keys, should it be a write through cache etc?

看看是否需要在任何地方进行缓存，如果需要，则应执行什么驱逐策略，是否需要密钥到期，是否应该是直写式缓存等？ Basis all this analysis, draw out a High Level Diagram of your whole system.

基于所有这些分析，绘制出整个系统的高级图表。

必须拥有 (Must Haves)

Some key things your high level diagram should have are:

您的高级图表应该具有的一些关键内容是：

Load Balancers

负载均衡器 Services

服务 Databases and Caches

数据库和缓存 User interaction points

用户互动点 Any other tools like a Message Queue, CDN, etc.

其他任何工具，例如消息队列，CDN等。

演练设计 (Walkthrough the design)

Once you have the whole diagram ready, go over the whole design, one use case at a time and explain your design to your interviewer at a very high level. Talk about why you have chosen a particular database here and why you have used a particular mode of communication like Sync/ Async etc. You can also get into an RPC vs HTTP kind of a conversation if you made a particular design choice. You should go over what kind of data replication strategy is being used in your databases, for example, would you use a Master-Slave or a Multi Master setup etc. If this sounds intimidating, you can check out how I usually do a design walkthrough in this video.

一旦准备好整个图表，就可以遍历整个设计，一次使用一个用例，并以很高的水平向面试官说明您的设计。 在这里讨论为什么选择特定的数据库，为什么使用特定的通信模式(例如Sync / Async等)。如果做出了特定的设计选择，您也可以进入RPC vs HTTP的对话。 您应该检查一下数据库中使用了哪种数据复制策略，例如，您将使用主从设备还是多主设备设置等。如果这听起来很吓人， 您可以查看一下我通常如何进行设计演练在这部影片中 。

CAUTION: Do not go into the details like APIs, DB Schema etc right away unless the interviewer asks for it. Most people get lost in designing the APIs for just one system at this point and run out of time later on.

注意 ：除非面试官要求，否则不要立即进入API，DB Schema等详细信息。 在这一点上，大多数人迷失了为一个系统设计API的时间，后来又用光了时间。

Brownie Points: Most interviews do not have FRs and NFRs around analytics, but if your design covers that or leaves good enough scope for analytics, that elevates your solution a lot. Try to add that. For example, you can look at this.

布朗尼要点(Brownie Points)：大多数采访都没有关于分析的FR和NFR，但是，如果您的设计涵盖了该范围或为分析留出了足够的空间，则可以大大提高您的解决方案。 尝试添加。 例如，您可以查看this 。

实作 (Implementation)

Once you explain the whole flow to your interviewer, ask them which component they want to discuss in detail. Usually, people do not want to go over the entire system in detail. Let them decide which is that one component that they want to dig into and then you can go over the implementation details of that particular system. Things you should cover here are:

在向面试官说明整个流程后，请他们询问他们要详细讨论的内容。 通常，人们不希望详细了解整个系统。 让他们决定要挖掘哪个组件，然后您可以遍历该特定系统的实现细节。 您应该在这里介绍的内容包括：

APIs — Call out the APIs that this system exposes. Make sure you are using the best practices here. For example instead of a GET API with URL like GET /user/getUserbyUserId, it’s better to use: GET /user/{id}

API —调用此系统公开的API。 确保您在此处使用最佳做法。 例如，最好不要使用URL这样的GET API，例如GET / user / getUserbyUserId ，最好使用： GET / user / {id}

API Protocols — You can cover what protocols are you exposing the APIs on. Most people choose REST APIs, but you can decide to use something more efficient like Thrift, Protobuf etc based on your use cases.

API协议 -您可以涵盖要公开API的协议。 大多数人选择REST API，但是您可以根据用例决定使用更有效的工具，例如Thrift，Protobuf等。

Events — You can call out which events this particular service listens to, who produces that event, what payload comes in, what processing happens on that event etc.

事件 -您可以调出该特定服务侦听的事件，产生该事件的人，传入的有效负载，对该事件进行的处理等。

DB Schema: Go over the DB Schema here. You can also get into SQL vs NoSQL debate or why have you chosen a particular database, if you did not go over the same earlier while talking about the high level design.

数据库架构：在这里浏览数据库架构。 您也可以进入SQL vs NoSQL辩论，或者为什么要选择一个特定的数据库，如果您在谈论高级设计时没有更早地进行过讨论。

If it’s a SQL, do talk about what indices you’ll have and how are you optimising your queries. In case of NoSQL, make sure you go over the consistency guarantees that the DB provides, can it cause any issues and the kind of queries you’ll run on that DB. Clearly call out the keys for key-value stores or the partition keys for a columnar store etc.

如果是SQL，请谈论您将拥有哪些索引以及如何优化查询。 如果使用NoSQL，请确保您遍历了数据库提供的一致性保证，是否会引起任何问题以及您将在该数据库上运行的查询的种类。 清楚地调出键值存储的键或列式存储的分区键等。

处理墨菲定律 (Handle Murphy’s law)

This is something that most people skip but this is one of the most important things that you must cover which talks about how resilient your system is. In the real world, things break, and when they do, you need to make sure you are in full control of your system.

这是大多数人都跳过的事情，但这是您必须涵盖的最重要的事情之一，它谈到了系统的弹性。 在现实世界中，事情会破裂，而当事情破裂时，您需要确保完全控制系统。

Talk about how you monitor the system. What kind of alerting mechanism do you have in place? What are your KPIs (Key Performance Indicators) and how do you track them? What happens when things break, when your service crashes, your DB’s master node goes down or even when one of your datacentres goes down?

谈谈您如何监视系统。 您采用哪种警报机制？ 您的KPI(关键绩效指标)是什么？如何跟踪它们？ 当事情中断，服务崩溃，数据库的主节点出现故障甚至某个数据中心发生故障时，会发生什么？

Again, if you haven’t done this before, see how I have been doing it, towards the later half of this video.

再说一次，如果您以前没有做过， 请看本视频的后半部分，我是如何做到的 。

This is my checklist, that I usually follow when I try to design any system, be it in an interview or in the real world. Hope this helps!

这是我的清单，当我尝试设计任何系统时，无论是在采访中还是在现实世界中，我通常都会遵循该清单。 希望这可以帮助！

翻译自: https://towardsdatascience.com/system-design-interview-checklist-a-gateway-to-faangs-2b7fac80e423

面试官说你java基础薄弱