← 회사 목록

Companies

Meta

Meta Data Engineer Interview Questions & Process (2026) — docs/Meta Data Engineer Interview Questions & Process (2026).pdf

Overview

Meta(Facebook)의 데이터 엔지니어 면접은 별도의 행동면접(behavioral) 라운드가 없다는 점이 가장 큰 특징이다. 대신 SQL, 데이터 모델링, 프로덕트 센스, Python이 하나의 45분 라운드 안에서 동시에 뒤섞여 평가되며, 지원자는 한 라운드 안에서 여러 역량을 동시에 증명해야 한다. 저자는 이를 '블렌디드(blended) 포맷'이라 부르며, Amazon보다 느리고 Google보다는 빠른 4~10주짜리 프로세스로 설명한다.

Timeline

# 단계 형식 소요 시간 평가 항목
1 Recruiter Screen Phone call 30 min Role fit, level calibration, salary, visa
2 Technical Phone Screen Video call 60 min SQL, Python, product, modeling 4개 영역에 걸친 약 10개의 빠른 문답
3 Virtual Onsite 45분씩 4개 라운드 약 3시간 SQL, Data Modeling, Product Sense, Coding + Pipeline
4 Hiring Committee Review Internal 1-2 weeks 모든 인터뷰어 피드백을 루브릭 기준으로 종합 채점
5 Team Matching Light interviews 1-2 weeks 관심 있는 팀이 여러 곳일 경우 팀 매칭
6 Offer & Negotiation Recruiter 1 week 보상위원회(comp committee)가 최종 금액 확정

Rounds

1 SQL and Query Optimization 온사이트, 45-60분. 인터뷰어가 제공한 샘플 스키마를 대상으로 공유 에디터에서 라이브 코딩. 난이도가 올라가는 2~3문항 출제.

Focus Areas

고급 윈도우 함수 — ROW_NUMBER/RANK는 기본이고 NTILE(퍼센타일 버킷팅), LAG/LEAD(시퀀스 비교), PERCENT_RANK(분포 분석), SUM OVER(누적 지표)까지리텐션 코호트 쿼리 — Day 1/7/28 리텐션, 주간 코호트퍼널 분석 — 셀프 조인 또는 이벤트 배열을 활용한 다단계 드롭오프 분석DAU, MAU, DAU/MAU 비율 용어에 대한 확실한 이해A/B 테스트 지표 계산 — control/treatment 테이블에서 신뢰구간을 포함한 lift 계산

Sample Question

"You have an events table with user_id, event_name, and event_timestamp. Compute the 7-day rolling DAU for the last 90 days. Then compute the DAU/MAU ratio as a stickiness metric. Then identify the top 100 users by stickiness." (하나의 프롬프트 안에 세 개의 쿼리가 중첩된 구조 — 대부분은 첫 번째는 작성하고, 절반 정도가 두 번째까지 작성하며, 세 번째는 'stickiness'를 유저 단위에서 어떻게 정의할지부터 스스로 정해야 하는 프로덕트 센스 영역이라고 서술됨.)

Solution Approach

쿼리를 바로 작성하지 않고 먼저 'stickiness'와 같은 모호한 지표를 어떻게 정의할지 인터뷰어에게 확인한 뒤 작성한다. 정의를 말로 설명하는 과정 자체가 평가의 절반을 차지한다고 서술됨.

이렇게 말하면 좋다

"I am thinking of stickiness here as the number of active days in a 28-day window divided by 28. Is that the definition you want, or do you have a different one in mind?" 이후 쿼리 작성.

피해야 할 답변

"I would compute it in pandas, this is a lot of SQL." — Meta는 Presto와 Spark SQL 위에서 동작하므로, SQL로 풀지 못하면 Meta에서 일할 수 없다고 판단된다는 서술.

Common Mistakes

  • 윈도우 함수 문법을 각 함수가 언제 적합한지 이해하지 못한 채 암기 — "왜 RANK이고 DENSE_RANK가 아닌가?"에 답하지 못함
  • 최적화 대화(파티션 프루닝, 프레디케이트 푸시다운, 브로드캐스트 조인)를 생략함 — Meta는 페타바이트 규모 데이터를 다룸
  • NULL 케이스를 처리하지 않음 — "윈도우 내 이벤트가 0건인 유저는 어떻게 반환되어야 하나?"를 스스로 묻지 않음
2 Data Modeling and ETL Design 온사이트, 45-60분. 화이트보드(또는 가상 화이트보드). Meta 제품 하나를 주고 그 데이터 모델과 ETL 파이프라인 설계를 요구.

