Dcard Backend 面試

距離收到錄取通知已經有兩個月了，決定來分享一下當初去 Dcard 面試的心得跟過程～

雖然我本來就有在新創公司工作，但是新創公司樣樣都要自己來，而且沒有一個 Mentor 帶領，產品也比較沒有流量，很難判斷自己做出的系統架構是不是一個好的架構，因此今年決定申請 Dcard 實習，來體驗看看高流量的 backend 開發！

面試流程

Dcard 的面試流程算是滿透明的，基本上分成 3 大關，履歷審查、第一次面試跟第二次面試。

整個流程走的也算滿快的，大概一個月就會把整個面試流程走完，而且各個階段有沒有通過都會寄信通知，非常棒～

履歷審查

一開始當然是附上履歷！履歷的部分我是寫滿一頁整而已，基本上就是寫上工作經歷、寫過比較重要的 Side Project、黑客松、讀書會等等。

因為我個人認為 Dcard 還滿看重你的自學能力以及你是不是喜歡與人分享交流，所以放的內容都是比較偏自學、交流性質的活動，一些在學校做過的助教跟網頁開發的打工倒是都沒有放進去。

如果想要參考履歷要怎麼寫的話，可以到 關於我 頁面查看。

申請 Dcard 實習有個比較特別的地方是要交一份作業，是實作一個 Rate Limiter Middleware，也就是如果在一定時間內超過一定數量的 Requests 要回傳 429 Too Many Requests，基本上語言方法不限，我是用 NodeJS + Redis 來實作的。詳細可以參考我的 Github Repo。

另外申請實習是可以附上應徵信的，裡面可以附上一些履歷沒有提到的內容（履歷主要以技術背景為主），例如我在應徵信裡面提到了我為什麼會想來 Dcard 參加實習以及一些個人特質。想參考的可以看這裡。

第一次面試

Talent Operation Team (HR)

首先是 HR 面試，總時間是一小時（但我不到一小時就結束了）。一開始是 5 分鐘的自我介紹，想參考的可以看這裡。再來就是回答 HR 的問題，基本上我個人感覺 Dcard 很在乎你對公司的看法、你來參加的動機等等，比如說我有被問到「為什麼會在大三的時候就想要來做 Intern？」或是「為什麼會走 Backend 這條路而不是其他方向」。HR 也會針對你的履歷提出問題，例如我有被問到「為什麼會寫 Blog？」，讓我真的覺得 Dcard 的 HR 很用心也很親切，在聊天的過程中就能體會出來你的履歷有被認真的看過，而且 HR 對於資訊這方面的知識也都略知一二。

總之 HR 面試關整體來說就很像在聊天一樣，重點就是履歷一定不能造假！最後會問你有沒有任何想問的問題，如果沒有的話就會進到開發面試。

Development Team

由 Backend 的成員來面試，總時間也是一小時（但我也是不到一小時），聽說本來是有 Backend Team 的主管會來的，但我去的時間好像剛好主管在開會，所以就是兩名 Backend Engineer 來幫我面試～

這關主要就是考驗你的技術實力了，不過我覺得問的問題還滿隨性的，除了最後一題之外，其他問題都是圍繞著你的履歷上面有提到的技術，跟一些滿基礎的 Backend 知識來提問的。我有被問到的問題跟我的一些回答包括：

1. RDBMS v.s NoSQL 分別是什麼？
   RDBMS 主要利用資料正規化來分割資料庫，建成一張張表後利用 Join 的方式來合併資料。
   NoSQL 給了方便的彈性，有很多類型，例如：Document based、Graph、Key-Value…
2. RDBMS v.s NoSQL 要怎麼做出選擇？
   RDMBS 跟 NoSQL 的 use case 不太一樣，RDBMS 比較適合被用在需要確保 ACID 的資料上，以確保資料的一致性；而 NoSQL 通常都是希望可以分散式來提高可以性以及可擴充性。另外還有一個考量的點是 RDBMS 的 Join 會使得他不適合用在微服務上，因為跨 services 的 transactions 需要額外的 effort 來實作。
3. ACID 是什麼？
   A 是 Atomic，原子性，一個事務不是全部成功就是全部失敗。
   C 是 Consistency，事務完成後資料正確無誤。
   I 是 Isolation，事務有隔離級別，確保同時發生的事務不會發生錯誤。
   D 是 Durability，事務一旦成功資料就不會遺失。
4. Authentication 跟 Authorization 的差別。
   Authentication 驗證身份，例如帳號密碼；Authorization 驗證有沒有權限使用這個功能。
