在這個問題中，我們必須使用來自兩個表的數(shù)據(jù)：表customers和表orders。我們可以編寫一個帶有子查詢的代碼來克服這個問題。但是，您可能知道，如果查詢和子查詢使用來自多個表的數(shù)據(jù)，那么也可以使用聯(lián)接編寫解決方案。記住了編寫盡可能少的代碼行的建議，最好使用join。

這個解決方案的假設是什么？一種假設是，可能有客戶沒有訂單。這意味著表customers中的客戶可能不會出現(xiàn)在表Orders中。第二個假設是，我們不會顯示零訂單的客戶，因為問題沒有明確地說。

現(xiàn)在，這已經導致我們解決方案崩潰。我們必須輸出兩個已經存在的列，所以我們一定要使用SELECT。我們需要找到每個客戶訂單的總數(shù)。我們必須使用sum（）聚合函數(shù)對其求和。好的，桌子必須連接起來。我們將使用JOIN關鍵字來實現(xiàn)這一點。為什么不讓其他人加入呢？因為我們的假設是，我們只想要至少有一個訂單的客戶。使用JOIN將給我們提供這樣的結果：它將連接兩個表，并且只查找兩個表中的值（客戶）。接下來呢？我已經使用了聚合函數(shù)，所以我必須使用GROUP by。結果必須按字母順序排列，所以我將使用ORDER BY和ASC。

由此產生的解決方案分解可能如下所示：

• 選擇
• 總和(total_order_coste)
• 加入
• 按分組
• ASC命令

在您的情況下，這并不是緊急情況，因為您理解了所有內容，所以您可以進入下一個檢查列表部分，或者您也可以在這里找到最多的commonSQL JOIN面試問題。

3.編寫代碼

在評估了問題并為代碼制定了策略之后，是時候開始編寫它了。

1. 堅持一種選定的方言
2. 編碼時逐行進行
3. 邊編碼邊說話
4. 使其具有可讀性
5. 與選定的慣例一致

i。堅持所選方言

如果您參加SQL編碼面試，這一點尤其重要。正如您已經知道的，有一個ANSI/ISO SQL標準，并且有許多SQL方言。實際上，每個RDBMS都使用自己的SQL方言。當然，你不可能都知道。你面試的公司可能使用的是其中一種方言。

如果面試官不在乎你使用哪種方言，那就選擇你最喜歡的一種。如果你不是很擅長用SQL方言編碼，不要試圖通過選擇他們使用的SQL方言來吸引面試官。最好選擇你最熟悉的方言來解決問題，而不是使用其他一些你不太確定的方言。如果你選擇后一種，你可能會比必要的更緊張。此外，不熟悉特定的SQL方言可能會使您搞砸解決方案。

一旦選擇了SQL方言，請堅持使用。例如，如果您選擇用PostgreSQL編寫，不要將其與T-SQL混在一起。

ii。逐行進行

有一個明確的解決方案分解將幫助您檢查這一點幾乎沒有注意到。由于您已經概述了代碼的功能和部分，您只需要保持冷靜，按照解決方案大綱系統(tǒng)地編寫代碼。代碼只不過是你思想的編程語言版本。如果你的想法和你的解決方案大綱是清晰的，你的代碼也將是清晰的。

如果你開始從一行跳到另一行，你會讓自己和面試官感到困惑。這可能會導致不能編寫正確的代碼。

iii。邊編碼邊說話

當您一行一行地編寫代碼時，您還應該談論您正在做什么。這很重要，因為當大聲說出你在做什么時，你更容易看出你是否做錯了什么。一切在你的腦海里聽起來都很棒。但是當你大聲說出來的時候，那些不太好的想法真的很突出！這使您有機會在執(zhí)行過程中更正代碼。否則，您可以完成代碼，甚至沒有意識到您做錯了什么。

為什么在你寫的時候解釋每一行都很重要，原因之一是它再次邀請面試官參與你的解決方案。這讓他們有可能理解你在做什么，并給你一些提示。如果你只是寫了一個代碼，并對自己在做什么保持沉默，面試官也可能會停下來，只是等你完成代碼，讓你知道你做得如何。

iv。使其具有可讀性

簡單地從美學的角度來看，擁有一個結構良好的代碼是一種樂趣。不僅如此，它還使您和面試官更容易閱讀您的代碼。

使您的代碼具有可讀性的主要因素在上面的一個要點中提到：盡可能簡單地編寫代碼。然而，有些解決方案不能簡單。如果您不努力使其具有可讀性，那么即使是幾行代碼讀起來也可能是一場噩夢。

要記住的一個技巧是使用空格、制表符和Enter。并且經常使用它！這些鍵可以將代碼分成幾個部分，從而更容易理解代碼的功能。把它想象成你說的或寫的任何東西?？崭瘛⒅票矸蚭nter將使代碼具有逗號、句子和段落。

