Dcard – Machine Learning Backend Engineer 面試紀錄

  • Misc
  • Title: Backend [email protected] Learning Team
  • Interviewer: Bruce(一面)Bruce, Chris, James, Hao cheng / HR Aria(二面)
  • Location: 遠端 Google Meets
  • Date: 2021.5.17 / 2021.06.04

Intro

透過內部的朋友介紹,因為有相關經歷決定投投看,準備的方向是:

  • 一面:

    • 快速刷了一個 leetcode 的線上課程,可以在短時間複習資料結構與演算法,以及歸納好的題目能更好掌握解法
    • 複習了 Redis In Action 如何設計 Twitter 系統的部份
  • 二面:

    • 複習了 DDIA (Design Data Intensive Application) 的批處理與串流處理章節
    • 重讀了 BigQuery 的文件
    • 統整之前做過的專案,找回已經忘記的經驗與知識點
    • 準備主流面試問題的回答

希望這份筆記能幫助到下一位挑戰者~

Questions

  • 一面

    1. 請你自我介紹
    2. 為什麼選擇使用 Kubeflow?
    3. 你設計的事件系統的 qps 多少?
    4. (子題)有沒有做負載測試?
    5. (子題)你設計的事件系統如果超過 BigQuery 的 insert quota,怎麼處理?
    6. 為什麼喜歡容器技術?
    7. 你所建制的 ML 基礎設施是否對團隊帶來實體的幫助?
    8. 你會怎麼實作一個 Set 資料結構?
    9. (子題)如果不用 Dictionary,要怎麼做?
    10. (子題)你使用 BST 的排序只適用 numeric,如果插入不同的 Data Type 要怎麼改?
    11. 如果要你設計一個 API 服務使用者資料,你會怎麼優化效能?
    12. (子題)使用 python lru cache 或連外部的 cache server 有什麼差別?
    13. (子題)如果想要針對快取做統一的設定,怎麼做?
    14. 有什麼問題想問?
  • 二面(HR)

    1. 請你自我介紹
    2. 之前為什麼會做農科院的研究助理?
    3. 為什麼想換工作?
    4. 未來五年生涯規劃?
    5. 有什麼問題想問?
  • 二面(ML Team)

    1. 請你自我介紹
    2. 你設計的事件系統如果造成阻塞,怎麼處理?
    3. 你設計的事件系統怎麼優化串流的速度?
    4. 你導入 ML 生產流程時,有幫 Data Engineer 解決過哪些問題?
    5. ML 生產流程的資源如何規劃?
    6. 如果 Log 量太大,怎麼處理?
    7. 你如何監控系統?
    8. 如果要你蒐集使用者點擊廣告的資料,並能在 1 分鐘內搜尋到結果,要怎麼設計?(白板題)
    9. (子題)如果要縮短時間,要怎麼優化?
    10. (子題)你的解決方案在查詢資料時要 scan,怎麼避免 scan?
    11. 有什麼問題想問?

