Companies

Google

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

Overview

Google의 Data Engineer 채용 프로세스는 리크루터 스크린부터 오퍼까지 보통 6~12주가 걸리며, 다른 빅테크 대비 가장 길고 불투명한 축에 속한다는 것이 필자의 관찰이다. 지원자 본인이 만나본 적 없는 Hiring Committee(HC)가 인터뷰어들의 서면 피드백만으로 최종 합격 여부를 결정하고, 그 평가에는 기술 역량뿐 아니라 'Googleyness'라 불리는 문화 적합성 축이 상당한 비중으로 반영된다. 합격 후에도 특정 팀이 아니라 '구글 소속'으로 채용되어 팀 매칭 단계를 별도로 거친다.

Hiring Committee(HC)가 인터뷰어 본인이 아니라 다른 팀 시니어 엔지니어들로 구성되어, 서면 피드백 패킷만 보고 채용 여부를 투표로 결정한다.
'Googleyness'라는 문화 평가 축이 존재하며, 필자의 관찰로는 전체 평가에서 상당한 비중을 차지해 기술 점수가 좋아도 이 축이 약하면 HC 단계에서 탈락할 수 있다.
합격 후 특정 팀이 아니라 'Google 소속'으로 채용되므로, HC 통과 이후 별도의 팀 매칭 단계(매니저 인터뷰)를 거쳐야 하고 매칭이 안 되면 오퍼가 무기한 지연될 수 있다.
다른 FAANG 스타일 DE 인터뷰보다 알고리즘(해시맵, 트리, 힙, 그래프 등 CS 기본기) 비중이 높다.
RSU 베스팅이 1년차에 약 33%로 집중되는(front-loaded) 구조라, 연차별 총보상(TC) 체감이 다른 회사와 다르다.

Timeline

#	단계	형식	소요 시간	평가 항목
1	Recruiter Screen	Phone call	30 min	Role fit, level calibration, basic signal
2	Phone Screen 1	Video call	45 min	SQL + data concepts, light coding
3	Phone Screen 2 (optional)	Video call	45 min	Borderline 또는 시니어 지원자 대상 추가 검증
4	Onsite Loop	4~5 rounds, 45 min each	1 day (분산 가능)	SQL, Coding, DE Domain, System Design, Googleyness
5	Hiring Committee Review	Internal (지원자 비참여)	2~4주	패킷 리뷰, hire/no-hire 투표
6	Team Matching	매니저 인터뷰(콜)	1~4주	특정 팀과의 매칭
7	Offer & Comp Committee	Internal	약 1주	최종 보상 패키지 확정

Rounds

1 SQL and Data Analysis 공유 에디터에서 라이브 코딩, 난이도가 올라가는 2문항

Focus Areas

복잡한 다중 조인(필터링·집계 포함)윈도우 함수(ROW_NUMBER, RANK, LAG, LEAD, SUM OVER)서브쿼리와 CTE(가끔 재귀 CTE)BigQuery 특화 패턴(UNNEST, STRUCT, ARRAY, 파티션/클러스터링 인지)쿼리 최적화(실행 계획에 대한 추론)

Sample Question

사용자 검색 쿼리 테이블(user_id, query_text, query_timestamp)이 있다. 세션 간 비활동 30분을 기준으로 세션을 나눌 때, 서로 다른 두 세션에서 동일한 쿼리를 검색한 사용자를 찾아 user_id, 반복된 쿼리, 세션 간 간격(일 단위)을 반환하라.

Solution Approach

LAG와 타임스탬프 차이로 세션을 나누는 CTE를 먼저 만들고, 사용자·쿼리로 그룹핑한 뒤 반복된 것만 필터링하는 방식으로 접근한다. 코드를 바로 치기 전에 세션화 로직을 먼저 말로 설명하는 것이 채점 포인트다.

이렇게 말하면 좋다

"먼저 LAG로 연속된 쿼리 사이 간격을 계산해 세션을 나누겠습니다. 30분을 넘으면 새 세션으로 봅니다."라고 구조를 먼저 설명한 뒤 코드를 작성한다.

피해야 할 답변

"이건 Python 스크립트로 짜서 pandas로 가져오겠습니다" — Google은 BigQuery 스케일에서 동작하므로 SQL이 기대되는 매체다.

Common Mistakes