5. Authentication 怎麼做？
   可以用 JWT。
6. 簡單的說明 JWT 的技術。
   JWT 是 JSON Web Token，主要分成三段，用 . 連接起來。第一段是 header，第二段是 payload，前兩段都用 Base64 編碼，最後一段是前兩段的加密文。可以用來防止攜帶的資訊被修改，因為竄改者無法知道第三段的加密結果為何。
7. 給你兩個很長的 SQL 跟他們的 Explain 結果，請你講解兩段 SQL 做了什麼，以及他們的差別。
   這題基本上是最難的了，因為那時候對 PostgreSQL 還不是很熟，所以其實沒有回答的很好。但主要就是要對 SQL 語法有基礎的知識，特別是常常使用 ORM 而不是直接寫 SQL 的，至少要知道 SQL Join 怎麼使用。

總之我覺得回答的重點就在於，不要提到自己不熟的技術，因為他們很有可能繼續追問你在回答中講到的技術。而這部分的題目大概也是因人而異，我被問到的題目跟我在準備時看到其他人分享的題目也是完全不相同，所以在履歷裡面也近量別寫自已不熟的技術吧xD，不然大概有大機會會被問倒。

最後也會詢問有沒有什麼想問的，基本上我有詢問他們用的框架、他們的開發流程等等。

第二次面試

Talent Operation Manager (HR Manager)

這關是 30 分鐘。基本上跟第一次面試的 HR 面試差不多，但內容會偏向更大方向的討論。一樣真的要稱讚一下 Dcard 的 HR，都非常的親切＆準備充足。

CEO - Kytu

首先，CEO 的名字的念法跟 Kit 是同音的，這個我在去面試前查了好久才查到xD。

這關是 30 分鐘。基本上在別人的面試分享有看到，就是跟 CEO 的聊天關。基本上一坐下就會問你有沒有什麼想問的問題，所以一定要提前準備一些你想要問的問題，除非你的臨場反應真的很好。

基本上想要跟 CEO 聊什麼都沒問題，我有詢問關於 Dcard 從一個 10 人團隊到現在 200 人的管理問題，還有詢問一些職涯規劃，討論讀研、是否要出國等問題。

問題可以盡量準備多一點，因為 CEO 回答的速度還滿快的。

總結

Dcard 的面試總體感受是滿好的，非常看重你對公司的看法。第一次面試時還會帶你參觀辦公室，帶你到他們的零食區拿食物；第二次面試時 CEO 還請喝星巴克，雖然我根本不敢在當下喝就是了xD

基本上如果說要準備的話，我強烈建議多去看看一些關於 Dcard 的文章報導，或是 CEO 的演講也可以稍微看看，會對你在面試時的應答還滿有幫助的～

雖然面試整體過程是走比較輕鬆的路線，但我認為 Dcard 對實習生的審核是非常重視也不隨便的！我認為 Dcard 還滿重視面對問題的邏輯思維和主動學習的能力，所以如果你有在寫 blog 的話，應該是大大加分！

最後，如果這篇文章對你有幫助的話，可以幫我按個喜歡、或是留言！各位的支持就是我寫作的最大動力。有任何想問的問題也可以在底下留言喔～

這篇文章距離我錄取 Dcard 的 Web Backend Intern 有一兩個月的時間了 XD 只是一直沒有時間寫分享文，因為 7/6 就要去上班了，所以特來發此分享文紀錄一下。

其實我投了許多知名的外商公司的 Intern 加一間本土公司的 Dcard，然而外商公司只有到繳交履歷的階段，連面試都沒上真的是很慘 QQ，雖然我也沒有說很意外，因為知名外商公司一向都很搶手，而且許多強者真的是太強了，我自認為我還是很 junior 的工程師 XD。但因為為了生活還是要想辦法找到一份工作，才能半工半讀阿 XD

所以，也很感謝在面試 Dcard 的時候都很順利，也能夠拿到此機會，讓我能夠一探 Dcard 的系統架構。以下的內容我會分享在 Dcard 面試的題目，以及我大致上的應對方式。

面試流程

我是應徵 Dcard 2020 年開放的 Web Backend Intern，當初還有看到前端及資料分析的實習生的招募，但有在看我 Blog 的文章就知道，我是完全怨恨前端的 XDD，沒辦法我對前端完全沒有愛，老實說我覺得天分跟喜好都有影響，我喜歡分析後端的架構，對於視覺呈現的東西我真的是完全不感興趣就是了。

在面試流程上可以看成是有四關的：

