越來越多的面試在第二面的時候提出需要面試者準備簡報的要求,我自己也在二面做了幾次的簡報準備,甚至是在一面的時候就先想好我會怎麼介紹這家公司的產品(有點職業病)。
今天的文章比較長,包含:
1. 二面簡報的常見情景:業務 / 商務開發 / 導入團隊
2. 本次模擬面試背景:職缺 / 工作重點 / 情境 / 時間限制 / 參考資料
3. 二面簡報的要點:態度 / 大綱 / 系統的解說
4. 四個常見的問題
一、【二面簡報的可能情境:】
1. 面試「業務」:
請你根據你對於產品的了解簡報
2. 面試「商務開發」:
請你根據產品的特性分析整個產業以及可以進攻的方向/預估業績目標/打法
3. 面試「Customer Success / 導入團隊」:
請你根據產品設計一份針對客戶的教育訓練簡報
此時,通常面試公司會提供兩個參考資料(不一定每一個都有):
1. 原先有的sales kit / 教育訓練的PPT
2. 系統的demo帳號
有天晚上幫朋友(兼諮詢者)做了一個二面簡報的模擬面試。
在這一次模擬面試裡,朋友提出了四個問題,我們可以先放在心裡,文章結束後,我們再來快速回覆:
Q1: 通常這類型的簡報會怎麼結束?
Q2: 我怎麼知道哪些名詞是這個產業的專有名詞、哪些是這個系統創造出來的?
Q3: 說明功能的時候通常是用PPT截圖還是直接在系統使用呢?
Q4:這些功能真的是幫他們解決問題的功能嗎?還是說這家公司其他的系統也可以做到?
二、【本次模擬面試背景 】
▲ 面試的職缺:Customer Success / 導入團隊
▲ 職缺的工作重點:這樣的職缺常出現在系統公司裡,客戶購買系統後,需要一段時間的系統導入期,此時會有一個導入團隊,帶領客戶完整導入、從資料清洗、資料彙整、系統使用教育訓練、初期系統設定與優化。
▲ 簡報情境:你現在要簡報的對象是已經購買了此套系統的行銷部門,這是他們第一次的教育訓練。
▲ 簡報時長:一小時為上限
▲ 提供參考資料:系統的demo帳號
三、【二面簡報的要點】
分別包含:
1. 簡報的態度
2. 簡報的大綱
3. 系統的解說
1. 簡報的態度
為什麼把簡報的態度放在最前面呢?因為,簡報的態度會影響你的肢體語言、用字遣詞、預設心理。
心態上,如果你是一個系統導入團隊,你自然是以自己公司的產品為傲,但是對方公司員工不一定也這麼認為。
疑?你會問,如果對方公司不認同的話,為什麼要購買? 因為公司上層認同,不代表今天聽你說話的這群行銷人員也認同。
他們可能手上有很多專案,時間卻都不夠用了,卻還是要上這個教育訓練。
他們也可能已經習慣了很多系統的使用,儘管可能用起來有點麻煩,但是至少習慣了,現在是要嘗試學習一個不知道是更方便還是更麻煩的系統。
他們可能心想著,不知道這個系統導入又要花多少時間整理資料了,天啊,工作真的做得完嗎?
因此,你的簡報,必須能夠回答他們這些心中的問題,降低他們的恐懼,讓他們開始相信這個系統會解決問題,而不是帶來更多問題。
這麼一想,首先你的用字遣詞就會開始變成比較快樂、正向的,傳達一種「我帶來了一個好消息,我來協助你們解決問題」,接著,你的簡報會從「解決他們心中的不安、痛點」開始,先把對方的疑問解決了,有個心靈上的默契,再講系統的部分。
2. 簡報的大綱
這類型的簡報大綱,通常會包含幾個部分:
(1)這個系統的好處
(2)導入需要的時間、時間軸、要完成的任務、每個人物雙方的對口
(3)系統基本名詞的解釋
(4)常見情境demo
(1)這個系統的好處
講解系統的好處時,不要拿出太複雜的系統架構圖,哈哈哈,太困難的系統架構圖,不要說是行銷人員,我都會覺得崩潰。
而且,複雜的架構圖會讓人一開始就覺得這是件很困難的事情,一開始可以談談通常使用這個系統的人之前遇到怎樣的困難。
疑?這不是業務才要做的事情嗎?跟客戶說明用了這個系統可以解決什麼痛點。
當然,但是呢,你面對的這群人也是需要知道的,一個產品的銷售不是在簽約後結束,而是在簽約後才開始。 (畢竟還有續約、upsell啊)
所以,我會建議你把系統的功能,都轉為「這個功能可以解決的最大問題是什麼」。
例如,功能是可以把「客戶分類自動化」。
解決的問題就是「你們是不是覺得每天都要花很多時間比對名單、撈名單、分配名單,有了這個功能,只要名單放入系統,系統會隨時根據你的定義圈選符合定義的名單,節省下你每天處理名單的時間。」
當人們聽到這件事情對他們是有幫助的時候,那就他們就會對你說的話產生興趣。 因此,在一開始,可以說明這個系統可以解決的三大問題。
(2)導入需要的時間
包含:時間軸、要完成的任務、每個人物雙方的對口
這裡最簡單的表達方式是一個時間軸搭配一個簡單的專案導入組織圖。
時間軸有預計導入的時間(一個月?三個月?半年?)
每個節點需要完成的事情,例如資料清洗、資料整合、教育訓練、實機操作等等。
每個節點雙方需要的人力、各自負責的窗口、產出的文件(內容)等等。
因此,有個組織圖是會幫助理解的。
這可能只有一頁,但是人都關心「所以我什麼時候需要做什麼?」,導入團隊其中一件事情就是妥善分配大家需要的做的事情,掌握時間。
(3)系統基本名詞的解釋
抓出幾個常用到的名詞,配合簡單的系統截圖,每個名詞花個30秒解釋,我覺得是可以的。 這點要看系統的難易程度。 越是整合多方系統的第三方系統,複雜度會越高,越需要名詞解釋。
而你,在面試時,很有可能你就是這個系統的小白,如果你自己也不懂,那就是一個需要被說明的地方。
如果你都懂呢?那講給一個可能都不懂的人聽,他不懂的,就是需要解釋的。
(4)常見情境demo
不管是在真實的教育訓練、還是面試,我們不可能把系統全部的功能都說明完,而且通常也會有完整的教育訓練手冊可以看,所以作為第一次的教育訓練的demo,你可以挑選幾個最常用到的功能介紹。
我自己會選擇我最喜歡的幾個功能,總是有一些功能讓你覺得「wow!」的,不管別人覺得如何,當你自己覺得「wow!」的時候,你介紹起來會格外的閃閃發光。
你的態度影響了他人的態度,當你覺得很快樂的在介紹時,也會提高他人對於這個系統的信心。
為了避免demo冗長,我會在每一個功能結束後,詢問是否有問題,或是請他們提出還有什麼想要完成的事情,我可以現場demo給他們看。
最後回顧一下我朋友提出的問題:
Q1: 通常這類型的簡報會怎麼結束?
因為是第一次教育訓練,你可以說明預計下次第二次會議的時間,以及在這段時間雙方會做什麼事情,或是需要準備什麼內容來準備下次的會議。
舉例來說,我可能會說
「好的!那這是今天第一次的教育訓練,謝謝大家的參與。 下一次的教育訓練我們預計是8/24,這中間我會跟 Alex 以及 Betty 一起把常見的流程梳理出來,完成第一次系統設定,我稍後會把流程圖範例發給各位。下次開會的時候,我們可以針對流程圖來做優化,也會帶著各位一起了解進階報表,到時候再請行銷部相關同仁一起參加,這點再請 Cathy 一起幫忙確認參與人員。」
Q2: 我怎麼知道哪些名詞是這個產業的專有名詞、哪些是這個系統創造出來的?
最快的方法是:問這個產業的朋友,例如你簡報的對象是行銷部,就找2-3個行銷的朋友。
Q3: 說明功能的時候通常是用PPT截圖還是直接在系統使用呢?
因為看著截圖說明很容易發空(開始滑手機),所以我會建議「情境的解說用PPT展現,但是使用方式直接用系統demo」。
Q4:這些功能真的是幫他們解決問題的功能嗎?還是說這家公司其他的系統也可以做到?
這個呢,應該在簽約之前就會被解決(笑),以導入團隊的身分來說,目標是導入成功。而且,一個系統會被導入一定是至少可以解決一個他門現在沒辦法解決的問題才對,因此,如果你需要知道,可以找業務詢問,這也會幫助你在教育訓練的時候更針對問題對症下藥。
最後,跟大家分享一句今天打動我的話(跳tone),也是一年前我在FB上寫給我自己的,臉書跳出回顧時,我自己看了一次,又默默地唸了一次:
You only live once, but if you do it right, once is enough.
from Mae West
▲ blog好閱讀版:https://goldfishblog.tw/top-100-career-questions-31/
▲ 此篇blog的靈感來源是「100個常見的職涯問題」,只要名字與信箱就可以每天第一時間收到我的回覆~
訂閱連結:https://hi.goldfishblog.tw/100-career-questions
#100個最常見的職涯問題 #31
#2020年小金魚的日更200篇挑戰 #DAY70
系統架構圖 定義 在 矽谷輕鬆談 Just Kidding Tech Facebook 的精選貼文
#就地避難在家鍛鍊寫作能力
軟體工程師系統設計面試準備指南
當你有了幾年的工作經驗以後,在找工作時一定會遇到系統設計的面試,有鑒於大部分的面試心得都是針對演算法以及資料結構的程式面試 (包括我之前寫的美國軟體工程師求職心得),對於系統設計的準備資源還真的不多,本篇要來剖析系統設計面試,介紹面試的流程、正確的心態以及準備的方向,讓大家再也不怕系統設計面試!
Medium 好讀版:https://medium.com/jktech/%E8%BB%9F%E9%AB%94%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E6%BA%96%E5%82%99%E6%8C%87%E5%8D%97-acf6ab1f502f?source=friends_link&sk=ca40acf60b749cb1b32c17a868b0c1a3
#為什麼系統設計很重要?
在程式面試表現優異,可以讓你順利拿到 Offer;但是系統設計會決定你加入公司的職等!這也就是為什麼有些人有十年經驗只能拿到 Mid-Level (L4) 的 Offer,而有些人只有五年經驗卻可以拿到資深工程師以上 (L5+) 的 Offer。
另外,如果你是面試 Staff 或是 Principal 級別以上的話,除了系統設計以外,有些公司還會有 Technical Leadership 的面試,來判斷你是否有能力可以跟不同的部門合作、解決問題的不確定性、帶領資淺的人然後推動並且完成一個跨部門的大型技術專案。
簡單來說,系統設計用來判斷你是 L4 或是 L5+,Technical Leadership 面試用來判斷是 L5 或是 L6+。
#為什麼系統設計很難準備?
大多數應徵者在準備的時候會過度偏重於程式面試,原因也不難理解,程式問題的定義很清楚,有給定的輸入以及預期的輸出,就算你真的想不出來,LeetCode 上的討論區也有參考答案;這種有考古題可以參考的面試,對於台灣教育出來的人來說相對好準備,隨著你解的問題多了,你也會更有信心,不知不覺甚至還會刷上癮了呢!但系統設計卻非如此。
系統設計面試的問題描述通常很模糊 (這是刻意的),沒有給定的輸入與輸出,比較沒有既定規則可以遵循,然後也沒有一個標準答案,針對不同系統你需要提出不同的解法然後分析優缺點,一樣的問題,面試官也會針對你過去經驗往不同的方向問,有些問題你工作上沒有碰過還真的回答不出來,這也就是為什麼很多人看到系統面試就怕了。
#到底要怎麼準備?
首先我們要先建立一個觀念:沒有任何一個人可以知道所有的技術細節
不管你的面試官有多少年經驗,不管他們再怎麼資深,在變化快速的軟體產業,沒有人可以知道所有事情,一定有你知道而他們沒聽過的事情!
請把系統設計當成分享你過去所學的面試,這個面試的目的在於展示你對於軟體架構能力的廣度跟深度,你必須可以給出大方向的架構,知道有哪些元件 (廣度),同時針對你熟悉的領域深入探討更多細節 (深度),並且提出幾個解決方案,分析優缺點,並且針對系統需求選擇合適的解法。
大方承認自己對某些領域的細節不熟,也是完全沒問題的,只要讓面試官了解你知道這個東西,如果要深入了解的話你知道有哪些方向要努力,這樣就夠了,因為在大型的軟體專案裡,一定是高度分工的,不會有人同時精通手機端、前端、後端、Infra 以及嵌入式或是硬體的。
講到這裡,相信你也知道如果真的要準備是準備不完的,這些知識是透過平常工作以及閱讀技術文章長期累積的成果,比較沒辦法臨時抱佛腳。
#具體來說會問什麼問題
舉例來說,一個系統設計的問題會像是這樣:如何設計 Facebook?
這類問題的描述通常會很大而且模糊,面試官不預期而且你也不可能在 45 分鐘內就設計出這些公司花了好幾年這麼多人力設計出來的產品,所以第一步要做的事情是確認需求:是要設計動態牆、Messenger、廣告系統還是推薦系統?流量跟資料量為多少?需要支援全球的使用者嗎?
確認完需求以後,會針對最重要的幾個使用場景設計你的 Data model 以及 API,接著畫出大的系統架構圖,大致上會包含客戶端 (手機版/桌面版)、Load Balancer (Reverse Proxy)、App Servers 以及資料庫,接著可以針對細節下去討論,這邊開始就很自由了。
如果你是專精在資料庫,可以討論要用什麼資料庫以及資料要怎麼存可以讓特定使用場景的讀取以及寫入效能比較好,要怎麼做資料庫的 Replication 跟 Sharding 來服務更多的使用者?
如果講到快取,哪些地方可以加快取呢 (瀏覽器前端, CDN, App Server, 資料庫)?具體來說寫入快取有哪些方式以及優缺點 (write-through, write-around, write-back)?什麼時候要失效?要讓哪些資料失效?
如果聊到微服務器架構跟 Service Mesh,不同的服務怎麼跟其他的服務溝通? control plane 要怎麼更新 data plane 的設定?如果 control plane 掛了怎麼辦?要怎麼做 service discovery? 哪一種 Load Balancing 策略比較好 (round robin, random, least connection, ring hash, or maglev)?有些服務掛了影響到整個系統怎麼辦?什麼時候需要 circuit breaker ?
如果你是手機開發者,怎麼實現離線瀏覽?手機要有資料庫嗎?要怎麼以及多常跟伺服器同步?API 要怎麼設計?如何實現 Infinite Loading?剛 Po 文以後要怎麼樣在自己手機上馬上看到?
這些問題真的列舉不完,總之看到這裡你會了解為什麼我說這個面試是沒有範圍而且也準備不完的,重點應該放在跟面試官的討論,展現你在技術方面的廣度跟深度,讓面試結束的時候能夠有一個你們兩個人都同意的設計!
#準備材料
系統設計的資源比較分散,以下是我篩選過後覺得有用的資料,按照素材的類型作分類,也歡迎大家留言補充!
#入門影片
針對完全沒有概念的新手,我建議可以先從哈佛的 CS75 Lecture 9 Scalability 開始,裡面講到的很多基礎觀念都相當重要,值得一再複習,這些概念先有了以後再閱讀其他的材料會比較有感覺:
如果你看完這篇文章後還想再多了解系統面試的形式,也可以看一個前 Facebook 工程師分享的影片:
Distributed Systems in One Lesson 也很推,裡面提到不少業界在使用的設計模式:
有一個需要付費的資源是 SystemsExpert,每個影片會講解一個系統設計重要的概念,我個人覺得內容有點淺所以沒有買,但是整理地還算不錯,如果你看完他們免費的影片有興趣還是可以參考一下。
#閱讀文章
影片是一個讓你很好理解大方向概念的方式,但是如果你要深入理解背後的原理還有怎麼運作的細節,還是得透過大量以及深度的閱讀來吸收呀!
system design primer 整理了很多系統設計的資源,資料量很夠, 個人的建議是先快速過一遍,不要細讀,先知道總共有哪些元件,大概是做什麼用的就好,接著針對有興趣的部分在深入研究,建立自己的知識庫。
Grokking the System Design Interview 也是很多人推薦的材料,主要是針對系統設計的問題提供範例解答,他們的答案可以當作一個參考,但面試的時候不要完全照著回答,還是得看跟面試官討論的結果來進行,但這個是需要付費的,有興趣可以用我的推薦碼註冊購買。
如果你不想花錢或是不確定 Grokking 的文章你喜不喜歡,有一個類似的網站 Crack the System Design Interview 整理得也還不錯。
#書籍
唸書是一個有系統性學習的方法,如果你只想選一本書來看,就選這本大家都推的系統設計聖經 — Designing Data-Intensive Applications,簡稱 DDIA,這本書適合的對象是想要長期準備系統設計或是分散式系統的人,裡面舉的例子都是實際上業界遇到的問題,不會有以前讀教科書那種工作又用不到的感覺;但也因為是書,花了一些篇幅在講解背景知識,包含以前的系統是怎麼設計的以及如何演進到現在,對短期要準備面試的人效率會有點低,所以不適合有時間壓力的人。
這本書我目前讀了一半,最大的收獲是它解釋了很多為什麼現代的系統要做這樣的設計,我們針對不同的系統要求可以有哪些解法,這些解法各有什麼優缺點,總之分散式系統就是我們解決了一個問題,但又會產生更多要考量的點,一切都是 trade-off。
但這本書也不是沒有缺點的,首先我覺得是本書的英文沒有很好讀,我常常一段看了好幾遍才知道他想表達的重點是什麼,而且,有些很重要的觀念常常藏在一段文字裡用一句話帶過,但是不太重要的觀念卻使用 Bullet Point 表達;另外這本書話常常講一半,一些觀念提到了一點卻說我們後面再聊,也因為這樣,我在考慮要不要幫大家整理每一個章節的重點,翻成中文分享給大家,有興趣的朋友麻煩拍手留言告訴我!
除此之外,Google 的 SRE Books 內容也很實在,但是每一個章節的內容是獨立的,建議大家選擇想研究的章節跳著看就好。
最後,Distributed systems for fun and profit 的內容也很好,以分散式系統的理論為主,比較沒那麼針對系統設計面試。
#還想閱讀更多嗎?
我知道光是上面的資源就已經讀不完了,但是行有餘力的話,平時也可以多看看各大公司的技術部落格或是訂閱技術週刊如 TechBridge (台灣) 、HackerNews 以及 InfoQ 等等。
此外,參考別人的經驗也是很好的方式,最近剛好幾個朋友剛找完工作,他們分享的矽谷找資深工程師工作心得分享以及2020 上半年軟工找工經驗分享也都很值得看!
最後,在工作上使用到的技術,除了會用以外,最好也要花時間去研讀技術文件,了解他們設計的考量以及支援的場景,大部分這類型針對開發者的文件寫得會比較深入,所以也是相當好的學習素材;我自己過去一年因為工作上需要整合 Envoy 到我們公司的 Traffic Infrastructure,從他們的文件中學到很多 Service Mesh 跟微服務器的重要概念,學習的深度都是其他資源無法提供的。
#總結
這篇文章我們整理了很豐富的系統設計資源,希望大家不要被這滿滿的資訊量嚇跑。
請記得,我們永遠有各種方法在短期內針對面試做準備,提升面試的表現,但這都只是一時的,沒辦法讓你一夕之間就成為專家;如果想要追求長期的持續成長,那麼沒有捷徑 — 就是養成每天學習以及閱讀的習慣,一開始真的很難看到效果,但是當你持續一週、一個月甚至是一年以後,你會明顯感受到自己的成長,這些投入的時間都是騙不了人的。
如果這篇文章對你有幫助,請拍手留言加訂閱,並且分享給更多有需要的人知道!