CTE로 충분히 명확하게 표현할 수 있는데 중첩 서브쿼리를 남발한다
BigQuery 관점(중첩/반복 필드가 있으면 UNNEST)을 놓친다
쿼리를 다시 쓰지 않더라도 파티션 컬럼·클러스터링 키 등 최적화를 언급하지 않는다

2 Coding in Python or Java 라이브 코딩, Python이 기본이며 Java에 더 강하면 허용

Focus Areas

해시맵(중복 제거), 힙(top-K), 트리(파티셔닝 로직) 등 DE 맥락의 자료구조'데이터 파이프라인 설계'가 아니라 실제 알고리즘 문제깔끔하고 관용적인 Python, 엣지 케이스 처리

Sample Question

(user_id, event_timestamp, event_type) 형태의 스트림을 받는다. 임의 시점에 최근 1시간 동안 이벤트 수 기준 top K 사용자를 반환할 수 있는 클래스를 구현하라. 스트림은 하루 수백만 건 규모일 수 있다.

Solution Approach

슬라이딩 윈도우 + top-K 문제로, 시간 윈도우 관리에는 deque류 구조를, 랭킹에는 크기 K의 힙을 사용해 두 요소를 결합해야 한다.

이렇게 말하면 좋다

"윈도잉과 랭킹 두 부분으로 나뉩니다. 윈도잉은 타임스탬프로 인덱싱된 deque로, 랭킹은 크기 K의 최소 힙으로 처리하겠습니다. 코드 작성 전에 시간 복잡도를 먼저 생각해보겠습니다."

피해야 할 답변

"이건 그냥 BigQuery에 넣고 SQL로 돌리겠습니다" — 프로덕션에서는 맞는 답일 수 있어도 이 라운드에서는 알고리즘 구현 능력을 보는 것이므로 오답으로 취급된다.

Common Mistakes

복잡도 분석(O(N) 추론)을 생략한다
자료구조를 스케치하지 않고 바로 코드로 들어간다
빈 스트림, 동점(tie), K가 사용자 수보다 큰 경우 등 엣지 케이스를 놓친다

3 Data Engineering Domain Knowledge 토론 형식 — '시스템을 설계하라'보다 '개념을 설명하고 추론하라'에 가까움

Focus Areas

배치 vs 스트리밍 트레이드오프와 선택 기준파이프라인 아키텍처(Lambda vs Kappa)와 적용 시점데이터 모델링(스타 스키마, 스노우플레이크, 비정규화 트레이드오프)데이터 웨어하우징 개념(파티셔닝, 클러스터링, 컬럼형 저장)스키마 진화(컬럼 추가/타입 변경/필드 제거 처리)데이터 품질 검증 및 운영 중 불량 데이터 탐지 방법

Sample Question

일별 매출 리포팅 파이프라인을 어떻게 만들지 설명하라. 그 다음 이를 스트리밍 우선 아키텍처로 마이그레이션한다면 무엇이 바뀌고, 무엇이 그대로이며, 무엇이 더 어려워지는지 설명하라.

Solution Approach

시스템 설계가 아닌 도메인 추론 질문이다. 배치와 스트리밍 패러다임을 비교하며 exactly-once 시맨틱스, 워터마크, 지연 도착 데이터, 운영상 트레이드오프를 언급해야 한다.

이렇게 말하면 좋다

"배치 버전은 하루 종료 시점에 Spark 잡으로 원시 이벤트를 날짜별 파티션 매출 팩트 테이블로 집계합니다. 스트리밍으로 가면 워터마크, 지연 이벤트, 멱등 쓰기를 고려해야 하고, 이벤트가 순서 없이 도착할 때의 정확성이 가장 어려운 부분입니다."

피해야 할 답변

"스트리밍은 그냥 더 빠른 배치일 뿐입니다" — 스트리밍은 정확성 모델 자체가 다르며, 이렇게 말하면 실제로 스트리밍 시스템을 구축해본 적이 없다는 신호로 읽힌다.

Common Mistakes

이 라운드를 시스템 설계 라운드로 착각해 바로 박스를 그리기 시작한다 — 인터뷰어는 도식이 아니라 추론을 원한다
운영 관점(파이프라인 장애, 백필, 스키마 변경 대응)을 놓친다

4 System Design 화이트보드(또는 가상 화이트보드) — 프롬프트 기반 데이터 파이프라인/분석 시스템 설계

Focus Areas