Focus Areas

스타 스키마를 처음부터 설계 — 팩트 테이블/디멘션 테이블과 그 관계그레인(grain) 결정 — "이 팩트 테이블의 한 행은 무엇을 의미하는가?"에 한 문장으로 답할 수 있어야 함Slowly Changing Dimensions — Type 1/2/3와 각각이 적합한 상황팩트 테이블 유형 — transactional, periodic snapshot, accumulating snapshot쿼리 성능을 위한 비정규화 vs 저장 비용 사이의 트레이드오프

Sample Question

"Design a data model for Facebook Marketplace. We want to answer: how many listings does each seller have, how many sold in the last 30 days, what is the average sale price, and how does seller performance change over time? Walk me through your fact tables, dimensions, and grain." (주니어 답변은 모든 것을 리스팅 레벨 팩트 테이블 하나에 담으려 하고, 강한 답변은 리스팅/트랜잭션/셀러 일별 스냅샷이 서로 다른 세 가지 그레인임을 인식해 세 개의 팩트 테이블로 분리한다고 서술됨.)

Solution Approach

그림을 그리기 전에 먼저 답해야 할 질문들을 확인한다 — 요구된 지표들이 리스팅/트랜잭션/셀러 일별 스냅샷이라는 세 개의 서로 다른 그레인에 걸쳐 있음을 인식하고 그레인별로 팩트 테이블을 분리해 설계한다.

이렇게 말하면 좋다

"Before I draw anything, I want to confirm the questions we need to answer. The metrics you described span three grains: listing level, transaction level, and seller daily snapshot. I am going to design three fact tables to keep the grains clean." 이후 스케치.

피해야 할 답변

"I would just put everything in one big table and pivot." — Meta는 Presto/Spark 위에서 차원 모델을 운영하므로, 원빅테이블식 사고는 프로덕션 분석 웨어하우스를 구축해본 적이 없다는 신호로 읽힌다는 서술.

Common Mistakes

  • 그레인 질문을 건너뜀 — 인터뷰어가 팩트 테이블의 한 행이 무엇을 뜻하는지 알 수 없다면 모델이 잘못된 것
  • 모든 디멘션에 기본적으로 Type 1 SCD를 적용 — Meta는 과거 이력 분석을 중시하므로 대부분은 Type 2가 맞음
  • 모델을 프로덕트 의사결정과 연결하지 않음 — "30일 롤링 매출을 위한 셀러 대시보드 쿼리를 지원하는 디멘션"이라는 설명이 단순히 "이건 디멘션입니다"보다 낫다는 서술
3 Quantitative Analysis / Product Sense 온사이트, 45-60분. 대화형(conversational). 프로덕트 시나리오를 제시받고 지표를 어떻게 측정할지, 어떤 지표를 정의할지, 그 지표를 계산하는 SQL을 작성하고, 결과를 해석하는 과정을 진행.

Focus Areas

프로덕트에 실제로 중요한 것을 포착하는 지표를 정의할 수 있는가경쟁하는 지표들 사이에서 우선순위를 정할 수 있는가방금 정의한 지표를 계산하는 SQL을 작성할 수 있는가숫자를 맥락 안에서 해석할 수 있는가 (예: 5% 하락이 큰 것인가? 무엇과 비교해서?)PM이 존중할 만한 방식으로 다음 단계를 제안할 수 있는가

Sample Question

"You are working with a PM on Facebook Marketplace. They want to know if Marketplace is healthy. Define the metrics. Prioritize them. Write the SQL for the top one. Then tell me what you would do if it dropped 10% next week." (사실상 네 개의 질문이 하나로 합쳐진 문제.)

Solution Approach

4단계 프레임워크: (1) 노스스타 지표와 보조 지표 정의 — 예: 완료된 거래 수를 노스스타로, 신규 리스팅 수/리스팅→메시지 전환율/메시지→거래 전환율/30일 셀러 리텐션을 보조 지표로. (2) 우선순위화 — 선행지표(리스팅→메시지 전환율)를 매일 모니터링. (3) 실제로 SQL을 작성 — 이 단계를 건너뛰고 앞의 두 단계만 말로 때우는 지원자가 많다고 서술됨. (4) 해석과 제안 — 하락이 균일한지 특정 세그먼트에 집중되어 있는지 지역/카테고리/구매자 코호트별로 슬라이스하고, 최근 14일 내 제품 변경 사항이 있었는지 확인.

이렇게 말하면 좋다

"Before I define metrics, let me restate the goal. We want to measure health, which means engagement, retention, and revenue. Different metrics map to different parts of health, so I am going to pick one for each."