Answers

  • 一面

    1. 介紹自己過去待過什麼公司,做過什麼 side project,特別強調接觸容器技術和雲服務後的轉變。因為經歷的相關性,花了很多篇幅講述目前工作做過的事。
    2. 說明當初有考慮過 Airflow,但當時對 k8s 的支援還不夠好,Kubeflow 則是 k8s 原生,另外 UI 有內建 IAP,以及有提供 Notebook Server 等附加的微服務
    3. 因為是新系統,尚未完全取代舊系統,qps 約 50-100,強調未來轉移完成和事件類型增加會達到 qps 1000 以上
    4. 沒額外做負載測試,說明前級的 API 沒有外部服務查詢的依賴,依賴的 config / api token 是以小資料集的 sidecard 模式運行,只要服務的可擴展性設定好,事件送到 Pub/Sub 之後,便可確保後面應用端對資料的 durability
    5. 說明已經有遇過類似的問題,送資料到 Facebook 同樣有 request limit,是以 Dataflow 對事件做壓縮處理(by windowing)解決
    6. 說明容器服務可解決跨系統的依賴問題、容器具有獨立性與無狀態性的好處,另外容器引擎如 docker 提供了 network 及 volume 的設定,在開發端能帶來 IaC 的好處
    7. 建置的 workflow 制定了一套 pipeline 開發標準,反饋給 Data Engineer 讓他們都能用同一套標準開發,並且提供共用的元件避免重造輪子,解決人工部署的麻煩,且區劃好 I/O 與 operator 能夠更快速追到錯誤來源
    8. 從這題開始 live coding,定義一個物件內部以 Dictionary 查詢重複的元素,在 insert 時避免重複,並且說明如何透過定義 dunder method 讓物件變成 Iterable
    9. 如果不用 Dictionary,可以實做一個演算法如 BST,去有效率的找出元素是否已經存在
    10. 可以透過型別的判斷,分別存到不同的陣列,以套用不同模式的查找
    11. 先確定 API 在查詢 Database 是否已經最佳化,提出幾個快取的方案:1)最簡單的方式是在函式掛 @lru_cache 2) 連接外部的 cache server 3) 使用額外的 batch 服務算出 hot key
    12. 差別在於負載均衡的情況前者會不適用,若是後者則有高耦合節點崩潰的問題,可以透過掛載小資料集的方案取代
    13. 可以自定義一個 MiddleWare,統一分析 request 來判斷如何讀取快取
    14. 問了兩個問題:

      1. 此次面試有什麼可以改善的地方?——自我介紹太長,最好可以簡單敘述解決什麼問題
      2. 下一面的建議?——會問系統設計相關的問題
  • 二面(HR)

    1. 因為是遠端面試,特別準備一個簡單的投影片輔助自我介紹,從一面的自我介紹做改善,強化了接觸容器技術和雲服務後的轉變,並讓目前工作的重點項目更加簡潔(縮短至 5-7 分鐘)。因為是面向 HR,更簡化技術相關的說明。
    2. 因為想換語言 C# 換到 Python,那份工作開始學習 Python 以及用 Django 做專案
    3. 說明主因是想挑戰更高的工作標準
    4. 職涯的話長期要對各個工具掌握度更高(見樹也見林),短期想針對 Linux 與網路相關底層知識做強化;興趣方面說明自己有在自學鋼琴,每天都有練習且直播,期許能持續進行
    5. 針對 HR 描述的公司介紹(公司有年度目標,根據此目標去切分短期目標)做細節提問、詢問個人的工作績效如何定義(OKR 指標)
  • 二面(ML Team)

    1. 同上,技術相關有更完整的描述。
    2. 使用 Pub/Sub 有資料保留的特性,如果後端應用失敗,可以在恢復後快速的自動擴展去消耗已經累積的事件
    3. 說明此系統最大的 effort 在於事件會以 10 秒 window 做壓縮,其他部份都只有 I/O 要處理,整個事件流在短時間內就可傳遞完成
    4. 分成幾個面向去說明: 1) 幫助 Data Engineer 做代碼演算法的優化,例如太依賴迴圈,調用順序等 2) 使用 Kubeflow 時版本還太新,遇過許多系統上出現的問題,如 MySQL 微服務的查詢效能太差
    5. 規劃 operator 的資源通常要實際跑過一次,再根據資源使用量去做調整,如果遇到資料傾斜的差異,則須另外客製化
    6. 有遇過 Log 暴增導致成本增加的問題,透過 GCP 紀錄檔的篩選器去排除不要的紀錄
    7. 使用 GCP 的 Stack Driver 去拉圖表,指標超出監控值就發送通知
    8. 根據之前設計過得事件串流系統去做,使用 Pub/Sub 及 k8s 的微服務處理事件的寫入,因為需要快速看到結果,廣告點擊次數的累計不能透過 Batch System 去算,所以 Database 會選用適用 high throughput 及讀寫快速的 BigTable 去存,表的 key 設計成 user_id#ad_id 格式,並說明 BigTable 可以如何處理寫入衝突
    9. 說明 BigTable 的寫入操作不需要任何查詢,可以在 5-20 ms 內完成,如果要優化,可以針對前面串流的過程則透過更好的水平擴展規劃去降低突然流量造成的阻塞
    10. 說明 user_id#ad_id 的設計的確會 scan 表,可以改成只用 user_id 當 key,而 ad_id 改放欄位,因為 BigTable 底層是 hash map 的資料結構,欄位有很好的擴展性並不會造成額外的儲存空間,這樣查詢的時間複雜度只要 O(1)
    11. 問了以下問題

      1. 詳細工作內容?——ML 串流系統的優化、Pipeline 的實作,總之 ML 的後端都會碰到
      2. 是否有 code review?——有
      3. tech stack 的優先順序?——k8s 與 elasticsearch
      4. 對於此次面試的 feedback 與下一面的建議?——因為要集合團隊的意見,事後會發信分享

Informations

  • 原本以為會考 leetcode,但實際上都是問應用層面的問題,面試過程的確是偏向「面談」而非「考試」
  • 第一面沒準備到自我介紹,只能臨陣發揮,花了太多時間講自我介紹(15 分鐘),但面試官很有耐心去聽完我的經歷描述,對於問題的提問過程也以多個角度切入,去判斷你的理解程度到哪裡
  • 面試結果不會很快公佈,一、二面的結果都是將近一個禮拜才通知,HR 有保證一週半內一定會通知結果,不會發無聲卡
  • 剛好遇到疫情爆發階段,沒機會去公司面試,但也因為遠端的模式,可以透過螢幕分享,去更好得表達你的概念與想法

Result

感謝卡。提供額外 feedback:二面針對技術選擇時,回答得比較沒那麼精確。

整體來說,我會給此次面試的體驗很高的評價,不像其他公司可能考個 leetcode 看答案,而是真的花時間去了解你的經歷與背景,並針對相關經歷做提問。也因此,建議有相關的經驗再去挑戰,不然應該很難過關。

雖然整個流程進行得很慢,但也很完整,公司感覺也是有完整的考量後才給結果。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。