job

面試紀錄 Interview logs

  • Misc
tags: job

TOC

Tagtoo科技跨平台網路廣告

  • job: 後端工程師
  • interviewer: Teddy
  • location: 臺北市信義路四段267號11F
  • date: 2018.12.20
  • questions:
    1. 有沒有用Django開發過什麼專案?
    2. 有用過GCP的什麼服務?有用過GKE嗎?
    3. 看你的經歷,為什麼又想回業界?
    4. 有沒有AI的經驗?用過什麼工具(視覺化、統計分析)?
    5. 為什麼會想投我們公司?是哪個部份吸引你?
  • answers:
    1. 以我在目前任職的農科院有開發過的兩個專案來回答
    2. 主要是使用compute engine,有舉出使用情境:為了幫公司測試tableau server的功能,分別在GCP部署了tableau server及api server;另外有補充是以docker來做部署;至於GKE的部份還沒有摸過
    3. 這個問題我說明了在業界的公司為什麼離職,之後又為什麼會找公部門的工作,有點可惜沒回答到重點,其實主要是業界的技術水準跟real world的營運,能學到更多的東西,另外一方面則是薪水
    4. 回答之前線上課程有上過相關課程,用numpy、pandas、seaborn來打kaggle的經驗
    5. 這一題回答得不好,我回答因為公司所使用的技術滿吸引我,但沒有表現出對廣告投放或資料分析這方面的興趣
  • informations:
    • 目前Tagtoo的廣告拓及率已是領導的地位、規模也在擴張(東南亞:馬來西亞、印尼等),之前比較沒有用AI技術來分析資料(2-3億筆cookie),現在逐漸在加強這方面的分析應用
    • 不接受遠端工作,老闆覺得見面的直接溝通最有效率
    • 應徵的信件應該都是老闆自己回覆的
  • references:
  • results:
    offer get (N-10)*13