如果可能，請為表使用別名。但試著讓它們變得不言自明。避免使用單個字母的別名，但也不要使別名過于冗長和描述性。變量名也是如此。

雖然SQL不區(qū)分大小寫，但最好用大寫來編寫SQL關鍵字。這也會使它們在代碼中突出，特別是如果所有列和表名都是小寫的。

查看我們的文章“編寫SQL查詢的最佳實踐：如何構造您的代碼”，它關注如何改進SQL查詢，特別是在性能和可讀性方面。

V。與選定的約定保持一致

沒有規(guī)則讓你寫大小寫；沒有規(guī)定的命名慣例，所以它取決于你和你喜歡它。但無論你做什么，都要與之保持一致。

如果你想用小寫來寫所有的新列名，并用下劃線分隔單詞，請這樣做并保持這種方式。將列命名為salary_per_employee看起來相當不錯。但是盡量避免將一個列命名為salary_per_employee，另一個列命名為SalaryPerDepartment，第三個列命名為“total salary”，第四個列命名為max_salaryperdeparment。當你試圖閱讀代碼時，你會傷害自己，尤其是最后一個代碼。

在編寫表名、使用別名等時也是如此。保持一致性也會增加代碼的可讀性。

談到一致性，我們將向您展示此核對表部分在實踐中是如何工作的。

編寫代碼示例

以下是臉書的一個編碼問題：

