[面試分享] Meta (Data Scientist, Product Analytics)

Meta 的面試非常好玩也具有挑戰性！整體來說，從 HR 到面試官的對談都非常舒適，體驗非常好！準備技術關的過程中也同時溫習過去所學，讓自己的技術水平更上一層樓

面試公司與職位

公司名稱: Meta

職位名稱: Data Scientist, Product Analytics

面試時間: 2025/04

面試地點: remote

工作地點: London

結果: Offer

面試內容

• 2025/03/28 First HR Phone Call (45 mins)
• 2025/04/29 Screening Interviews (45 mins)
• 2025/05/20 Virtual Onsite Interview (45 mins * 2)
• 2025/06/03 Virtual Onsite Interview (45 mins * 2)
• 2025/06/27 Team Match (45 mins)

Meta 的 HR 會建議你花時間好好準備 Screening Interviews，通常是 2 週左右開始進入面試流程，但由於我中間卡到家庭旅遊，所以隔了將近一個月才開始。我大概 2 天後收到回應說通過，進入 Virtual Onsite 階段，中間因為我回台處理事情，因此又隔了將近一個月才開始。我自己的建議是不要把時間拉太長，2 週是滿不錯的節奏，不然準備到後面很厭世，同時還要上班，會心力交瘁。

Meta 的面試會先通過幾輪測試來決定你的 Level，最後再根據你的 Level 去尋找有開缺的 Team 進行 Team Match，如果對方覺得你聊得來，就會發 Offer 給你。由於保密協議的關係，我無法透露實際面試的問題，以下僅針對每一階段進行大方向介紹，以及分享我是如何準備每一關面試的！

Fisrt HR Phone Call

不得不說 Meta 的面試體驗非常好，從一開始的 HR 介紹就非常仔細，不僅了解你個人的背景、動機以及個人期待，也花非常多的時間介紹 Meta 的面試流程，同時也給予很多素材讓你清楚明白面試的重點。

在每個階段間，也都有一次通話，HR 會告訴你下一關大方向會考什麼，有什麼不會考，可以怎樣準備等等。個人覺得滿好的，一開始就把遊戲規則講清楚，明明白白的告訴你我們就是要考 A, B, C，如何流暢應答就是憑本事看個人造化。

Screening Interviews

可以把 Screening Interviews 看作技術關第一面，用來篩選面試者的基本能力是否到位，考題主要有兩大方向 SQL 以及 Product Sense，總共 45 分鐘

Virtual Onsite Interview

通過 Screening Interviews 後會進入 Virutal Onsite，可以看作更進階的技術關，總共包含四場面試：Analytical Reasoning, Analytical Execution, Technical Skills 以及 Behavioral，各自都是 45 分鐘，可能全擠在同一天，也可能全部分散開來，取決於你以及面試官可行的時間

• Analytical Reasoning
• • Product Case Study，會有一個或數個 feature 並詢問你相關的問題，大致上和 Screening Interviews 的題型差不多，但問得更深更廣。我個人認爲這部分和 Behavioral 是決定 Level 主要的兩關，前者測驗你的硬實力，後者則是考驗軟實力。
  • 範例題
  • • Assuming the Facebook Stories feature has been fully launched and A/B testing is no longer possible, how would you measure its success?
    • Let’s say you’re a Product Data Scientist at Instagram. How would you measure the success of the Instagram TV (IGTV) product?
    • Imagine Facebook Messenger can only make 2-person calls at the moment. And Product is considering adding a feature to make group calls. How would you approach it?
  • 面試官想要聽到的內容以及可能的 Follow up 問題
  • • Who would you roll this out to?
    • How would you set up an A/B test for this feature?
    • What metrics would you use to evaluate the success of the group call feature?
    • How would this test be evaluated?
  • 這類問題剛開始準備會滿吃力的，特別是不熟悉該產品時，很容易就卡住，我建議先從自己做過的專案下手，並且根據以下框架去練習。專案順完之後可以開始練網路上找的模擬題，也可以丟給 chatGPT 做模擬訓練。
  • • 商業目標 - 想解決怎樣的問題？為什麼我們認為這個問題重要？誰是我們的主要目標？為什麼？產品改動的假設以及期望是什麼？
    • 如何定義成功 - 北極星指標是什麼？還有哪些 Lagging 或 Leading metrics？除了上述指標外，還有哪些指標是重要的？
    • 衡量成功 - 如何設計 A/B test？可能會遭遇到什麼樣的困難？如何解決？
    • 結果 - 成效如何？ 是否決定上線？後續可以怎樣優化？
  • 面試當下我會建議你順著面試官的問題走，主動提及潛在的問題或是如何進行 trade-off 決策。舉例來說：
  • • MKT 實驗和預算息息相關，公司不願意在初期投入大量資源，僅能 target 一小部分的受眾進行實驗，因此實驗需要跑更長的時間。這種情況下，我們可以建立一個 model 去計算當匡列 X% 用戶會需要跑 Y 天實驗，最終需要花費 Z 元，並以此給予團隊建議
    • 在實驗設計時考量到 Novelty Effect，減少結果誤判
    • 推薦演算法相關實驗要考量到多樣性，以此確保電商平台的健康，而不是一味的推薦熱門店家
    • 系統面層級的衡量以及 Side Effect。例如 Facebook 和 Instagram 可以互相導流，在 Facebook 上進行產品改動，可能讓 Instagram 流量下降。因此需要從 Meta 的角度衡量成功，舉例來說，每一個互動有一個 Engagement Score，當 Facebook 上互動增加，而 Instagram 減少時，是否整體分數還是上升的，以此作為最終判斷基準