• 作業關

  在面試之前，Dcard 在徵才網站上有說明需要繳交作業，簡單來說就是要你寫一個 Project，而 Project 的內容是要實作一個 middleware 來計算 IP 次數的功能，藉此來限制流量。這邊我記得是沒有特別說限制的語言及資料庫，完全自由發揮。在後面會再詳細說明～

• 技術關

  這關顧名思義，就是 Dcard 的後端工程師來面試，所以會問的就是技術上的問題，至於有那些問題，在後面會詳細列出來～

• 執行長聊天關 (?)

  這關說實在可以當作是跟執行長聊天吧，因為我去面試的時候，Dcard 執行長是直接問我有甚麼問題，這個我在之前看到別人的 Dcard 面試經驗分享也有看過，所以我算是事先就有準備一些問題，之後在後面也會詳細列出來。

• HR 聊天關 (?)

  這個相較於前面兩關就會在更輕鬆一點，因為 HR 滿親切的，沒有看到那種很嚴肅的 HR，所以也可以看成是聊天的感覺，然後 HR 也是有問一些問題，之後在後面也會詳細列出來。

作業關面試分享

講真的，我之前應徵的實習工作都沒有要上傳作業的，不過也有可能我的公司都很小，不然就是他們對實習生的要求不高就是了。

以下是 Dcard 作業題目描述：

Dcard 每天午夜都有大量使用者湧入抽卡，為了不讓伺服器過載，請設計一個 middleware：

• 限制每小時來自同一個 IP 的請求數量不得超過 1000
• 在 response headers 中加入剩餘的請求數量 (X-RateLimit-Remaining) 以及 rate limit 歸零的時間 (X-RateLimit-Reset)
• 如果超過限制的話就回傳 429 (Too Many Requests)
• 可以使用各種資料庫達成

這個題目算是很常見的，也算是最基礎的限制流量的方式，這邊因為我覺得只寫一個 middleware 有點難以 Demo，所以我索性寫了一個很小型 Dcard 系統的 Backend，但是也只是有一些註冊登入使用者、抽卡等 API 而已。因為我個人是滿好奇 Dcard 後端是怎麼去實作抽卡這個步驟的，所以就順便做個陽春版了～然後在抽卡 API 上前面放前面作業所規定的 middleware。

這邊詳細作業的實作架構就不多講了，因為可以直接參考我的 GitHub：https://github.com/KennyChenFight/dcard-simple-demo

我在 README 寫的算滿詳細的，這邊就只講我大致上的思路就好：

• middleware 部分應該搭配類似於 Redis 類型的 DB

  這種功能一般情況下是不會搭配如 PostgreSQL 這類型的 RDBMS 的，簡單來說 Redis 存放這些資料，就如同存 Cache 資料，因為每個 User 的 IP 記數，主資料庫根本就沒必要知道這件事情，主資料庫本就應該負責真正重要的資料，如果讓這類型的 middleware 搭配主資料庫將會大幅度拖垮效能，也就是在大部分的情況下，我們都應該先去快取資料庫取資料，因為這樣的存取或寫入的速度快，只有當快取資料庫取不到相對應的資料，才會去取主資料庫的資料。

• 熟悉何謂 Race Condition

  不管是 RDBMS 或 NoSQL 都會遇到 Race Condition，也就是我在實作的時候，如果你不瞭解 Redis 的機制，那也是會容易寫出有 Race Condition 的，這邊我算是有寫出兩種版本，一種是 Race Condition，一種是沒有的，因為說實在的 IP 記數那邊少記了一次或多記了一次，影響很大嗎？

  我的想法是：如果系統並沒有高流量，即使使用者會多拜訪個幾次，對於系統負擔造成不是很大，採用簡單的實作方式即可，即便會 Race Condition。而沒有 Race Condition 的版本，需要撰寫 Lua 腳本才對 Redis 進行存取跟寫入的動作，對工程師而言，你需要多學一個 Lua 語言，你才能維護存取跟寫入的動作，當然這是沒有很難，如果想知道為什麼可以去參考我的 GitHub。我後來是丟沒有 Race Condition 的版本，不過我在技術關的時候有講解有這兩種版本以及採用情境當下為何。

作業差不多就是這樣，然後因為沒有特定限制語言及資料庫，但是在徵才說明上，有特別說希望是熟悉 Golang 或 Node.JS，而資料庫的部分希望熟悉 PostgreSQL 及 MongoDB，因此作業我就是採用 Golang+PostgreSQL+Redis 來實現的。

不過，題外話，我到現在還是不敢說熟悉某種程式語言，我只能說認識，我對熟悉的定義是非常專精並且了解程式語言整個底層架構 XDD

