如何在45分钟内搞定系统设计的面试

295 阅读9分钟

如何在45分钟内搞定系统设计面试

在深入探讨之前,我想分享一下我为什么要写这篇文章。

我现在在Netflix担任高级软件工程师(后端)。在此之前,我曾在eBay、高盛和美国银行担任后端系统的软件工程师。系统设计面试是每个面试周期的一部分,不管是大公司还是小公司的初级职位、中级职位还是高级职位。我自己也在设计面试中挣扎,觉得自己无所适从,无法在45分钟内拿出一个流程设计,这时我开始与导师和周围的朋友讨论如何在45分钟内解决一个需要100多位工程师花几年时间才能解决的问题。在阅读了几篇设计面试的文章和书籍,并参加和接受了几次面试后,我想出了自己的处理策略,并开始与朋友和学员们分享,他们也觉得很有用,因此在这里写了这篇文章。我们中的大多数人都熟悉设计的技术层面,但缺乏在45分钟内结构化或框架化一个完整的(不是对或错)解决方案的能力。我将专注于如何以最有效和高效的方式及时结构化问题。由于明显的原因,我的主要重点将放在后端设计上 😉

我将把我的帖子分成以下几个部分。

  • 软技能技巧
  • 如何分配45分钟的时间

🤖 软技能技巧。

  • 仔细聆听,不要急于在心中设计。 通常,当面试官还在解释问题时,我们就开始提前思考,并试图将其与你过去可能做过的事情联系起来--无论是在你的工作或学校项目中,还是在准备面试时读到的。虽然你确实得到了一个先机,但往往容易错过面试官在思考时给出的重要提示/要点。因此,一定要仔细听,并注意他/她/他们提到的所有关键特征
  • 如果你不了解这个领域,不要惊慌。没有人可以知道所有的事情,这是完全可以的。有一次,我被要求设计一个基于酒精和用户喜爱的口味的鸡尾酒配方应用程序。我从来没有探索过这个领域,所以我完全迷失了。我从内心深处感到恐慌,但却试图表现得像正常人一样。几分钟后,我告诉面试官,我对鸡尾酒不太熟悉,我们都笑了起来。然而,我喜欢烹饪,我试着把它与我知道的东西联系起来,即设计一个应用程序,根据现有的材料生成食谱。因此,如果你不知道这个领域,试着与你知道的东西进行关联,并让面试官预先知道。通常情况下,面试官会很有帮助。
  • 展示你所拥有的技能和知识,而不是去猜测面试官在你身上看到了什么。 这些面试最好的一点是没有正确或错误的答案。这些面试是为了让面试官了解你对系统设计有多少了解,你在理解模糊的需求和寻找出路方面有多勤奋,这在现实世界中经常发生。当你在高压环境下第一次与人见面时,你很可能无法弄清楚面试官在寻找什么!😊。但是,如果面试官事先提到,比如他/她/他们想知道你如何做缓存/分布式缓存,那么你就有了重点关注的线索。所以,你要专注于展示你的知识来解决问题,而不是去想应该关注什么,因为面试官可能在寻找XYZ的技能。
  • 对琐碎的过程使用黑箱技术。:一旦你清楚了需求,并且有计划地关注哪些服务,就不要去设计每个可能需要互动的服务。只花时间来设计主要的服务。如果时间允许,以后再来设计琐碎的服务。例如,如果你正在设计一个家具店的买家体验,不要花时间去设计一个支付处理器来完成结账过程。相反,放一个盒子,并将其标记为支付处理器,以获取信用卡信息和客户的详细信息来执行支付。支付处理平台本身可以是一个系统设计问题。另外,这并不意味着你在设计图中放上一堆盒子就叫完成了......😉所以,不要设计每一个将成为交互的一部分的服务,用黑盒子来表示上下文中琐碎的服务。
  • 在讲述你的选择时,总是提出权衡。:仅仅告诉面试官你的选择并不总是足够的。因此,在面试官进一步询问你之前,你可以提出权衡利弊,以及任何使你选择A而不是B的其他背景,这也显示了你的理解深度,它不仅仅是一个侥幸或随机选择。因此,不要等待面试官质疑你的选择,解释理由并讨论你考虑的其他方法的权衡。

如何分配45分钟的时间?