• Analytical Execution
• • 以統計為主要核心，同時會夾帶一些產品相關的問題。不是填鴨式的作答，而是透過情境去詢問不同的統計問題，我個人第一次被這樣問，滿驚豔的同時也覺得滿有趣的
  • 關於統計，唸書就對了，把日常會使用的統計概念複習得滾瓜爛熟，上網查查Meta 以及其他大廠的考古題刷一刷，然後我就去面試了。以下是我複習的內容，文章最後會附上我自己的答案
  • • Mean, Median, Variance & Standard Deviation 的定義和公式
    • 大數法則
    • 中央極限定理 (Central Limit Theorem)
    • Standard Error
    • Sample Size 計算公式
    • Type I Error, Type II Error & Power 各自定義以及如何影響 Sample Size
    • P-value 定義以及公式
    • Confidence Interval
    • Z-test vs T-test 公式以及應用場景
    • 條件機率 (Conditional Probability)
    • 二項式分布 (Binomial Distribution)
• Technical Skills
• • 第二次 SQL 測驗。我覺得題目很活，不像是刷題那樣死板的給 input 問 output，會問更多關於 Product Sense 的問題
  • 關於如何準備 SQL 可以參考這篇 [面試分享] SQL 面試準備攻略：準備技巧、刷題資源與範例解析
• Behavioral
• • 給定情境詢問你是否有相關經驗，並且根據你的回應追問。舉例來說
  • • 有沒有和同事相處不愉快的經驗
    • 有沒有專案中途被上層介入而調整方向的經驗
    • 有沒有在時間壓力下完成事情的經驗
  • 不僅在詢問你「是」或「否」，更多的是想知道你是否明白問題的來源，以及能夠解決問題。這類題目沒有標準答案，更像是認識你的工作風格，進而確認你未來能與團隊合作融洽
  • 我自己覺得 Behavior 是最難準備的，因為什麼樣的題目都有可能出現，一旦面試中被問到沒想過的題目，很容易就會當機，再加上是英文面試，一旦卡詞或是轉不過來表現就會頗糟，這點在 Senior Role 或是 Manager Level 很被看重。我唯一能給的建議有兩點
  • • 套用模板 - 網路上有很多不同的介紹，我個人習慣是 (1) 先簡單闡述背景，著重在問題發生的原因。(2) 繼續解釋當下我怎麼解決問題或是衝突 (3) 有機會的話，會再延伸說明下一次發生類似情況的時候，我成功基於上次經驗化解問題
    • 大量練習 - 雖說題目種類跟海一樣廣，還是有跡可循，個人經驗為例，題型多半圍繞在「成功」、「失敗」和「衝突」三大環節，網路上也很多範例可以參考。我自己會把題目跟答案都寫下來，然後丟給 chatGPT 請他作為面試官角色陪我練習。一開始可能會很卡，所以注重在回答的質量，練習越多就會越順，就可以回答越快了！

Team Match

當上述面試流程都通過後，最後會進入 Team Match 階段。Team Match 雖然是面試的一環，但不用感到太大壓力，Hiring Manager 會請你快速自我介紹，然後開始介紹該職位的主要業務、團隊大小等等，我自己沒有遇到更多的技術問題，僅是閒聊而已。如果對方覺得你不錯，就會進入 Offer 階段，HR 會告知你評定的 Level 並提供給你 Offer，如果對方覺得不適合，或是你單方面拒絕該機會，也不必太緊張，後續還是有機會再有下一次的 Team Match。面試結果會保留一年，除非你想要挑戰更高的 Level，否則一年內都不需要重新進行技術測試，而且結果適用於全球崗位，只要當地 Hiring Policy 允許，你就有機會得到 Team Match 的機會並且拿到 Offer