趨勢科技TrendMicro

  • job: [email protected] Segment
  • interviewer: Catherine / John
  • location: 台北市大安區敦化南路二段198號8F
  • date: 2018.12.21
  • questions:
    • 一面
      1. 介紹你最近全端開發的專案?
      2. 你說的這個專案是部署在哪裡?為什麼不部署在雲端?
      3. 你的專案有寫過任何測試嗎?是什麼樣的測試?
      4. 為什麼你會針對穩定性來做測試?
      5. 你的專案主要用到什麼工具?
      6. 你之前在業界任職時的專案開發流程為何?
      7. 你的優點跟缺點為何?
      8. 請排序你最想當的角色:code、maintain、testing、design
    • 二面
      1. 為什麼考卷最後一題是送分題你卻沒寫到?是時間太短嗎?
      2. 如果今天桌上有5顆外觀一模一樣的球,但重量不同,給你1個磅秤,你能在幾次比較過後依重量完成排序?
      3. 同上題,如果今天已知其中3顆球和其中2顆球重量相同,能減少你比較的次數嗎?
      4. 如果9跟3的交集是1,聯集是多少?
      5. 今天讓你測試一個登入頁面,有email、password跟1個登入按鈕,你會怎麼測試?
      6. 為什麼前兩個工作性質差異這麼大?
      7. 你有什麼壞習慣?
      8. 人生遇過最大的困難是什麼?
      9. 你守時嗎?
      10. 你未來短、中、長期計畫是什麼?
  • answers:
    • 一面
      1. 介紹了我用Django開發的視覺化網站,專案的緣由以及要解決什麼問題
      2. 部屬在Local Windows Server上,說明因為專案性質跟資源因此沒有部署在雲端,有說明其中利弊
      3. 這個專案從多個API抓取資料,有測試抓取資料的函式及紀錄log,另外針對執行時段較長(如時間範圍廣的)有另外測試
      4. 這個問題一時想不出來怎麼回答,就回答了因為遇到某個問題必須加上這樣的測試
      5. 抓取資料的排程用了redis、celery,後端是django,前端主要用到highchart.js及datatable.js
      6. 一個junior做開發,自訂合理的開發時程或senior同意後開始開發,其中有遇到問題適時反應給senior知道,pm對整個專案的成果負責
      7. 說明了太過悲觀主義,有時想太多劃地自限,但這同時是個優點也是個缺點
      8. code > mantain > testing > design
    • 二面
      1. 答題時間沒有規劃好,不應該發生這樣的事
      2. 磅秤是一種比較排序法,最佳時間複雜度會是O(NlogN)
      3. 答不出來,但可能可以減少?
      4. 原本超簡單的題目一時竟然回答不出來,腦袋卡在為什麼9跟3交集會是1,其中是經過什麼運算得到?主管回覆說可以,但不用想這麼複雜有直接答案
      5. 測試form沒填正確回覆的錯誤訊息是否正確,改變cookie來測試session,之後主管補充可以抓背後的API測試
      6. 這題回答得太長,但主要是遇到突發狀況跟想轉語言
      7. 有強迫症動作、駝背、沒運動習慣
      8. 家裡發生的突發狀況跟當時自己心境上的困境
      9. 自己是個守時的人
      10. 短期:點擊後端技能樹、加強技術能力;中期:在開源社群有所貢獻;長期:創業、做自己有興趣的project
  • informations:
    • 其實我是要面web後端RD,QA只是後來主管有興趣,前幾天臨時加的面試,結果RD當天已經沒有缺
    • 趨勢是看到cakeresume上的履歷,發email線上考邀請,以python做,約一個禮拜後約面試
    • 面試時對趨勢QA工作概況的認知:
      • by project
      • 從專案開始到最後產品上線後的使用者體驗部份全程參與
      • 有分成client端、backend等,行為模式會不同
      • 依照專案需求會碰觸到deploy
      • 該部門RD跟QA的人數比是1:1
    • 針對該部門做的專案細節介紹就不公開紀錄
    • 環境部份:
      • 沒停車位,很難找車位
      • 電梯常常大排長龍
      • 人資很可愛…
    • 說明自己開發用過得技術時比較沒有被challange到
    • 考題很廣,以下列一些比較有印象的:
      • OS: linux指令如chmod
      • code: 給一段code考輸出
      • Web: subnet、ajax
      • 邏輯: 小明大昨天7歲,明年10歲,請問小明生日
      • testing: 針對鬧鐘app列出可做的測試、兩個client端上傳檔案到cloud要注意什麼問題
    • 遇到的人資、面試官人都還滿好的,一整天面試下來滿舒服的

狄卡 Dcard

  • job: Backend [email protected] Learning Team

  • interviewer: Bruce(一面)Bruce, Chris, James, Hao cheng / HR Aria(二面)

  • location: 遠端 Google Meets

  • date: 2021.5.17 / 2021.06.04

  • 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 Enginner 解決過哪些問題?
      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 Enginner 讓他們都能用同一套標準開發,並且提供共用的元件避免重造輪子,解決人工部署的麻煩,且區劃好 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 來判斷如何讀取快取
    • 二面(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 Enginner 做代碼演算法的優化,例如太依賴迴圈,調用順序等 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 有保證一週半內一定會通知結果,不會發無聲卡
    • 剛好遇到疫情爆發階段,沒機會去公司面試,但也因為遠端的模式,可以透過螢幕分享,去更好得表達你的概念與想法
    • 整體來說,我會給此次面試的體驗很高的評價,不像其他公司可能考個 leetcode 看答案,而是真的花時間去了解你的經歷與背景,並針對相關經歷做提問。也因此,建議有相關的經驗再去挑戰,不然應該很難過關。
    • 雖然整個流程進行得很慢,但也很完整,公司感覺也是有完整的考量後才給結果。
  • results:
    感謝卡。提供額外的 feedback:二面針對技術選擇時,回答得比較沒那麼精確。