還在學習中就是了 ><

技術關面試分享

這個 Dcard 的技術關，其實跟我以前面試的公司不一樣，因為我以前應徵的都是實習生的職位，說實在面試的時候根本就不會問甚麼技術的問題，就算有，也沒有很細，不過也有可能我遇到的公司都很水吧 XD

相較起來，會覺得 Dcard 的技術關相對較硬，如果你是超級超級 junior 後端，在這邊很容易會被問倒。而且因為我事先不知道會被問這樣，我事前也是沒有任何準備 XD 不過好佳在憑藉著平常有在做筆記及工作的關係，有一些技術的東西根本就會深刻在腦海中。

再來要補充的就是這關由於疫情的關係所以是視訊面試，我覺得這也因此對我有好處吧，因為我個人其實滿容易緊張的，但是視訊面試的話我是不太會緊繃的，而且很自在。

以下是被問到技術題：

• 作業講解

  這個我有點忘了，但是我記得好像是有問作業上的架構思路講解，我大部分就是講為什麼要用 Redis，以及如何用 Redis 實作該 middleware，還有如何避免 Race Condition，但我這邊很強調 RDBMS 跟 NoSQL 的使用情境。

• RDBMS 與 NoSQL 的選用考量

  這題我個人認為是因為我的作業講解很強調 RDBMS 跟 NoSQL 的情境，所以這邊特地問我的選用考量，我以前的觀念是用 NoSQL 好爽，schema 亂開且很有彈性，想改就改。直到我的專案因為用了 MongoDB 當主資料庫，並且當專案規模越來越大時，我才發現有夠痛苦，我還是想強調就是，該專案不管未來是否會有高流量的情況產生，都還是需要用 RDBMS 作為資料庫，因為大部分的系統的功能時做下來，都會造成有多種 JOIN 的情況，如果你使用 NoSQL 會變成多文檔的 JOIN 方式，要知道 MongoDB 是只有支持單文檔事務的，如果你要支持多文檔的事務，你必須自行實作 two phase commit，雖然官方有提供程式碼，可是要知道這段程式碼可是又臭又長，而且並不能 100% 保證不會出錯。雖然我知道現在 MongoDB 4.0 之後貌似有支援多文檔事務，這方面我還沒有很實際去了解。

  當然會有人說 NoSQL 設計上，就應該把 JOIN 的情況改成單文檔的方式，然後不斷地內嵌文檔，這樣就不會有多文檔 JOIN 的方式產生，這個我個人認為整個 Schema 會變得很複雜，而且在程式上存取的撰寫並沒有很容易，反之很容易會出錯，而且需求多變，你要利用單文檔打遍天下，我個人是覺得很困難。而且 MongoDB 我出現過遺失資料的情況…QQ

  我是覺得高流量的系統應該是由 RDBMS 跟 NoSQL 撐起的，兩者是互相輔助的功能，所以一個好的系統不應該只靠 NoSQL 打天下。

• RDBMS 的隔離層級所造成的 Race Condition

  RDBMS 的 Race Condition 我相信是一個後端工程師需要理解的概念，我之前為了理解這個也做了不少壓力測試的實驗，為的就是看到各種 Race Condition 的情況。

  不過說真的有點漏氣，當時回答的時候有一些 Race Condition 的專有名詞忘記了，所以並沒有講得很詳細，最基本的當然就是 Dirty Read、Non-repeateable Read、Phantom Read，然後如何解決這些 Race Condition，除了透過設置 RDBMS 的隔離層級還有就是在 SQL 語句上做手腳，

  以上這些解決方法都有在我的 Blog 文章提到，可以尋找 RDBMS 分類就可以看到了 XD

• Golang channel 的解釋

  這邊就偏向講解 Golang 程式語言的概念了，要寫多 Goroutine 的程式，Channel 的概念是必須要懂得。

• 當有失敗的 Goroutine，如何去處理

  這邊是問一種情境，如果你的 Goroutine 可能遇到 Error 而被關閉了，你要怎麼知道得知這件事情，這種需求我個人認為最普遍的方式就是透過 Channel 來進行通知寫下 log，以方便日後能夠發現及 Debug。

• Redis 選用的 key value 架構選用考量

  這邊的話面試官沒有給任何情境，所以我也就是拿作業的實作方式，講解存入 Redis 是用哪種資料型態，並且為何這樣做及如何存取，這邊的話就是講解 Redis 的 Hash 資料結構