總結與心得

• 整體來說，我覺得 Meta 的面試體驗非常好，除了 HR 中間去放假有一陣子 Follow up 回得比較慢以外，效率都還算不錯。每個面試階段中都會主動聯繫你，詳細介紹面試內容以及注意事項，備感照顧。
• 技術方面，我覺得面試有一定的難易度，特別是 VO 會考不同的類型，很需要花時間準備，網路上可以找到很多心得，也有人會去一畝三分地刷考古題，準備的方式百百種，可以尋找自己適合的方法。有機會的話也建議找人 Mock Interview，真人對話和人機的臨場感是完全不同的，熟悉面試的環境壓力有助於回答問題！
• 面試準備階段，我花最多時間在準備 Product Case，每天上班通勤就練一題，下班回家再練一題，不求多但求實，每次練習至少 30 分鐘起跳，不斷詢問自己有哪邊沒有思考到，也會丟給 chatGPT 評分並且給予建議。準備第二多的是統計，統計存在日常工作中，但除了面試外，從未有文字化闡述的經驗。我自己是去翻過去的課程筆記，快速溫習一遍並且手寫答案下來，特別是公式的部分，有手寫並且簡易推導才容易記住。SQL 我一開始大量刷題，刷乾了之後就開始維持每天 1 題維持手感，沒時間就跳過。Behavior 的部分是我準備最不足的部分，一開始以為會和過去面試的內容差不多，圍繞在過往專案經驗上去挖掘，殊不知題型完全沒預料到，殺個措手不及。
• 很開心能夠拿到 Meta 的 Offer，算是對自己的一大肯定，知道過去幾年的經驗累積有達到一定的水準，通過後也開始比較敢去投大廠，而不是畏畏縮縮的覺得不可能會上。美中不足的是，即便 Meta 開給我比現職高 30% 的 TC，最終因倫敦爆炸高的居住成本婉拒了該 offer。後續有機會再寫一篇台北 vs 柏林 vs 倫敦的薪資與生活成本比較！

問題＆答案

統計小菜雞如我，如果有寫不好或是錯誤的地方，還請留言多多指教！

統計

• 大數法則
• • It means the more data we collect, the closer the average of our sample gets to the actual population average
• 中央極限定理 (Central Limit Theorem)
• • The central limit theorem states that the sampling distribution of the sample mean will approach a normal distribution as the sample size increases, regardless of the population's distribution, provided the samples are independent and identically distributed.
• Standard Error

Standard Error = s / √n
s = 樣本標準差（sample standard deviation）​
n = 樣本數（sample size)

• Type I Error, Type II Error & Power 三者間的關係以及如何影響 Sample Size
• • Type I error is like blaming someone for a crime they didn’t commit — we rejected the null when it was actually true. (false positive)
  • Type II error is like letting a guilty person go free - we failed to reject the null when it was actually false (false negative)
  • Power is the probability of detecting a real effect, that is, correctly rejecting the null hypothesis when the alternative is actually true.
• P-value 定義
• • The p-value indicates how surprising the observed results would be if the null hypothesis were true. A common threshold is 0.05.
  • If the p-value is less than 0.05, it suggests strong evidence against the null hypothesis, and we can reject it. If the p-value is greater than 0.05, it suggests weak evidence against the null, and we fail to reject it.
  • In practice, p-value is commonly used in A/B testing to determine whether there is a statistically significant difference in user behavior between the control and variation groups.
• Confidence Interval
• • It gives us a range where we believe the true value (like the population mean) lies, based on our sample — with a certain level of confidence.
  • In statistical analysis, The width confidence interval is directly proportional to the confidence level, i.e., as the confidence level increases, the width of confidence interval increases as well.

Product Case

聲明我不是社群媒體的產品專家，以下僅是我自己思考後與 chatGPT 對話的結果

Case Study 1 - Imagine Facebook Messenger can only make 2-person calls at the moment. And Product is considering adding a feature to make group calls. How would you approach it?

