從0到1攻克商業分析師面試大魔王-SQL Assessment
前言
今天這篇文章再次重訪一個在過往文章裡面反覆提及、也是很多在美國的商業分析研究生的求職者都聽聞過、但可能不知道如何準備和進行有系統和這個面試環節：SQL Online Assessment！如同我在前面眾多文章都有多少帶到的，SQL Assessment基本上是商業分析師面試的標準配備了，多數存在於人資後的一關、用人主管的前一關；甚至有些是得先通過SQL Assessment，才能得以和人資通到電話，展開接下來的流程。
今天的文章，我會更全面的分享從頭到尾在每一個環節準備、攻略SQL Assessment的秘訣，會融合我過去面試的經驗和最近面試別人的過程。在閱讀本文前，也歡迎閱讀我之前兩篇和SQL面試有關的文章，做一個360度的熟悉。
我在這篇文章裡面會淡化語法的教學，畢竟之前已經有一篇文章在講語法，而我更多會碰觸到的是準備上、磨練技巧、面試當下的心法，讓讀者閱畢這篇文章可以更了解面試中的應對進退，成為一個更成熟圓融的SQL Test Taker，也避開一些我之前走過的面試坑。
適合讀者
準備進行海外(亞洲、美國)的商業分析、資料科學的求職者、對於準備SQL Online Assessment有困惑和不知道怎麼全面提升技能的在學生、待業人士、即將來美國攻讀分析應用學程的學生等。
本文架構
1. 提升SQL技術
2. 接到面試後的準備
3. 面試當下心法密技
4. 結束面試後別忘記範疇
我會以一對一面試，有面試官帶領SQL Online Assessment的線上線下面試為主要標的。本篇分享的技巧和心態可以適用面試前期的線上評測和最後一關時候可能的白板題型。
一、 如何準備和提升SQL技術
關於如何在真正進入求職季，一個沒有SQL語言經驗或是熟練資料庫語言者、或是你是一個商業分析研究所新生，而苦於不知道怎麼提升SQL硬實力，我會建議三個步驟打磨你的SQL技能：地毯式學習、刷題、商業資料實戰。
SQL困難的地方在於，如果你沒有在真實的職場實習或正職經驗過，在一個研究所學程裡面，即使有三學分的資料庫語言課程，不管老師的教學多麼扎實，你還是會覺得搔不到癢處，也不要對於你上完一堂三學分的資料庫語言課程，就對求職時的SQL測驗能駕輕就熟的錯誤期待。以下就上文提到的三步驟進行分享。
🔑地毯式學習
儘管說三學分的資料庫語言課程有所不足，但你仍然要認真的聽課和完成作業，老師的學習、指定教科書可以協助打底。建議還是要時時複習、詳讀指定教科書，從頭到尾建構你的資料庫概念：從最一開始創建一個表格，表格的要件是甚麼 (Primary Key、Foreign Key、DDL、DML、DCL等等)，到基本的語法之間的差異(where vs having)等等，相信這些基礎在任何一堂三學分的課程與任一的資料庫語言教科書都會完整涵蓋。
在透過學習打底的過程中，我也強烈建議同時搭配線上學習網站的互動式介面進行複習。SQL困難的地方在於你比較難真正在學術環境裡面真正擁有一個資料庫去操作和見證你的Query會跑出甚麼樣的結果，因此附有IDE和互動式介面的網路課程可以補足這一點，和你的學習相輔相成。
我強烈推薦從Codecademy開始 ，將Intermediate Course完成，再來做DataCamp所有的SQL課程 ，做完這些線上教育平台的所有課程後，相信你已經可以基本上把教科書上較為生硬的理論與Query跑出來的結果互相結合了，並且走向實務之路。
🔑刷題
我相信刷題就不用我多說了！Leetcode、Hackerrank都是非常好的選擇，我會建議在開始正式求職之際，以每天三到五題的量開始練習，培養語法的敏銳度也從刷題的過程裡面知道自己哪些部分的技巧是較為欠缺的！
很多人會問我說，如果想要能通過一些科技大廠的面試，刷題大概要刷到甚麼樣的程度。我會說：刷到「Difficult」，建議的路徑是先從Leetcode、HackerRank的簡單開始刷，刷完再刷兩個網站的中級，刷完中級在刷兩個網站的困難級，不要抱著僥倖認為刷到中級就可以，大家都是在求職，努力推自己的底線和極限絕對是百利而無一害的！
我也會建議重複刷題，刷完一輪，如果可以可以在挑一些你在過程裡面有卡頓的題目再重複進行撰寫，有兩個好處。
第一：可以重新檢查自己有沒有進步。
第二：在往後SQL Assessment中，很多面試官會希望面試者能出「有效率」、「簡潔」、「可規模化」的語法，透過重複刷同樣的題目，你可以訓練自己的思維，去找出更優化、更簡潔的寫法。尤其Leetcode、Hacker Rank都有單題排名的機制，你可以透過撰寫不同的寫法、甚至你也可以單純上網找答案複製貼上，慢慢掌握和培養一個語感：原來A寫法和B寫法在解C類型的題目，A是比較有效率的，這時候就可以累積如此的肌肉記憶，以後碰到C類型的題目，可以優先從腦中的記憶庫裡面，淘選出A解法。
🔑商業資料實戰
在經過步驟一和步驟二的橋接：分別是教科書嫁接到實地Query，實地Query到刷題挑戰，很多人其實在第二步驟往往就停了，但往往會忽略最後一個步驟，商業實戰的過渡，而這往往也是最困難達到的！
Leetcode和HackerRank最主要的問題就是往往題目過度斟酌於技法的磨練，以至於題目過於刁鑽和冷門，進入到職場之後會發現，很多刷題網站測試到技法，根本不會用到，有時候你想破頭得到一個解法，可能根本不是商界人士會使用的；而且刷題網站提供的表格和資料往往不符合現在的商業語境，例如人口資料、氣象站資料、班級成績的樣本，對於練習有益，但基本上零商業價值。這些差異如果面試者沒有意識到，往往會在你第一次SQL Assessment給你打擊，就像你很會推導公式和進行繁複的數學運算，但你碰到月考應用題的時候，卻不知道如何解決。
要如何和商業領域的資料進行掛勾呢？最好的方式即是找跟你關係良好的學長姊進行對練 (可見networking的重要)，由於學長姊已經在公司工作，他們手邊一定會有很多日常查詢的表格、他們會處理的問題、甚至是他們協助面試時候的一些些考古題，他們也絕對有能力將這些題目進行轉換，變成一道道經典的考題考驗你、讓你撰寫。
找人對練的好處多多，包括：讓你可以從刷題的語境中跳脫出來，正式跨足用SQL解決商業問題的領域 (營收估算、留存率、使用者多寡等等)；訓練你盲寫 (即有別於Leetcode/HackerRank可以回傳結果，沒有辦法執行查詢驗證你所寫的流程 — 白板題)；累積你和考官互動的能力等等。
當你有這樣的對練經驗之後，你就可以正式走入面試了！
二、 接到面試的各種準備
當你已經完成學習SQL的各種嫁接，而你的面試邀請如雪片飛來之際 (hopefully)，你在正式面試到來那一天，你可以做甚麼準備呢？以下有三個訣竅可以讓你在面試當天更得心應手。
🔑一畝三分地是你的好朋友
當你接到某公司的分析師職位面試的時候，第一件要做的事情絕對是上一畝三分地查找面經，不管你有沒有足夠權限或是購買頂級會員，或多或少可以看到前人們面試時候的Table Name、試題等等。
能了解到表格和題目的類型至關重要，雖然碰到相同表格、題目的機率小之又小，但閱讀這些面試經驗，對於你準備面試的好處是，它再一次協助你完成從線上刷題領域到商業實戰的嫁接。
範例一: 社群網站考題
SQL Table: DATE|ORDER_ID|SENDR|TIMESTAMP , sender = 1: seller ; sender = 0: buyer
Q1: How many orders have message from buyer on date xxxx範例二: 社群平台考題
SQL Table: RESTAURANT | TRIP | RATING 3 TABLES
Q1: Restaurant orders count...
舉例來說，上面的兩個面經一個是某社群媒體的考題、一個是某送貨平台的考題，我在沒有登入一畝三分地的狀態下看到是不全面的，但透過這些完整、半完整、不完整的資訊，在完整資訊下你可以提前練習、在不完整的資訊下，你還是可以一窺大概某公司的某些組別常用的Table、可能的潛在問題為何，面經可以協助你聚焦，往下一步前進。
🔑自己出題考自己
當你有了這些歷史面試資料時，你可以額外做下一步準備就是：想像該公司有的表格，並且進而出題考自己，在這個商業實戰的階段裡面，你要做的事情就是把自己想像成是你即將面試公式的分析師、資料科學家甚至是面試官，出題給自己 (作為一個面試者)。透過自問自答，面試者努力窮盡各種面試問題大全、不錯過任何各種難易度的問題，到時候如果面試真的碰上這些表格，你也已經把題目八九不離十的「猜題完畢」！
就以上面某社群平台的表格舉例吧！這個表格應該是跟電商有關功能的資料。有日期、訂單ID、訂單的送件者(買賣雙方)、時間。
透過不全的問題集裡面，感覺很多是和訂單數有關係的。那身為面試者可以以此開始延伸。
1. 想想有沒有其他的表格：比如說使用者的表格 (可能會有國家、使用者ID、載具、性別)、比如說訂單量的表格 (訂單價格、訂單數量)、比如說訂單貨品的表格 (產品ID、產品敘述、產品類別)
2. 開始想想面試官會問你甚麼題目：比如說每周是哪一天訂單量最大？平均來說一個訂單傳訊息的使用者是賣家比較多還是買家比較多？單月的總收益是多少？不同載具在不同國家的收益、訂單數量是多少等
有了這些你想像出的表格欄位和問題之後，你就可以開始自答，在word doc、Google doc上開始撰寫你覺得合理的query答案了！並且在寫出答案後，自問說，你寫的答案可不可以更進一步優化。而無形之中，你透過如此「想像表格」、「自我出題」、「自我回答」、「自我優化查詢Query」的過程更加熟習你即將到來面試可能出現的題型情境了！
🔑熟悉平台
把該面試公司的潛在表格都熟悉數遍之後，別忘記也要熟悉之後會在面試中使用的Coding平台。基本上在面試前，人資都會在邀請信中提附帶平台連結或是平台指引。別忘了在面試前花個十五分鐘到半小時上去熟悉一下介面。
有些公司是用Hacker Rank這種刷題網站當作企業面試方案；更多的是無法真正執行Query、只能寫Pseudo code的平台 (如Google Doc、Code Pad、Hacker Earth等等)，也會有一些是可以讓你執行代碼的雲端平台 (如GCP的Big Query或是其他雲端的解決方案)，但不管是甚麼，作為一個面試者都應該提前熟悉工具，以免面試當下措手不及。
三、 面試當下的心法秘笈
當你緊張的準備迎來第一次的SQL Assessment面試，你和考官自我介紹完 (甚至很多根本不給你自介、直接一上來就進入測試)，以下的心法供你參考，讓你可以在SQL水平一定的程度之下，更好、更順利的攻下一個個的測驗！
🔑提前打開平台連結、面試時間分分鐘寶貴
在面試前，建議面試者提前打開要撰寫SQL測驗的平台連結，不要讓面試官提醒與等待。通常SQL測驗的時間45分鐘到一小時不等，如果扣除面試官自我介紹、面試者自我介紹、最後提問的時間，可能最後聚焦在考題的部分可能只剩下40–45分鐘，同時也要考量面試者面試緊張時出錯的時間，其實能走完面試官預定題目組數的面試者少之又少。
如果一個面試者能在給定時間內有效率又快速的回答盡可能多道題目，通過的機率越高。所以一定要把握時間，不要浪費時間在找連結、打開平台、等待。雖然只是一件小事，但提前準備可以確保你有個平順、處變不驚的開場。
🔑表格Table釐清與提問 (四點注意)
在真正進入撰寫查詢語法前，面試官通常會在測驗平台上放入若干個表格這些表格，這些表格將會是待會進入到題目後你使用存查的資料來源。以下提供一些方向和技法，讓你目光在掃過這些表格時可以同步準備和進行的！
1) 提問不清楚、待釐清的欄位和確認欄位的資料格式
每個欄位(column)都蘊含著該公司在存儲資料、分析資料的領域知識，面試官也不會預設你所有都理解，所以透過詢問，可以比面試者瞎猜還要有效率。例如網站資料session ID、visit ID、user ID、customer ID、page ID可能代表不同的含意；product ID、order ID的意涵是甚麼；透過詢問，也可以知道不同欄位之間的從屬關係：例如一個order ID可能是涵蓋多個Product ID或是一個order只能有一個product ID，這些都是隨著商業種類的不同而會有所差異。
另外一個重點是資料格式，這往往也會在答題時造成答案的差異。比如說國家的欄位是用數字表示還是字串表示；ID是有涵蓋字串還是純整數；如果是布林格式，True代表甚麼、False代表甚麼？這些都要在檢視表格之際，內心有一個底。
2) 確認Primary Key、Foreign Key、最小單位
透過掃視表格之際確認這兩種Keys，並且在內心有所定見是可以一定程度加速你撰寫答案的過程。Primary Key在邏輯上通常會是一個表格的最小單位，他是不會重複的，會是一個Unique Identifier。比如說Order table裡面，Primary Key會是一個Order Item ID (1,2,3,4,…..)，但order item ID 1,2,3,4可能是同一筆order (擁有同樣的order ID)，但1,2,3,4不同的是同一個order ID裡面有四項商品的product ID。因此辨別Primary Key和Non-Primary Key就可以知道說，如果要進行Order ID的計算，就得加上「Distinct」進行去重複。
而辨別Foreign Key的目的則是在串聯表格的時候可以用上 (JOIN)，要注意的事情是，在接下來答題的過程裡面，Foreign Key不一定是只有ID，很多面試者會忽略ID之外的Foreign Key，比如說國家、市場、日期等等。比如說在Product Table裡面，可能一個商品在日本、在美國有相同的Product ID (因為同時在這兩個國家販賣)，所以在連結可能Order Table的時候，不只要使用Product ID，也要使用國家進行聯集！
3) 確認哪些表格是Dimension Table、哪些表格是Metric Table
通常在測驗中會出現的表格，會分成以上兩類。Dimension Table (維度表格)是指不包含數字的，比如說Customer Table，只有customer ID、customer name、gender、location等等，它含有的資訊是維度資訊，就第一反映是面試者無法用類型的表格計算數字；Metric Table (指標表格) 是指包含數字的，比如說Sales Table，有sales price、sale quantity (可以用來計算收入)、比如說Page view Table，有該網頁連結、瀏覽數、曝光數、點擊等等。
確認Dimension vs Metrics的好處是：百分之九十以上的題目，都會是聯集(JOIN)Dimension Table和Metrics Table進行求解。透過這個環節的確認，可以更快掌握解題時候的邏輯。另外也要注意有一些表格本身是Dimension Table，但透過某些轉換它也可以是Metric Table，比如說訂單表格(Order Item ID/Order ID/Product ID)，面試官可能也會詢問訂單數 > COUNT(DISTINCT ORDER ID)，訂單商品數 > Order ID, COUNT(DISTINCT Product ID) 等等的題目，透過計數、平均等將維度轉換成指標。
4) 確認表格的上下階層
透過確認表格的上下階層對於後續的作答也會很有助益。在串聯表格的過程裡面，通常會遵循由大到小、由小到大的關係。
比如說如果考題是考有關使用者在網站上的路徑，表格的標準配置通常是Visit、Page、User，那串聯的過程基本上沿著這幾個維度的包含關係出發。一個使用者會有很多Visit(訪次)、一個訪次裡面會有很多的瀏覽頁面(Page View)，因此要進行表格串聯時，可以以USER JOIN VISIT JOIN PAGE或者PAGE JOIN VISIT JOIN USER進行思索、執行合理的連結。
而這些上下階層的確認，除了是靠平常商業領域知識的累積、前期面經的準備，當然也是可以和主考官確認而來。
🔑開始撰寫查詢語法(Write queries)的心法 (四大心法)
和主考官確認、自己審視完表格後，主考官就會逐一貼上問題，讓你開始作答。以下提供幾項心法與訣竅，讓你可以有條不紊、效率快速的寫出答案。
1) 讀懂題目、與主考官確認思路
這一步是至關重要的，絕對不要在沒有讀題目之前，直接開寫；也不要在沒有和主考官確認完思路正確性，直接進入Query撰寫。
讀每個題目都要找到三個要件：維度(Dimension)、指標(Metrics)、條件(Condition)，這三個要件對應一個典型Query的三部分為：維度對應Non Aggregated Columns；指標對應Aggregated Columns (ex SUM/AVG/COUNT/MIN/MAX)；條件對應WHERE Statement。
以下我就來舉一個例子：Write a query to get the total monthly revenue for different devices in US and EU for Q1 and Q2 2018.
這邊的維度就是SELECT STATEMENT裡面的Device (載具)、country (國家)、月份 (Month)。
這邊的指標就是SELECT STATEMENT裡面的SUM(revenue)，所以你就得用group by function。
這邊的條件就是 1) 限制國家 (US, EU的國家)、日期 (Q1-Q2 2018)。
因此確認完這三個要件之後，一個粗略的答案雛形就能應運而生：
SELECT device, country, month, sum(revenue)
FROM TABLE1
JOIN TABLE2
JOIN TABLE3 …
WHERE country in (US, UK, DE, FR, …….)
AND DATE BETWEEN ‘2018/01/01’ AND ‘2020/06/30’
GROUP BY 1,2,3以上例子，想必你就會知道讀懂題目有多麼重要了吧！清楚的知道題目要甚麼和劃出三要件的切分，可以幫助你在作答的時候不會有任何疏漏。
而三要件的羅列也是和主考官確認思路很好的邏輯之一，說法可以如下：「透過題目我知道我要在表格一表格二(…)選取載具、國家和月份，並且用Group by這三個欄位去計算營收，並篩選國家和期間，請問我這樣的思路是對的嗎？」而當主考官認可後，就可以開始撰寫了！
2) 大原則：永遠從指標(Metrics)表格開始查詢
這是我建議培養起的好習慣。當你確認指標後，永遠把存有該指標的表格首要放在FROM之後，然後在LEFT JOIN/INNER JOIN剩下的維度表格。這個心法的真諦在於，指標表格通常是最小單位，由最小單位的階層往越大的聯結，相對直觀且不會出錯。
範例如下：
SELECT columnA, columnB, columnC
FROM metric_table
LEFT JOIN dimension_table
LEFT JOIN dimension_table
WHERE ...
GROUP BY ...3) 掌握撰寫的順序
撰寫的順序每個人習慣不同，在此提供兩個我比較推薦且比較多人使用的流程。
第一，從FROM和JOIN開始：這個做法是答題者先確認好哪些表格是答題必須，先從表格進行串聯。把表格串聯完成後，在寫SELECT STATEMENT。這樣的好處是主考官會知道你的資料源處理是否正確，通常會給你一個示意，讓你修正或繼續。
第二，從SELECT開始寫：有些人則是習慣先把要輸出的欄位先寫出來，然後再找這些欄位是存在於哪些表格，再進行表格的串聯。這樣的好處是答題者可以先把理想中的結果寫出來，創造一個如燈塔的效果，接下來按圖索驥把中間的路徑走完。
4) 邊寫邊read out loud
這點我在之前的文章也強調很多次，在撰寫答案的時候，別忘記時時透過念出自己的思緒，邀請面試官進入的答題環節。不要低頭猛寫、不出聲，透過將面試官參與撰寫的環節，很多時候可以少走很多冤枉路。
5) 邊寫邊想備案
這件事情比較難做，不一定在撰寫每一題時都一定要達成。當你有一個明確思路跟八九不離十的解法時，在將答案逐步寫出之際，也可以撥出一部分的精力，同步思索：有沒有另外的解法、有沒有更有效率的查詢方法。提前先想的好處當然是避免在你迅速寫完之際，面試官的追問。先想總比措手不及還要好的！
🔑結束撰寫查詢語法之後 (兩點注意)
在你寫完每道題目之後，並不是寫完就好，額外做以下的步驟可以讓你與其他面試者更脫穎而出。
1) 注意follow up question、考官提示、準備優化
在完成題目後，考官通常不會讓面試者就白白結束，很多時候會進行追問或提示。這些內容包含但不限於：請你解釋你的流程作法(walk me through your logic)、提示你哪些沒有注意到的點或是小錯誤，並且請你調整Query、詢問你有沒有考慮到某些特殊請況，你的答案能不能捕捉到這樣的特殊情況、有沒有第二種寫法等等。
這種時候不用心急，只需要冷靜的一一回答面試官的問題，並且仔細聆聽，在這樣的環節更多的是與面試官的互動，面試官希望透過這個事後的提問，更加知道你是不是一個思想全面、反應迅速的分析師，並且可以接受反饋、修正錯誤。
2) 詮釋結果
如果你的測驗是可以跑出結果的(如使用互動式的IDE，可以真實的查詢到數據)，在答案輸出後，記得花一些時間看看結果，並且主動提出數據結果的詮釋。可能是使用者的行為、不同期間數據高低的推測、進一步的研究方向等等。如同第一點所表達的，透過詮釋的過程，也是展現你是否為一名好的分析師的資質。
四、結束面試
在你結束一小時後的SQL測驗後，最重要的一件小事即為把你這一小時的經驗變成你珍貴的資料庫。不管是你儲存/螢幕截圖/下載下來面試的表格、問題，這些題目都是你更接近商業世界的敲門磚，將其分門別類。
如果答的不好、沒有全部答完題目，記得在面試後花時間將題目想過，試著重新撰寫查詢指令、力求正確，不再同樣、類似的問題摔第二次跤。
而分類的好處則是未來面同樣產業領域的公司，這些題庫都可以派上用場。臉書的題目可以關聯到Twitter、Linkedin；DoorDash的題目對於Uber Eat、Grubhub；Amazon的題目對於Ebay、Wayfair等電商平台大同小異。
基本上SQL測驗準備也是一個不斷迭代的過程，隨著你每次面試經驗的累積，你的資料庫和實力會益發厚實，讓你更加得心應手。
小結
希望這篇無比完整的指南可以讓讀者在成為商業分析的路途上，面對SQL Assessment的大魔王之際能不再害怕、不斷前進，你有甚麼功克SQL的小訣竅嗎？歡迎留言分享！