• RDBMS 的 Index 是甚麼，如何輔助

  這邊就是講 RDBMS 的索引是甚麼意思，又要怎樣才能建立好的索引，提升效能等事情，不過個人並沒有對這個很拿手，應該說理解了基本概念，可是真的要熟悉是需要一些實戰經驗的累積的。

• 如何測試 SQL 語句效能好不好

  這邊我猜面試官是想要考知不知道 EXPLAIN 語句，因為每個查詢語句都會建立一個每個查詢設計一個查詢計劃，透過看這個查詢計畫可以看出該 SQL 語句是慢在哪裡，透過這樣的方式去改進 SQL 語句的效能。

• 考你一個 SQL 語句，問你哪些欄位可以加 index

  1	select id, title from posts where pinned = true and createdAt > '2019-04-23'

  這邊是考說如果有該 SQL 語句，你會把索引加在哪個欄位上。

• Message Queue 的 Consumer 怎麼處理 fail data 或是 Consumer 掛了怎麼辦

  這邊會問我這個問題，是因為我在前公司負責做有關 Message Queue 應用的專案，所以特定問我是如何處理失敗的資料或者 Consumer 掛了的話要如何重啟或是解決方式。

  其實對此我有寫了一個 RabbitMQ 封裝的 Library，可以參考一下：https://github.com/KennyChenFight/rabbitmq-go

  雖然封裝的普普通通，但也是有完成重新連線的機制，歡迎發 issue 一起改進，有空我也會持續改善架構的。

• CI/CD 的概念

  講真的我 CI/CD 用的並不多，主要原因是我之前的工作經驗，公司沒有很扎實的 CI/CD 的流程，其實也可能是因為我是實習生的職位，我根本碰不到這個，大部分的工作專案大多是一人完成，也根本沒有協作的經驗，很多情況下我都是透過自學或者是跟朋友寫專案慢慢去摸索的，對我來說目前比較熟悉的話大概就是 GitLab 提供的 CI/CD 的功能了～

• Docker 的概念

  這個也算是老生常談了，現在很多公司都在用 Docker 了，不管是開發或是上線，都是非常好用的工具。

• 問你想問面試官什麼問題、為什麼想來 Dcard

  這個題目就很常見了，我記得我就是問了 Dcard 系統的架構及解釋為什麼我想要換工作並應徵 Dcard。講白了就是我想體驗團隊協作、完整的 CI/CD、Code Review、高流量的設計。原因就是這麼簡單，我覺得當經歷過這些，整個視野才會提高，而且就很清楚理解業界是怎麼運作的。

執行長關面試分享

其實純粹聊天的面試才是我最害怕的 XD 因為可能一不小心就被面試官心裡打了個大 XX 都不知道 QQ 尤其是如果是自己提問題的話又更加困難，總之這關我倒是聊了滿多創業的事情的，畢竟曾經我也想要創業，然而面對現實還是先擱著了 QQ

我只能說年紀輕輕就成立公司是一件很大膽、勇氣的事情，能夠做出自己喜歡的產品是一件很有成就感的事情，Dcard 到了今天的規模，雖然受眾大多是台灣的大學生，但這也足以說嘴了，而且當你用戶越多，寫出來的系統就會越被挑戰，當越被挑戰就需要花很多時間去改進，工程師實力才會大幅度的提升。所以如果想要體驗高流量，要先想辦法提高用戶，否則高流量的一切架構設計都是白談的。

HR 關面試分享

這關就很輕鬆了，HR 大致上就是問我為什麼會喜歡寫程式，為什麼要換掉前一份工作來應徵 Dcard，還有自己作品分享等經驗，就盡量分享自己的經驗及思路就可以了，有時候我都會陷入擠不出問題，然後就乾在那邊 QQ 我覺得這也是我需要改進的地方，不過我是覺得當問題都問完之後就也不必硬聊，可以提早結束就好。

總結

以上大概就是 Dcard 面試過程的分享，說實在很多都是第一次被問到，也算是給了我一個審視自己的機會，我個人覺得 Dcard 對於實習生的標準是一點都不馬虎的，而且感覺在整個專案流程上是做得很完善的，在我之後進去工作後，會在分享自己的感想，總而言之，我覺得進去 Dcard 是一種挑戰，而且我相信強者一堆，我會被電爆，所以像個海綿一樣努力汲取吧！

最後最後！請聽我一言！

如果你還沒有註冊 Like Coin，你可以在文章最下方看到 Like 的按鈕，點下去後即可申請帳號，透過申請帳號後可以幫我的文章按下 Like，而 Like 最多可以點五次，而你不用付出任何一塊錢，就能給我寫這篇文章的最大的回饋！