“當用戶試圖2FA(2因子身份驗證）進入平臺登錄時，臉書會發(fā)送短信。為了成功2FA，他們必須確認他們收到了SMS短信。確認文本僅在發(fā)送日期有效。不幸的是，數(shù)據(jù)庫中存在一個ETL問題，其中朋友請求和無效的確認記錄被插入到日志中，這些日志存儲在'FB_SMS_SENTS'表中。這些消息類型不應在表中。幸運的是，'fb_confirmers'表包含有效的確認記錄，因此您可以使用該表來識別用戶確認的SMS文本消息。

計算2020年8月4日確認短信短信的百分比?！?

如果您編寫這樣的代碼，它將涵蓋我們在本檢查列表一節(jié)中提到的所有內容：

SELECT  cust_id,
        SUM(total_order_cost) AS revenue
FROM orders
WHERE EXTRACT('MONTH'
              FROM order_date :: TIMESTAMP) = 3
       AND
       EXTRACT('YEAR'
              FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id
ORDER BY revenue DESC

讓我們假設Facebook使用SQL Server，但它讓您自己決定用哪種SQL方言編寫代碼。您不熟悉T-SQL，因此決定使用PostgreSQL編寫。

例如，EXTRACT()和雙冒號（：：）是PostgreSQL的典型函數(shù)。第一個從datetime數(shù)據(jù)類型中提取日期的部分。它不存在于T-SQL中！所以如果你對面試官說你是用T-SQL寫的，然后使用這個函數(shù)，你就犯了一個錯誤。在T-SQL中，應該使用DATEPART（）函數(shù)。您應該知道PostgreSQL中的這個函數(shù)稱為DATE_PART()。一個下劃線可能意味著代碼工作和不工作之間的差異。

類似地，PostgreSQL中的雙冒號（：：）用于數(shù)據(jù)類型轉換。在T-SQL中，它不起作用；您必須使用CAST（）或CONVERT（）。

對于這段代碼有一個解決方案分解將使您很容易一行一行地編寫它。其實很容易。首先，您必須從表中選擇一些數(shù)據(jù)，對其進行篩選、分組，最后對其進行排序。不要先編寫WHERE子句，然后轉到SELECT語句，然后轉到數(shù)據(jù)類型轉換或任何其他處理代碼的奇怪方式。

在編寫代碼時，可以像這樣與面試官交談：我使用SUM（）函數(shù)選擇cust_id列來計算表訂單的收入。然后，我使用WHERE子句根據(jù)ORDER_DATE列中的月份和年份篩選數(shù)據(jù)。之后，我在客戶級別上對數(shù)據(jù)進行分組，并按降序對結果進行排序。

您可以看到這段代碼有縮進，代碼的每個關鍵部分都有一個新行，并且命名約定是一致的。你想看看如果我們不遵循這個代碼會是什么樣子嗎？在這里：

SELECT cust_id,SUM(total_order_cost) AS REVENUE FROM ORDERS WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id order BY Revenue DESC

4.檢查代碼

編寫完代碼后，是時候在它成為最終答案之前對它進行審查了。如果到目前為止您已經遵循了清單上的所有項目，那么您將很容易檢查它。

在某種程度上，檢查代碼就是對照清單上的一些要點檢查代碼：

1. 檢查一下你還剩多少時間
2. 對照所需的輸出進行檢查
3. 對照所述假設進行核對
4. 檢查其可讀性
5. 帶領面試官通過解決方案
6. 優(yōu)化代碼

i。檢查您還剩多少時間

核對表這一部分的所有其他要點都依賴于這一點。如果你沒有時間了，那么你什么都做不了。你做了你所做的，你的代碼就是你得到的答案，不管你喜歡與否。

時間管理很重要，所以您應該有意識地為檢查代碼留出一些時間。理想情況下，您將有時間執(zhí)行以下三個檢查。

ii。對照所需的輸出檢查代碼

您應該回到您的問題，看看您的代碼是否真的返回所需的內容。你是不是忘了包括一些必需的列？你真的按要求訂購了結果嗎？這些和其他類似的問題是你應該問自己的。

如果你有時間，改正你所犯的錯誤。如果沒有時間，保持代碼原樣，但寫下你做錯了什么。

iii。根據(jù)聲明的假設檢查代碼

您基于一些假設編寫了代碼。回到你的假設列表，檢查你是否遵循了它們。

如果你這么做就太完美了。但是在編寫更復雜的代碼時，您可能會放棄一些假設或引入新的假設。也寫下來。如果您沒有遵循所有的假設，但您認為您應該遵循，并且您有時間更改代碼，那么就這樣做。如果沒有，就保持原樣。

iv。檢查代碼可讀性

在這里你應該檢查一下你是否理解你剛剛寫的東西?；氐侥拇a，再次檢查每一行的語法和邏輯。在逐行執(zhí)行時，評估代碼可讀性是否可以提高。您在命名約定上是否一致？你的別名清楚嗎？有什么歧義嗎？代碼是否以邏輯的方式構造并分成邏輯的部分？

同樣，如果有時間，提高代碼的可讀性。如果沒有時間，試著寫下來，或者簡單地記住你本可以做得更好的事情。

V。引導面試官完成解決方案

如果你做了上面所有的步驟，這一個應該會很自然地對你來說。最重要的是，當你解釋你的代碼時，你是誠實的。

無論您在檢查代碼時發(fā)現(xiàn)了什么錯誤，都要顯式地聲明它們。不要指望你的面試官不會注意到他們。別想把他們藏起來。承認你的錯誤，并表明你知道自己做錯了什么。每個人都會犯錯，但不是每個人都能意識到自己犯了錯并承認錯誤。它表明即使你犯了錯誤，你也知道自己在做什么。說到錯誤，以下是人們在數(shù)據(jù)科學采訪中最常見的錯誤。

如果您在輸出中包含了一個不必要的列，請這樣說，并繼續(xù)解釋您的輸出。你偏離了你最初的假設還是加入了新的假設？這么說并解釋原因。如果你做錯了，說這不是故意的，但你看到你的解決方案應該包括一些額外的假設。說明它們應該是什么，以便您的代碼工作。可讀性也是如此：如果您認為可以使代碼更好，請解釋如何使代碼更好。

通過完成所有這些，您不僅可以顯示您的編碼能力，還可以顯示您的思考速度，您的責任感和誠實性。這些都是所有公司都非常重視的特點。

vi。優(yōu)化代碼

編碼面試中的最后一個問題通常是要求您優(yōu)化代碼的問題。這樣，面試官將測試你的SQL理論知識。例如，如果您知道聯(lián)接可能在計算上耗時？您將被要求找出是否有消除聯(lián)接或子查詢的方法。例如，如果試圖找到最大值，通?？梢允褂媚硞€函數(shù)（如排序函數(shù)）刪除WHERE子句中的子查詢。

或者如果您知道對某些數(shù)據(jù)類型執(zhí)行操作的速度有多快。例如，字符串比較比整數(shù)比較慢，那么也許有一種方法可以在字符串數(shù)據(jù)上做到這一點？

結論

所有這些都總結到：如果你能很好地構建你的方法，編寫代碼幾乎應該是一個技術性的問題。重點是更多地思考，而不是編碼。編寫代碼應該以非常有條理的方式進行。

你應該仔細考慮問題、你面前的數(shù)據(jù)、可能的解決方案、你的假設和你需要的功能。只有在那之后，你才應該開始編碼。一旦你開始編寫代碼，你應該能夠讓面試官了解你正在做的事情，并讓他們知道你所做的每一步。像在實際生活中一樣，在開始在生產中使用代碼之前，您必須檢查和優(yōu)化代碼。這次采訪是你的制作；管理好您的時間，以便能夠審閱您的解決方案。

這些是你應該做的事情。在我們的帖子中還有更多的準備技巧：準備數(shù)據(jù)科學面試的5個技巧。

這一切都不容易。它需要經驗和實踐；沒人能偽造這個。但不管你的經歷如何，遵循這份清單肯定會給你的思維和面試表現(xiàn)增加一個堅實的結構。只能讓你表現(xiàn)得更好。