0:03
大家好我是Terry今天要来跟大家分享一下软体工程师的系统设计面试到底在面什么我几个月前是怎么自己准备然后成功的通过Google的Level 5的系统设计面试还有一些面试的技巧如果有经验的人应该都知道通常在北美面软体工程师的职位的时候都有好几轮的面试那我们说技术性方面的面试大概分为两类第一类就是考算法数据结构的应用这部分我在之前的一个影片里面有介绍要怎么去准备如果有兴趣的话可以去看一下
0:31
另外一部分就是我們今天要聊的叫系統設計其實硬要說的話也能歸類出第三個部分我把它稱之為Technical Deep Dive但是因為這部分不算是主流沒有前面兩個那麼好準備所以以後要是有機會的話再跟大家聊那系統設計面試到底在考什麼
0:46
其实最常考的概念就是去设计分布式系统大家知道像Google Facebook Amazon这些靠网络服务起家的公司他们背后的设计理念都离不开distributed system但是有时候也不一定考这个这是比较常出现的题目跟范围
1:01
我自己也当过面试官面过很多人有些很资深的工程师他们有很多年的工作经验但是面系统设计这一轮的时候反而做的不好因为他们没有准备嘛很多人觉得自己经验很丰富这些东西对他们来讲是common sense但是往往就是因为没有准备所以回答的很杂也没有规划也没有讲到重点因为可能很多的知识或许他们都知道但是不知道怎么在短短45分钟之内把它精简的呈现给面试官再来还有很多技巧都可以大大提升面试官对你的好感并且增加你拿offer的能力
1:30
那今天就來跟大家分享一下一些面試技巧還有我自己準備系統設計面試的方法那今天這集影片呢我不會講太深技術性的東西我想以後有機會可以在另外一個頻道或者是另外一個地方專門做這些影片的教學如果有興趣的話你可以在下面留言告訴我你的想法那我第一次接觸系統設計面試的時候是在大學那時候面美國的一家公司然後他們考我設計一套系統類似YouTube這種Streaming的服務那那個時候呢就真的是亂講完全沒有遇到過這種題目也不知道怎麼準備
1:59
其實我自己是覺得系統設計面試在準備起來會比LiCol那種面試更有意思寫LiCol寫到後面真的是會懷疑人生因為它有時候就像在寫謎題一樣會比較容易疲乏但是系統設計的話我反而會覺得很有趣因為它更像是一種討論性的面試通常沒有什麼對還是錯的答案而且你根本不用去真的去實行說真的你就是靠你的想像力還有嘴炮而已不像寫Code的面試你要把代碼真的寫出來然後有時候還要求程式要正確的跑完沒有錯誤
2:32
那我们前面说到比较常见的就是设计distributed system的应用举个经典的例子来说设计一个简化版的Twitter或是类似Twitter的这种服务就是一个蛮常考的东西为什么这类型的题目很常考呢因为它涉及到基本的前端设计后端服务器的设计到database里面的设计然后可以讨论很多skill方面的问题例如今天有100万个用户在同时使用的话你要怎么去设计让你的服务器不会爆掉又可以同时服务世界各地的用户
2:59
又或是例如今天在美国东岸的服务器坏掉了你要怎么确保用户体验可以不受影响这些诸如此类的应急措施那为什么这些概念很重要呢尤其是对资深工程师来说因为你带的项目很有可能就会涉及到这些问题你要知道像YouTube Facebook这种大型的服务器靠广告在维生的要是挂掉了每一秒基本上都在喷钱或是像是Netflix你要是看电影每五分钟就给你卡一次你一定会很想直接退订阅
3:24
所以我认为系统设计题目普遍来说最好的approach是先提出一个比较简单基本的设计然后从这个设计再来进行优化有些人很急着想要去impress面试官一开始就把那些什么cashdiabetes sharding然后哪里要用low balance那些乱七八糟的东西就放在design里面然后变得很复杂这样做的话有几个坏处第一个就是你可能最后会没有时间把一个完整的working solution给呈现出来因为系统设计可以讨论的follow up的问题真的很广
3:50
每个面试官在乎的方向也不太一样有些面试官很在乎你怎么去define你的数据结构或者怎么去设计你的API那有些面试官更在乎你怎么去支援同时有大量的用户在同时使用你的产品所以你很有可能就把自己带跑题了然后花一堆时间在面试官不在乎的地方上面再来就是假如你一开始就直接进入很复杂的设计基本上大部分的时间都是你自己在讲
4:13
就变成面试官在旁边看戏那假如你中间犯了什么错误你到后面可能就要回去改这些东西就会很浪费时间因为你把你整个设计变得很复杂就因为系统设计是一个很开放式的题目面试官更希望你从一个比较基础的答案开始然后你至少有一个working solution然后慢慢的根据他提出的要求或许他会问你一些比较特殊的情况你要怎么去handle然后让你去修改这个设计那这轮面试就会变得你跟面试官有很多的互动还有讨论
4:40
当面试官跟你的互动越多互相分享自己的想法你们聊得越开心通常代表说这轮面试你越有希望因为大部分的面试官更希望招来的人是可以跟自己一起工作一起讨论不同想法的人第二个诀窍就是要不断的问问题然后尽量表明你的假设通常面试官会给你一个很笼统开放式的题目然后需要求职者去提问你要把这个scope变得更小更可行一点把一些不确定性拿出来讨论
5:05
然後跟面試官達成一個協議以之前我們說的Twitter的那個例子面試官或許只會告訴你說我們今天要來設計一個類似Twitter的服務器就這樣而已那你在開始設計之前你會需要問非常多的問題還有提出很多假設例如我們要假設有多少個活躍用戶每個用戶每天平均發多少個推文系統需不需要支持用戶回覆推文系統需不需要支持用戶點讚之類的因為通常面試只有45分鐘
5:30
面试官不会真的要你去设计一个很细节的东西你只要跟面试官达成一个协议说我们的系统会让用户发推文然后用户可以追踪其他用户然后用户发的推文呢会需要被追踪的用户给看到之类的functional requirements还有一些non-functional requirements你会需要跟面试官去厘清例如用户每次刷新动态延迟不会超过300毫秒之类的
5:51
这部分面试官审核就是你有没有能力去主动理清一些很基本的设计概念那这边最常犯的错误就是你自己去假设一些你觉得是理所当然的东西然后没有去跟面试官沟通像是你可能会觉得用户可以点赞是一个很基本的feature但是其实面试官考你的设计重点是在即时动态那一部分
6:10
然后如果你又花很多的时间在设计这个点赞的feature上面就很有可能让你这一轮面试不及格第一个你没完成面试官要考的重点第二个就是你没有试图去沟通了解面试官重点在哪里这些都可以反映出来你在未来真实做项目的时候跟产品经理沟通的一些表现那第三个tip呢就是focus在基础的概念上面然后不要太纠结于某些技术的细节尽量让面试官去带这个节奏例如你们现在讨论到database你不需要去跟面试官说我们要用AWS里面的
6:39
RDS里面的MySQL大部分的时候你只需要了解SQL跟NoSQL这两个Database区别就好了然后为什么你选择SQL而不是NoSQL因为每家公司用的云端服务可能都不太一样而且你如果面对像Google这种规模很大的科技公司他们内部一定有自己的SQL Database可以让你选可能是一些你根本没听过的东西所以你不需要去把这些东西讲得这么细反而有时候会变成对你来讲是一个不利的情况
7:03
假如面试官反问你说为什么你选择用MySQL而不是用Postgres这时候你又刚好两个都写在你的resume上面因为你都用过那你又说不出个所以然这样的话这人就会被扣分我觉得尽量让面试官去带整个面试的节奏如果他想要知道你用过哪些SQL的Diabase他会很明白的直接问你你不需要自己去挖一个坑往里面跳而且系统设计这部分考你的更多是一些基础的概念而不是你要怎么去实际实行例如面试官叫你设计一个图书馆的查找系统
7:32
有些人可能会直接就开始写一些class啊function那些在这边我建议你要是不确定的话就直接问面试官Do you expect me to write some code and come up with a working solution?Or are we going to focus more on just the design?假如他给你的题目很笼统这些都是你的责任去厘清这些东西再来下一个诀窍就是你要主动提出tradeoffs因为season design这种题目是没有一个正确的答案的
7:54
很多時候會有兩種甚至三種以上的設計方法都是可行的但是都有他們的利弊你需要去權衡那你要是能去主動的提出這些設計的利弊的話會大大的讓你這輪面試加分舉個例子來說假如現在聊到要怎麼去share你的database這邊的話就有很多種切法你可以把不同的table放在不同的server上面
8:13
但是这样做的缺点就是可能会造成不均衡的Server Load那你也可以Short by 某一个ID就是有一个Hash Function去决定你这个数据要存在哪一个Server上面这样做的优点是什么缺点是什么这些你都要尽量去主动提出来绝对会让面试官对你的好感增加代表说你懂得概念很广而不是只知道一种设计方式因为在真实的工作环境下最好的设计方式通常都不止一样每一个项目它的Business Requirements都不太一样
8:39
而身为机身工程师的你是要有这个基本的概念跟提出不同的tradeoffs的能力再来下一个就是不要去背答案后面我会讲我是用什么资料去准备的那你在做准备的时候会看实际的这些例题像是怎么去设计推特假如只是无脑的去背答案的话就算你真的刚好被问到同一题他稍微只要改一点requirements你可能就不知道该怎么回答
9:01
系统设计的题目非常的广能问的问题真的太多了最好的准备方式就是真正去了解那些经典例题它是怎么去被设计的然后在看那些设计方式的时候你自己去想一下Do they make sense to you?然后假如你能想出更多设计方法的话
9:15
那代表你是真的有在思考而不是无脑的在记答案那假如你在准备的时候这些东西你了解的非常的吃力或者是你根本不懂一些基本的database的原理那代表说你可能还没有到这个级别可能还需要多一点的工作经验毕竟system design的面试通常是针对比较资深的工程师而对经验较少的工程师来说focus更多是在coding这方面那最后一个tip呢就是don't argue with your interviewer
9:39
有些时候你的面试官不一定知道比你还多或许你是正确的但是你的目标是在这一轮面试中尽量拿到strong hire而且假如你花太多时间跟面试官去争论一些没有意义的小东西是没有必要的就算你争论赢了证明自己是对的这也不代表说对方会真心认同你而且假如你遇到那种比较自我一点的面试官他很有可能这一轮就直接把你给挂了
10:00
他不会在乎你到底是不是对的他会觉得说你浪费一堆时间在跟他争论而没有把时间花在其他更重要的地方上面我有遇到过类似这样的情况虽然我知道我应该是对的但是我一直保持着一个态度就是说我还是有可能会出错我有可能是错的我就说oh yeah maybe I'm just missing somethingbut yeah you're probably right那我们就会move on到下一个环
10:19
能虚心接受feedback也是一个很重要的quality有时候当下真的谁对谁错不是那么的重要以上就是我的一些经验跟建议希望对你准备系统面试有一些帮助那我自己当时准备的方法其实很简单有一个叫做Glocking Assistant Design Interview你自己可以去Google一下它是一个阅读的课程我这边没有在帮他打广告就只是告诉你我自己当时准备的时候是用了什么课程你如果买这个课程的话我一毛钱也不花
10:41
它是一個有點像電子書的課程它不是影片它裡面就是大概有15題的經典例題加上一些基礎的知識我覺得這個課程幫助我最大就是我讀完這些經典的例題之後大概腦袋中就會有一個模板可以按照這個模板來走完這一輪面試從最基本的如果是
10:57
到最后怎么去scale它算是一个比较循序渐进的模板去完成一个系统设计有这个框架之后就不容易手忙脚乱想法跳来跳去导致最后自己的设计变得一团乱那它里面讲的这些经典的题目呢我大概都看了两遍以上我的准备方式就是我不只要了解它里面提到的设计方案我自己还会做笔记然后去想更多的设计方法
11:23
還有他們各種不同的 trade-offs再來就是他裡面講的東西都比較基本有些是沒有很細節的去解釋例如我更想了解Cassandra它內部是怎麼運作的我會自己去Google這些東西然後做筆記那這些就是我當時學習的方式再來就是我自己本身對這些Design的東西就蠻感興趣的所以在準備的時候不會感覺到枯燥乏味反而我覺得我學到了真的很多很有用的東西可以跟我實際工作上面做結合最後如果你正在準備系統設計面試的話我建議你可以找身邊的朋友幫你做幾個Mock Interview
11:51
這些都可以讓你熱熱身然後了解一下自己還有哪些地方需要改進加強好啦今天的影片就到這邊了如果你喜歡這集影片的話可以幫我點個讚還沒有訂閱的朋友的話可以認真考慮一下如果大家有興趣的話我之後可能會在另外一個地方真正的帶大家去做一些系統設計還有coding的題目希望能幫助你拿到更多的offer那你有什麼想法跟建議的話都歡迎在底下留言跟我說那我們下次見囉