• Who would you roll this out to?
• • Roll out to active group chats with 3 or more members and at least 5 messages exchanged in the past 30 days.
  • These are groups that already show ongoing interaction and are more likely to benefit from synchronous communication.
  • Exclude dormant or inactive groups to avoid noisy results or infrastructure load.
  • Optionally, segment by market to start with regions where group calling behaviors are more established (e.g. Southeast Asia, India, LATAM).
• How would you set up an A/B test for this feature?
• • Use a cluster-randomized design, where the unit of randomization is the group chat thread.
  • To avoid network contamination, map out the user-group graph and assign entire connected components (clusters of overlapping users/groups) to treatment or control.
  • Run the test for 2–3 weeks to observe sustainable adoption and behavior patterns.
  • Monitor
  • • Adoption and engagement (treatment only)
    • Messaging activity (both groups)
    • Guardrails: crash rate, error rate, uninstall rate
• What metrics would you monitor?
• • Feature Metrics (Treatment group only)
  • • Group call adoption rate: % of eligible groups who initiated at least one group call
    • Avg call duration, avg participants per call
    • Return usage rate: % of users/groups using the feature again within 7 days
  • Behavioral Change (cross-group comparable)
  • • Message frequency per group — is it declining or rising after feature launch?
    • Active group days — do groups remain active longer?
    • Messenger user retention (esp. for users in active groups)
  • Guardrails
  • • Crash/error rate
    • Report or abuse rate
    • Uninstall rate or notification opt-out
    • Post-call 1–5 rating score (optional survey for subjective feedback)
• How would this test be evaluated?
• • Since control group does not have access to group call, we evaluate impact via indirect metrics
  • • Change in message volume
    • Retention of group chats
    • Messenger user retention among active group members
  • For statistical evaluation
  • • Use confidence intervals or p-values to test behavioral deltas
    • Ensure pre-test power calculation to verify test sensitivity
  • Guardrails must remain stable (e.g. no increase in error rates, uninstalls)
  • Treatment-only metrics like adoption and repeat usage help understand potential, but should not be used to claim A/B test impact directly.

Case Study 2 - Let’s say you’re a Product Data Scientist at Instagram. How would you measure and evaluate the success of the Instagram TV (IGTV) product?

• Who would you roll this out to?
• • I would randomize at the logged-in user level, without distinguishing explicitly between creators and audiences.
  • The eligible population would be active users (e.g., those who posted, liked, or commented at least once in the past 30 days).
  • This captures the natural dynamics between creators and audiences, ensuring a representative experiment population.
  • Later, behavior-based segmentation can help analyze differential impact (e.g., creator adopters vs. non-adopters).
• How would you set up an A/B test for this feature?
• • Unit of randomization: Logged-in user ID.
  • Treatment group: Users can create and view IGTV content. Control group: Users do not have access to IGTV.
  • To handle network contamination
  • • Early-stage MVP: Hard gating — control users cannot view IGTV even through shared links.
    • Later-stage growth: Allow minimal exposure and log all exposure events.
  • Exposure would be tracked for secondary analysis.
  • Primary analysis would be based on Intention-To-Treat (ITT)methodology.
• What metrics would you monitor to measure the success of the IGTV feature?
• • Primary Metrics
  • • Active User Share (users with at least one engagement action)
    • Retention Rate (1-day, 7-day, 14-day retention)
  • Guardrail Metrics
  • • Crash Rate and Report Rate
    • Ads Revenue per User (to detect monetization cannibalization)
  • Feature-Specific Engagement Metrics
  • • IGTV Adoption Rate (among eligible creators)
    • IGTV Impression Rate (audience reach)
    • New Creator Rate (first-time content creators)
  • Platform-Wide Metrics
  • • Active User Share, Engagement Rate, and Retention across Instagram/Facebook.
• How would you evaluate the results of the IGTV experiment?
• • First, validate the experiment setup
  • • Conduct a Sample Ratio Mismatch (SRM) check.
    • Conduct a pre-metrics balance check.
  • Second, apply statistical tests
  • • Identify statistically significant results on primary and guardrail metrics.
  • Third, decision-making:
  • • Use a predefined decision framework.
    • If engagement increases but ad revenue decreases, quantify the trade-off:
    • Estimate engagement uplift → retention uplift → GMV impact.
    • Compare this to ad revenue loss.
  • Fourth, if no significant effects are observed:
  • • Check adoption rate and feature usability issues.
    • Analyze behavior patterns among creators and viewers.
    • Analyze behavior patterns among creators and viewers.
  • Finally, recommendation:
  • • If positive/neutral impact without harming platform health, recommend rollout.
    • Align the decision with long-term strategic goals (e.g., growing the creator ecosystem)