← 회사 목록

Companies

Netflix

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

Overview

Netflix의 데이터 엔지니어 면접에서 가장 독특한 지점은 'Partnerships and Accountability'라는, 다른 회사에는 없는 전용 라운드다. 저자는 이를 일반적인 행동면접이 아니라 매니저의 감독, 정해진 PTO/경비 정책이 없는 문화, 그리고 매 분기 작동하는 'Keeper Test' 안에서 생존할 수 있는지를 검증하는 스트레스 테스트라고 표현한다. Netflix DE 루프는 채용 담당자 통화부터 오퍼까지 보통 4~6주가 걸리며, 보상은 RSU/사이닝 보너스 없이 전액 현금으로 지급된다.

Timeline

# 단계 형식 소요 시간 평가 항목
1 Recruiter Screen Phone call 30 min Role fit, comp expectations, culture fit signal
2 Hiring Manager Screen Video call 45-60 min 기술 깊이 + 문화 정합성(가벼운 잡담이 아니라 실질적인 라운드로 취급해야 함)
3 Technical Phone Screen Video call 60 min SQL + 도메인 지식
4 Onsite Loop 45-60분씩 5-6개 라운드 보통 하루~이틀(가상) SQL, Coding, Data Modeling, System Design, Partnerships, (때로) Cross-Functional
5 Debrief & Decision Internal 3-7 business days 전체 패널 싱크, 하이어링 매니저가 오퍼 여부 결정

Rounds

1 SQL and Data Analysis 온사이트, 45-60분. 공유 에디터에서 라이브 코딩. 인터뷰어가 설명하는 스키마(주로 콘텐츠 시청 데이터, 구독자 이벤트, A/B 테스트 결과)를 대상으로 난이도가 올라가는 2-3문항 출제.

Focus Areas

세션화를 위한 윈도우 함수 — ROW_NUMBER, LAG, LEAD, SUM OVER가 핵심 (Netflix는 세션 데이터 중심)코호트 분석과 리텐션 쿼리 — 예: "1월에 시작한 구독자의 28일 리텐션은?"A/B 테스트 지표 계산 — lift, 통계적 유의성 신호, 세그먼트별 차이시청 이벤트의 세션화 — 시간 간격을 이용해 원시 재생 이벤트를 시청 세션으로 그룹화샘플 주제: 콘텐츠 인게이지먼트, 구독자 라이프사이클, A/B 실험 결과, 이탈 코호트

Sample Question

"You have a play_events table with user_id, content_id, event_type (play, pause, seek, complete), and event_timestamp. Define a viewing session as a sequence of events for one user on one piece of content with no more than a 30-minute gap between consecutive events. Write a query that returns each session with its start time, end time, total active duration, and whether the user completed the content during the session." (세션 경계 계산과 세션별 집계를 동시에 요구하는 문제 — 셀프 조인으로 접근하면 대체로 시간이 부족해진다고 서술됨.)

Solution Approach

LAG로 연속 이벤트 간 간격을 계산하고, 누적합(running sum)으로 세션 ID를 부여한 뒤 GROUP BY로 집계하는 방식이 깔끔한 답으로 제시됨. 코드를 치기 전에 구조를 먼저 말로 설명하는 것이 평가에서 중요하다고 서술됨.

이렇게 말하면 좋다

"I am going to use LAG to find the gap between consecutive events for each user-content pair. Then I will mark a new session every time the gap exceeds 30 minutes. Then I will assign session IDs using a running sum. Then aggregate."

피해야 할 답변

"I would just bring this into Pandas." — Netflix 인터뷰어가 SQL을 요구했다면 SQL을 원하는 것이며, Python으로 회피하려는 태도는 실패 신호로 읽힌다는 서술.

Common Mistakes

  • 셀프 조인으로 세션화를 시도함 — 소규모 데이터에서는 동작하지만 Netflix 규모에서는 무너지며 인터뷰어가 이를 지적함
  • 타임존 논의를 생략함 — Netflix 데이터는 전 세계적이므로 "이 타임스탬프가 UTC인가요?"를 항상 물어야 함
  • 재생 이벤트에 중복이나 순서 뒤바뀜이 있을 수 있다는 점을 간과함 — 코드를 작성하기 전에 데이터 품질 가정을 확인해야 함