피해야 할 답변

"I'd just look at DAU." — 대부분의 지원자가 기본값으로 삼는 답변이며, Meta는 DAU가 자사 제품 절반에서 부적절한 지표임을 아는 사람을 채용한다고 서술됨.

Common Mistakes

  • 지표를 정의하기 전에 바로 SQL로 뛰어듦 — 인터뷰어는 먼저 프로덕트 사고를 보고 싶어함
  • 우선순위 없이 12개의 지표를 나열함 — DE는 PM이 아니라 'PM처럼 생각할 수 있는 DE'이므로 상위 1~2개를 골라야 함
  • 지표를 의사결정과 연결하지 않음 — 지표 이름을 붙이기 전에 "이 지표로 무엇을 결정할 수 있는가?"를 스스로 물어야 함
4 Coding (Python) and Pipeline Design 온사이트, 45-60분. Python 라이브 코딩, 때로 파이프라인 오케스트레이션 논의와 결합. 저자에 따르면 난이도는 중간 수준이며 Meta는 Google식 알고리즘 위주 DE 면접을 밀어붙이지 않는다고 서술됨.

Focus Areas

실무적인 데이터 엔지니어링 Python — 파일 파싱, 딕셔너리 변환, 리스트 컴프리헨션, 데이터클래스멱등(idempotent) ETL 로직 — 안전하게 재실행 가능한 함수에러 핸들링과 재시도해당되는 경우 Pandas 또는 PySpark 패턴오케스트레이션 사고 — 스케줄링, 실패 처리, 백필 방법

Sample Question

"You receive a stream of user events as JSON records. Each record has user_id, event_type, event_timestamp, and a properties dict that varies by event_type. Write a function that produces a flat record per user per day with counts per event_type. Some records are out of order. Some are duplicates. The function should be idempotent for backfill."

Solution Approach

상태 관리, 멱등성, 엣지 케이스 처리를 테스트하는 문제. 강한 답변은 타임스탬프 기준 정렬 후 (user_id, event_id) 기준 중복 제거를 적용해, 입력 순서와 무관하게 안정적인 출력을 만드는 방식이라고 서술됨.

이렇게 말하면 좋다

"Before I write anything, let me confirm a few things. The properties dict varies by event_type. Should I flatten it, or just count? Also, when you say idempotent, do you mean re-running on the same input window produces the same output, or do you mean the function handles late-arriving data gracefully?" 이후 코드 작성.

피해야 할 답변

"This is basically a Spark job, can I just describe the DataFrame transformations?" — Meta는 실제 Python 코드 작성을 원하며, Spark 잡을 말로만 설명하는 것은 실패로 간주된다는 서술.

Common Mistakes

  • 중복을 처리하지 않음 — 입력에 중복이 있을 때 이중 카운트되는 단일 패스 집계를 작성하는 경우가 많음
  • 오케스트레이션 대화를 생략함 — 코딩할 시간이 없더라도 언급은 해야 함 (예: "매일 실행되는 Airflow DAG로, 날짜별 파티션에 상류 추출 태스크의 재시도 정책을 둔다")
  • 컴프리헨션이 더 깔끔한 곳에서 명령형 코드를 작성 — Meta 리뷰어는 Pythonic한 코드를 중시함

Culture — Meta의 5개 가치(별도 행동면접 라운드 없이 모든 기술 라운드 안에서 평가됨)

Meta는 별도의 행동면접 라운드가 없는 대신, SQL을 작성하는 동안, 데이터 모델을 스케치하는 동안 다섯 가지 가치를 상시 관찰한다고 서술됨: (1) Move Fast — 마감 안에 동작하는 해법을 내놓고 개선할 수 있는가, (2) Be Bold — 모호하고 임팩트가 큰 문제를 자발적으로 맡는가(인터뷰어가 제시한 더 어려운 버전의 문제를 받아들이는 것으로 드러남), (3) Focus on Impact — 모든 기술적 결정을 비즈니스 성과와 연결하는가, (4) Be Open — 실시간 피드백을 수용하고 필요하면 반박할 수 있는가(인터뷰어가 반박했을 때 근거로 방어하거나 우아하게 의견을 바꾸는 것으로 드러남), (5) Build Social Value — 자신의 데이터 작업이 제품과 사용자에게 미치는 영향을 이해하는가. "Tell me about a time" 식의 질문은 없으며, 기술 작업을 수행하는 동안 Meta 엔지니어답게 행동하는지가 관찰된다.

Prep Strategy

Key Takeaways