규모(scale)에서의 트레이드오프 추론설계 전 명확화 질문을 던지는지GCP 서비스를 이름으로 정확히 알고 있는지복잡함보다 단순함을 선호하는지

Sample Question

"YouTube 시청 시간 분석용 데이터 파이프라인을 설계하라" / "검색 쿼리 분석 플랫폼의 데이터 인프라를 설계하라" / "사용자 행동 기반 맞춤 광고 타겟팅을 지원하는 시스템을 설계하라"

Solution Approach

5~7분간 요구사항(데이터량, 지연 목표, 소비 주체)을 명확화하고, 3~5분 개략적 용량 추정 후, 10~15분 상위 아키텍처를 Ingestion→Processing→Storage→Serving 흐름으로 스케치하며 GCP 서비스명을 명시한다. 이후 인터뷰어가 지목한 부분을 10~15분 심화하고, 마지막 5분은 트레이드오프(예: Dataflow vs Dataproc)를 설명한다. 알아둘 핵심 GCP 서비스: BigQuery(웨어하우징 — 파티셔닝/클러스터링/슬롯 할당/구체화 뷰), Dataflow(Apache Beam, 스트리밍·배치 ETL), Pub/Sub(메시징·스트리밍 수집), Composer(managed Airflow), Cloud Storage(데이터 레이크), Dataproc(managed Spark), Bigtable(저지연 키-값 조회), Looker(서빙).

이렇게 말하면 좋다

"데이터 볼륨은 얼마나 되나요? 지연 목표는? 누가 얼마나 자주 이 데이터를 소비하나요?"로 5~7분간 요구사항부터 확인한다.

피해야 할 답변

"배치와 스트리밍 파이프라인을 분리한 Lambda 아키텍처를 만들겠습니다" — 예전엔 기본 답이었지만, Beam 통합 모델 등장 이후 Google은 이를 선호하지 않는다는 것이 필자의 관찰이다. 물어보면 Lambda를 언급하되, 기본안으로는 통합 Beam(Kappa 스타일)을 제안하는 편이 낫다.

Common Mistakes

과잉 설계 — 동일한 결과를 내는 5개 컴포넌트 설계보다 12개 컴포넌트 설계가 오히려 낮은 점수를 받는다
비용 최적화(슬롯 관리, 파티션 프루닝, 스토리지 라이프사이클 정책)를 언급하지 않는다
장애 모드(Dataflow 지연, Pub/Sub 백프레셔 등)를 다루지 않는다

5 Googleyness and Leadership 행동 인터뷰이지만 Google 특유의 색채 — 인터뷰어가 3~5개의 스토리를 후속 질문과 함께 물어봄

Focus Areas

지적 겸손(intellectual humility)모호함에 대한 편안함(comfort with ambiguity)성실함/책임감(conscientiousness)협업(collaboration)

Sample Question

"요구사항이 불명확한 프로젝트를 진행한 경험과 어떻게 범위를 정했는지 말해달라" / "시간 압박 속에서 완전히 새로운 것을 배워야 했던 경험" / "기술적 접근에 대해 동료와 의견이 갈렸던 경험과 해결 과정" / "본인이 틀렸던 경험과 무엇이 생각을 바꿨는지"

Solution Approach

많은 지원자가 '소프트한 라운드'로 오해해 준비를 소홀히 하지만, 실제로는 HC에 전달되는 노트가 강한 기술 점수를 뒤집을 수 있는 라운드다. 특히 "틀렸던 경험"에 "별로 크게 틀린 적이 없다"거나 지나치게 사소한 예시로 답하면 좋은 평가를 받기 어렵다는 것이 필자의 관찰이다. 실제 이해관계가 걸린 기술적/판단적 실수를 골라, 어떻게 깨달았고 무엇을 바꿨는지까지 이야기하는 편이 강한 답변으로 여겨진다.

Common Mistakes

GCP 서비스를 다 안다는 식의 과장된 자신감 — 모르는 부분을 솔직히 인정하는 편이 더 정직한 신호로 읽힌다
인터뷰어가 요구사항 변경을 제시했을 때 원래 설계를 고집하며 유연하게 대응하지 못한다
혼자 밀어붙인 경험만 이야기해 협업 신호가 약하게 비친다

Culture — Googleyness

필자의 관찰로는 전체 평가에서 대략 20~30% 비중을 차지하는 것으로 보이며(원문 여러 곳에서 20%와 30%가 혼재해 언급됨 — 정확한 공식 수치라기보다 저자의 체감치로 이해해야 한다), 기술 라운드 점수가 좋아도 이 신호가 약하면 HC 단계에서 뒤집힐 수 있다.