2 Coding in Python or Scala 온사이트, 45-60분. 라이브 코딩. 기본값은 Python이며, 팀이 Spark Scala를 많이 쓴다면 Scala도 가능하니 사전에 리크루터에게 확인할 것. 알고리즘 트릭이 아니라 프로덕션급 코드가 기준.

Focus Areas

스트림 스타일 데이터 처리 — 시청 이벤트 스트림을 처리해 세션 요약 생성엣지 케이스가 있는 파일 파싱 — 깨진 레코드, 순서 뒤바뀜, 중복Spark 패턴(PySpark 또는 Spark Scala) — filter, groupBy, 윈도우 함수, join멱등(idempotent) 변환 로직 — 같은 입력을 두 번 넣어도 같은 출력이 나와야 함

Sample Question

"You receive a list of subscription events: subscribe, upgrade, downgrade, cancel, reactivate. Each event has a user_id, event_type, plan_tier, and timestamp. Write a function that returns, for each user, their current plan tier and the total number of days they have been an active subscriber across all their subscription periods." (이벤트 전반에 걸친 상태 관리, 재활성화 처리 — 유저가 여러 구독 기간을 가질 수 있음 — 및 지저분한 이벤트 시퀀스에서도 깨끗한 집계를 만드는 능력을 테스트.

Solution Approach

구독자 라이프사이클 상태 관리 문제로, 재활성화·중복·순서 문제를 명시적으로 처리해야 한다. 코딩에 들어가기 전에 "같은 날 cancel 다음에 subscribe가 오면 하나의 연속 기간인가 두 개인가?"와 같은 모호한 지점을 먼저 확인하는 것이 'Context not Control' 행동으로 평가된다고 서술됨.

이렇게 말하면 좋다

"What if a cancel event is followed by a subscribe event the same day? Is that one continuous period or two?" 이런 질문을 던지는 것 자체가 문화적으로 긍정적인 신호로 읽힌다는 서술.

Common Mistakes

  • 2-3개의 날카로운 확인 질문 없이 바로 코딩에 들어감 — 저자는 이런 질문을 던지는 지원자가 이미 다른 지원자 다수와 차별화된다고 설명하지만, 그 비율 자체는 저자의 주관적 관찰이다.
3 Data Modeling and Architecture 온사이트, 45-60분. 화이트보드(또는 가상 화이트보드). 데이터 모델을 설계하고, 이어서 그 모델을 채우는 파이프라인 논의로 이어지기도 함. 팀이 lean할 때는 모델링과 아키텍처를 한 라운드에 합침.

Focus Areas

스트리밍/콘텐츠 플랫폼을 위한 차원 모델링A/B 테스트 데이터 모델 설계 — 수천 개의 동시 실험을 지원하는 실험 설정/할당/지표 저장 방식시청자 인게이지먼트 데이터 모델 — 세션, 재생, 콘텐츠 상호작용콘텐츠 메타데이터(제목, 출연진, 등급 등이 시간에 따라 변함)를 위한 Slowly Changing Dimensions

Sample Question

"Design the data model behind 'continue watching.' What gets stored, how is it updated, how do we serve it at Netflix scale?" (그 외 A/B 테스트 플랫폼 모델, 실시간+과거 코호트 분석을 모두 지원하는 시청자 인게이지먼트 모델도 샘플 프롬프트로 제시됨.)

Solution Approach

"이 모델이 어떤 쿼리에 응답해야 하는가?"를 먼저 묻고, 그레인은 유스케이스를 따라가야 한다는 원칙을 세운 뒤 그레인을 한 문장으로 명시한다 (예: "이 팩트 테이블의 한 행은 하나의 시청 세션을 나타내며, 30분 이하 간격의 연속 인게이지먼트로 정의된다"). Netflix는 분석용으로 스타 스키마를 선호하며 그 이유를 물어볼 수 있고, Iceberg의 파티셔닝 전략·스키마 진화·히든 파티셔닝을 언급하면 실제로 가점이 된다고 서술됨.

이렇게 말하면 좋다

"What queries does this model need to serve?"를 먼저 묻고, 그레인을 한 문장으로 명시한다.

피해야 할 답변

"I would just denormalize everything." — 트레이드오프에 대한 근거 없이 비정규화를 기본값으로 삼는 것은 주니어 신호로 읽힌다는 서술.

Common Mistakes

  • 그레인 선택에 대한 근거를 방어하지 못함 — 이벤트 그레인/세션 그레인/유저-일 그레인 각각의 용도 차이를 모름
4 System Design at Netflix Scale 온사이트, 60분. 화이트보드. Netflix 실제 유스케이스에 기반한 프롬프트로 전체 데이터 파이프라인을 설계.

Focus Areas

2억 명 이상의 구독자와 하루 수십억 건의 이벤트를 위한 설계 능력Netflix 데이터 스택(Iceberg, Maestro, Flink, Spark, Kafka, S3)에 대한 이해스트리밍 vs 배치 트레이드오프 추론장애 모드, 백필, 스키마 진화 처리

Sample Question

"Design a real-time pipeline that powers the 'continue watching' row. Events come in from 200M+ devices. The data must be available within 60 seconds of a user pausing." (그 외 A/B 테스트 인프라 설계, 국가×타이틀 조합별 일별 콘텐츠 인게이지먼트 파이프라인 설계도 샘플 프롬프트로 제시됨.)

Solution Approach

5단계 프레임워크: (1) 요구사항 수집(5-7분) — 기능/비기능 요구사항, 이벤트 볼륨, 지연 요구사항, 소비 주체, 이 데이터가 어떤 의사결정을 지원하는지. (2) 개략적 추정(3-5분) — 2억 구독자, 1인당 일평균 2시간, 세션당 다수의 재생 이벤트로 하루 수십억 이벤트 규모를 추정하고 설계의 근거로 삼는다. (3) 상위 아키텍처(10-15분) — 수집→스트리밍/배치→저장→서빙 흐름에 Netflix 고유 서비스(Iceberg, Maestro, Flink, Kafka, Spark)를 이름으로 배치한다. (4) 딥다이브(15-20분) — 장애 처리, 백필, 스키마 진화, 데이터 품질, 지연 도착 데이터. (5) 트레이드오프(5분) — 예: "상태 기반 처리와 정확히 한 번(exactly-once) 시맨틱 때문에 Spark Streaming 대신 Flink를 선택했다. 지연 요구사항이 시간 단위로 완화된다면 배치 Spark가 더 단순할 것이다."

이렇게 말하면 좋다

"I would put a Kafka topic here, consumed by a Flink job writing Iceberg tables, with daily Maestro jobs running Spark compaction." — 이런 식으로 Netflix 고유 기술명을 정확히 짚어 말하는 것이 입사 첫날부터 일할 수 있는 사람처럼 들리게 만든다는 서술.

피해야 할 답변

"I would use Snowflake for the warehouse." — Netflix는 Snowflake를 쓰지 않고 Iceberg/Trino/Spark 기반의 자체 데이터 레이크를 운영하므로, 이를 모르고 Snowflake를 언급하면 스택 리서치 부족 신호로 읽힌다는 서술.

Common Mistakes

  • Netflix 고유 기술 스택(Iceberg, Maestro, Flink)을 언급하지 않고 일반론적인 설계만 제시함
  • Iceberg가 Hive의 스몰 파일 문제와 메타데이터 비대화를 어떻게 해결하는지 설명하지 못함
5 Partnerships and Accountability 온사이트, 45-60분. 순수 대화형. 인터뷰어는 보통 시니어 엔지니어나 매니저이며, 3-4개의 시나리오를 제시하고 각각에 대해 후속 질문(follow-up)으로 깊이 파고든다. 분위기는 캐주얼하게 느껴지지만 모든 답변이 채점되고 있다는 점에 주의해야 한다고 서술됨.

Focus Areas

성과가 저조한 동료에게 직접적인 피드백을 줄 수 있는가방어적이지 않게 직접적인 피드백을 받아들일 수 있는가데이터가 준비되지 않았을 때 이해관계자에게 "안 된다"고 말할 수 있는가잘못된 판단을 했을 때 책임을 지는가, 아니면 회피하는가매니지먼트의 감독 없이 스스로 방향을 정할 수 있는가

Sample Question

"Tell me about a time you disagreed with a teammate's approach to a data problem. How did you raise it? What happened?" / "A senior stakeholder asks for a dashboard by Friday. You know the data quality isn't there yet and shipping it would mislead the business. How do you handle it?" / "Tell me about a time you had to give difficult feedback to someone who was underperforming on a shared pipeline." / "Describe a decision you made that turned out to be wrong. What did you do?"

Solution Approach

Netflix 컬처 덱의 네 가지 문화적 패턴을 기준으로 채점된다고 서술됨: Freedom and Responsibility(스스로 판단을 내리고 결과를 책임졌는가, 매니저를 기다리지 않았는가), Context not Control(지시가 아니라 맥락을 구해서 더 나은 결정을 내렸는가), Highly Aligned Loosely Coupled(목표에는 정렬하되 상시 체크인 없이 실행했는가), Radical Candor(어려운 피드백을 직접적이고 친절하게, 설탕발림 없이 전달했는가). 스토리는 구체적이어야 하며, 실제로 사용한 말을 인용하는 것이 핵심이라고 반복 강조됨.

이렇게 말하면 좋다

"I told her, 'this approach is going to break when we hit 10x scale, here is why, and here is what I think we should do instead.'" — 인터뷰어에게 이야기한 정확한 문구를 그대로 인용하는 구체성이 Netflix가 보상하는 요소라고 서술됨.

피해야 할 답변

"I'm a team player and I always find consensus." — 합의를 추구하는 태도는 Netflix 문화와 반대되며, 그들은 의견 충돌을 만들고 에스컬레이션하고 결정을 내릴 수 있는 사람을 찾는다는 서술.

Common Mistakes

  • 추상적으로만 말함 — "저는 협업을 중요시합니다" 같은 말은 무의미하며 구체적인 스토리가 필요함
  • 피드백을 부드럽게 순화함 — "부드럽게 제안했다"는 식의 표현은 갈등 회피형으로 읽힘
  • 잘못된 결과의 책임을 남에게 돌림 — 은근한 책임 전가조차 감점 요인
  • 매니저에게 에스컬레이션했다고 답함 — Netflix 문화에서는 지원자 본인이 의사결정자여야 함
6 Cross-Functional Partner Round (일부 루프에만 포함) 온사이트, 저자에 따르면 Netflix DE 루프의 약 절반 정도에 포함된다고 서술됨(정확한 통계라기보다 저자의 관찰). Partnerships 라운드와 형식이 유사한 순수 대화형·시나리오 기반 라운드로, 데이터 사이언티스트·PM·플랫폼 파트너 중 한 명이 인터뷰어로 참여.

Focus Areas

직무 간(cross-role) 협업 방식요구사항의 모호함을 다루는 방식비엔지니어링 파트너와 스코프를 협상하는 방식직접적인 보고 관계가 없는 사람들과 신뢰를 쌓는 방식

Culture — Netflix Culture Deck의 5대 문화 패턴 (Keeper Test 포함)

원문에 명시적인 수치 가중치는 없으나, 저자는 이 문화 패턴들이 Partnerships 라운드뿐 아니라 모든 라운드에서 관찰된다고 서술하며, 문화 덱을 읽지 않는 것이 Netflix에서 가장 큰 필터링 요인(the number one filter)이라고 표현한다.

Netflix는 자사 컬처 덱을 공개적으로 게시하며, 이를 정독하지 않고 면접에 들어가는 것은 지원자가 실제로 이 회사에서 일하고 싶어하지 않는다는 신호로 읽힌다고 저자는 강조한다. 다섯 가지 패턴은 다음과 같다: (1) Freedom and Responsibility — 규칙이 없는 대신 전적인 책임을 진다. 매니저의 지시 없이 스스로 움직인 경험담이 필요하다. (2) Context, not Control — 리더는 지시가 아니라 맥락을 제공한다. 맥락을 구해서 스스로 판단을 내리는 태도가 중요하다. (3) Highly Aligned, Loosely Coupled — 팀은 전략에 정렬한 뒤 독립적으로 실행한다. 목표를 받아 스스로 끝까지 끌고 갈 수 있어야 한다. (4) Pay Top of Market — Netflix의 보상 철학으로, 협상 방식에도 영향을 준다. (5) The Keeper Test — "이 사람이 떠나려 할 때 붙잡기 위해 싸울 것인가?"라는 기준이며 저자는 그 바가 높다고 서술한다. 지원자의 스토리는 팀이 붙잡고 싶어할 만한 사람처럼 들려야 한다.

Prep Strategy

Key Takeaways