我们大多数人面临的主要挑战之一是如何有效地管理我们的时间,以便我们能够提出一个最有效的解决方案。以下是我通常尝试划分时间的方法。我使用FUSH'D 技术(刚编出来的,不认为任何地方有这种东西😋)。下图显示了它所代表的含义。

FUSH'D技术

让我们看看我通常在这些方面花费多少时间。所有的时间都是近似的时间,在某些情况下可能会有所不同,但是,我发现这种细分非常有效。

F特征冻结:5分钟(大约)。利用前5分钟来问清楚问题,并尝试冻结2-3个(或更多,视情况而定)你正在尝试设计的功能。比如说。如果你正在设计一个在线家具商店,你可以考虑以下功能。

  • 购买/结账家具
  • 在不同的类别和标签(颜色、材料、尺寸)下搜索家具
  • 收藏/保存待用
  • 用户资料(通常这对大多数应用程序来说是很常见的)。

对这些功能进行初审,并提出更多的改进建议,如。定制,交付跟踪,使用AR的3D可视化,等等。请注意,这些东西可能需要更多的时间来钻研。面试官可能会要求你从这些增强功能中挑选一个听起来更有趣的。此外,如果你认为某些东西与你过去的经验有关,或者你真的很有信心,现在是时候包括它了。

U:使用案例:5-6分钟(大约)。对于你在上一步骤中锁定的每个功能,想出用例。确保也包括负面的用例,并强调你的系统不能解决什么问题。你可以讨论关于挑选特定用例的权衡/偏好。花点时间计算一下流量模式,每秒钟的呼叫,预期的SLA等。

S存储。3分钟(大约)。根据用例和场景,决定你将存储什么。像家具用例,你将需要存储库存--项目ID、价格、数量。用户愿望清单中的物品状态,用户信息等。另外,根据目标受众,检查你最终要存储的数据量,并为你的数据存储提出估计。为将来的扩展和增长留有余地。

H高层系统设计:7分钟(大约)。这是该问题的灵魂。想出各种组件/服务,并根据用例和功能定义它们之间的高层次互动。还包括终端用户如何与系统互动,是否是api终端、Web UI、移动应用程序等。弄清楚数据库的交互是什么样子的,你是否会使用任何排队机制来排查任何请求。你可以从一个小系统开始,以后再进行扩展。这也是触及如何有效和快速地提供响应的正确时机,你是否需要缓存,是否会使用浏览器缓存,memcached等,以及它们的权衡(通过详细的设计部分深入研究)。这些讨论将显示你对不同方面的理解的深度,你已经意识到并在你的设计中考虑到了。(PS: 仅仅使用这些术语是不够的,你也应该有正确的理解。)

D:详细设计: 20分钟(大约)。这是我花大部分时间的地方。我通常会将这部分进一步划分如下。

  • 7分钟:API和交互。开始为各种用例定义API,定义POJOs。你可以使用微服务架构并为某些功能定义特定的微服务。思考如何提高SLA和响应时间。有些面试官会要求你定义类、关系,也许为某些用例写一个小函数。对这一点要持开放态度。
  • 5分钟。数据库设计,SQL/No-Sql数据存储,等等。面试官可能要求你在这里写一些SQL查询。准备好用坚实的理由来证明你的选择。CAP理论在决定为哪种用例选择哪种数据库时往往很方便。
  • 7分钟:可扩展性。大多数面试官将有兴趣了解你的解决方案的可扩展性。这时,你将采取各种措施来扩展和优化你的反应。你将如何做负载平衡,以确保单个服务器不会因大量的请求而过载,而其他服务器则处于闲置状态。你将如何分配请求和数据(数据分片),是否基于地理位置、基于密钥、基于哈希等等?你可以使用什么样的缓存解决方案。经常出现的一个重要问题是,当数据增长得非常大的时候,你会怎么做?你将如何截断或归档那些可能不经常需要的数据,等等。你也可以围绕缓存解决方案,以及如何刷新缓存,确保缓存的一致性或可用性等问题展开。
    准备好在这一部分接受大量的交叉提问,因为面试官想测试你的知识,不仅仅是概念上的,还可能有兴趣知道你对市场上现有的解决方案有多熟悉。这些讨论也是为了检查你的沟通技巧、气质、说服力等。

这几乎概括了我如何在面试中花费40分钟,留下5分钟用于介绍/提问等。