체크리스트가 아니라 인터뷰어가 피드백 패킷에 기록하는 일종의 '느낌'이며, HC가 이 노트를 근거로 동점 상황을 가른다는 것이 필자의 설명이다. 핵심은 네 가지 특성으로 요약된다: 지적 겸손(모른다고 인정하고 어떻게 알아낼지 말하는 태도), 모호함에 대한 편안함(불분명한 문제를 스스로 스코핑하는 능력), 성실함/책임감(요청받지 않아도 테스트를 추가하고 문서를 쓰고 데이터 품질을 챙기는 태도), 협업(합의를 이끌어내는 방식으로 의사결정에 참여하는 태도).

Prep Strategy

1주차 — 알고리즘과 SQL: 하루 3~4개 LeetCode medium(해시맵, 힙, 슬라이딩 윈도우, 투 포인터 위주), 하루 3~4개 SQL 문제, BigQuery 특화 문법(UNNEST, STRUCT, ARRAY, 파티션 표현식) 숙달.
2주차 — 시스템 설계와 GCP: 45분 타이머로 주 2~3개 DE 시스템 설계 문제 연습, BigQuery 슬롯/Dataflow 스트리밍 모델/Composer DAG 패턴/Pub/Sub 보장 수준 등 GCP 데이터 서비스 아키텍처를 깊이 학습, 매일 데이터 모델링(스타 스키마 + 파티셔닝 전략) 1건 연습.
3주차 — Googleyness와 도메인 지식: 2개 이상의 특성에 매핑되는 5~7개 스토리 작성(각 발화 시 2~3분 분량), 특히 '틀렸던 경험' 질문에 대한 강한 스토리 2개 확보, 배치 vs 스트리밍/스키마 진화/데이터 품질/SLA 관리 등 도메인 추론 주제 복습, 이번 주 중 Googleyness 라운드를 모의 진행하며 강하게 반박받아보기.
4주차 — 풀 모의면접과 마무리: 5라운드 풀 루프를 한 번 모의로 진행해 에너지 관리 연습, 가장 약한 영역(대개 알고리즘 또는 Googleyness)을 집중 보완, 인터뷰어에게 던질 질문 3~4개 준비, 면접 전날은 새 내용을 벼락치기하지 말고 스토리만 한 번 다시 읽고 충분히 수면.
준비 기간이 4주 미만이면 위 일정을 압축하고, 8~12주 이상 여유가 있다면 풀 모의면접을 2회 진행하며 약점 1가지를 확실히 보완하는 데 시간을 쓴다.
GCP 서비스명을 암기하는 것보다, 왜 그 서비스를 다른 대안(예: BigQuery vs Snowflake) 대신 선택하는지 원리 수준으로 설명할 수 있는 것이 더 중요하다는 것이 필자의 조언이다.

Key Takeaways

Google DE 인터뷰는 CS 기본기(알고리즘), GCP 네이티브 시스템 설계 추론, 그리고 전 라운드에 걸쳐 흐르는 Googleyness 신호 세 가지를 함께 평가한다.
많은 지원자가 기술 준비에 치중하고 문화 축(Googleyness)을 과소평가하는데, 필자의 관찰로는 이것이 HC 단계에서 강한 기술 점수를 뒤집는 가장 흔한 원인이다.
"틀렸던 경험을 말해달라"는 질문에 답할 좋은 스토리가 없다면 지금 바로 하나 만들어두는 것이 Googleyness 준비에서 가장 레버리지가 큰 작업이다.
합격 후에도 팀 매칭 단계가 남아 있으므로, 관심 분야를 구체적으로 리크루터에게 전달하며 능동적으로 참여해야 한다 — 막연한 관심 표명은 매칭이 느려지는 경향이 있다는 것이 필자의 관찰이다.
6~12주라는 긴 타임라인을 과소평가하지 말 것 — 급하게 오퍼가 필요한 상황이라면 다른 회사의 경쟁 오퍼를 받고 중도 이탈하게 되는 경우가 흔하다고 저자는 지적한다.
보상 협상에서는 리크루터를 결정권자가 아니라 조력자로 대하고, 경쟁 오퍼 등 근거 자료를 제공해 comp committee 설득을 돕도록 하는 편이 유리하다.