← 회사 목록

Companies

Amazon

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

Overview

Amazon의 Data Engineer 채용 프로세스는 리크루터 콜부터 오퍼까지 보통 3~6주로, 필자의 관찰상 Google(6~12주)이나 Meta(4~10주)보다는 빠르지만 DoorDash나 Stripe보다는 느린 편이다. 가장 큰 특징은 Leadership Principles(LP)가 기술 라운드를 포함한 모든 라운드에서 함께 평가된다는 점으로, 필자는 대략 절반의 평가가 기술 외적인(LP) 요소에서 결정된다고 본다. SQL과 시스템 설계가 깔끔해도 자신의 작업에 대해 깊이 있게(Dive Deep) 이야기하지 못하면 탈락하는 경우가 흔하다고 저자는 지적한다.

Timeline

# 단계 형식 소요 시간 평가 항목
1 Recruiter Screen Phone call 30 min Role fit, salary, visa, basic LP screen
2 Online Assessment HackerRank 60~90 min 코딩 문제 2개, 가끔 SQL 포함
3 Phone Screen Video call 60 min 기술 문제 1개 + LP 심층 질문
4 Onsite Loop 4~5 rounds, 45~60 min each 1 day (분산 가능) SQL, Coding, System Design, Behavioral, Hiring Manager
5 Debrief & Decision Internal — 전체 인터뷰어 + Bar Raiser 싱크 영업일 3~5일 종합 hire/no-hire 결정

Rounds

1 SQL and Data Manipulation 공유 에디터에서 라이브 코딩, 인터뷰어가 제공한 샘플 스키마 기준 난이도가 올라가는 2~3문항

Focus Areas

윈도우 함수(ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD) — RANK와 DENSE_RANK 차이를 즉답할 수 있어야 함CTE와 재귀 CTE(직원-매니저 트리, 카테고리 계층 등 계층 데이터)쿼리 최적화(인덱스, 파티션 프루닝, 프레디케이트 푸시다운)중복 제거 패턴 — '사용자별 최신 레코드 찾기' 유형이 자주 출제됨고객 주문 분석, 셀러 성과 지표, 재고 파이프라인 데이터, 클릭스트림 세션화 등 실제 제품 데이터 소재

Sample Question

고객 주문 테이블이 있다. 고객별로 가장 최근에서 두 번째로 최근인 주문을 찾아라. 주문이 1건뿐인 고객은 제외하라. 그 다음 남은 각 고객에 대해 가장 최근 주문과 두 번째 최근 주문 사이의 간격(일 단위)을 계산하라.

Solution Approach

고객별로 파티션한 ROW_NUMBER로 순위를 매긴 CTE를 만들어 순위 1과 2만 필터링한 뒤, 셀프 조인하거나 피벗하는 방식으로 접근한다. SQL 문법만 암기하고 쿼리 구조 자체를 고민해보지 않은 지원자를 걸러내는 유형의 문제다.

이렇게 말하면 좋다

"여기서는 순위로 필터링해야 하니 ROW_NUMBER를 쓰겠습니다. RANK는 동점 처리 때문에 이 중복 제거 목적에는 맞지 않습니다."처럼 사고 과정을 코딩 내내 계속 말로 설명한다. 완벽한 SQL을 조용히 작성하기만 하면 사고 과정을 평가할 수 없어 'no hire'로 이어질 수 있다는 것이 필자의 강조점이다.

피해야 할 답변

"보통 이런 건 ChatGPT를 씁니다" 또는 "저는 SQL을 잘 안 쓰고 저희 팀은 ORM을 씁니다" — DE 역할에 맞지 않는다는 신호로 읽힌다.

Common Mistakes

  • CTE로 더 명확하게 표현할 수 있는데 중첩 서브쿼리를 남발한다 — CTE가 더 빠른 것은 아니지만 가독성 때문에 선호된다
  • NULL 케이스를 처리하지 않는다 — 코드를 쓰기 전에 '주문이 없는 사용자는 어떻게 반환되어야 하나요?'를 먼저 물어야 한다
  • 시간이 없어 쿼리를 다시 쓰지 못하더라도 최적화 방향에 대한 논의 자체를 생략한다
2 Coding in Python 라이브 코딩, Python이 기본(일부 인터뷰어는 Java/Scala도 허용하나 Python 선호)

Focus Areas

실전 데이터 엔지니어링 코딩 — LeetCode식 난해한 알고리즘이 아님파일 파싱(엣지 케이스가 있는 CSV, 중첩 구조의 JSON)재시도·레이트리밋 처리가 포함된 API 데이터 추출ETL 변환 로직(지저분한 딕셔너리를 깨끗한 레코드로 재구성)가끔 Pandas 또는 PySpark 패턴

Sample Question

order_id, customer_id, status(placed/paid/shipped/cancelled), timestamp를 가진 주문 이벤트 딕셔너리 스트림을 받는다. 일부 이벤트는 순서가 뒤바뀌어 있고 일부는 중복이다. 각 주문의 최종 상태를 반환하는 함수를 작성하라.

Solution Approach

상태 관리, 멱등성, 순서가 뒤바뀐 이벤트 처리를 시험하는 실전 데이터 엔지니어링 문제로, 알고리즘 퍼즐이 아니다.

이렇게 말하면 좋다

코드를 쓰기 전에 엣지 케이스부터 질문한다 — "두 이벤트의 타임스탬프가 같으면 어떻게 하나요? shipped 이후에 cancelled 이벤트가 오면 무시해야 하나요, 아니면 환불로 처리해야 하나요?" 이 라운드에서 특히 강조되는 Leadership Principle은 Insist on the Highest Standards다.

Common Mistakes

  • 엣지 케이스를 먼저 질문하지 않고 바로 코드를 작성한다 — 필자는 이런 질문을 던지는 지원자가 그렇지 않은 지원자 다수와 이미 차별화된다고 본다
3 System Design / Data Architecture 화이트보드 또는 가상 화이트보드 — 프롬프트 기반 데이터 파이프라인/분석 시스템 설계

Focus Areas

규모에서의 트레이드오프 추론설계 전 명확화 질문을 던지는지장애 모드, 백필, 데이터 품질을 고려하는지AWS 데이터 서비스를 이름으로 정확히 아는지

Sample Question

"Amazon.com의 실시간 광고 클릭 분석용 데이터 파이프라인을 설계하라" / "1000만 셀러의 성과 지표를 매일 집계하는 시스템을 설계하라" / "제품 추천 엔진용 데이터 인프라를 설계하라"

Solution Approach

5~7분간 요구사항(데이터량, 지연 요구사항, 소비 주체)을 명확화하고, 3~5분 개략적 용량 추정으로 설계를 실제 숫자에 근거시킨다. 10~15분간 Ingestion→Processing→Storage→Serving 흐름의 상위 아키텍처를 스케치하며 AWS 서비스명을 명시하고, 15~20분간 인터뷰어가 지목한 영역(장애 처리, 백필, 스키마 진화, 데이터 품질)을 심화한 뒤, 마지막 5분간 대안과의 트레이드오프를 설명한다. 알아둘 핵심 AWS 서비스: S3(스토리지 — 라이프사이클 정책, 인텔리전트 티어링, 파티셔닝), Redshift(웨어하우징 — distkey/sortkey/vacuum/analyze), Glue(ETL과 데이터 카탈로그), EMR(대규모 Spark 워크로드), Kinesis(스트리밍 — Data Streams와 Firehose의 차이를 알아야 함), DynamoDB(저지연 키-값 조회), Lambda(이벤트 기반 처리), Step Functions(오케스트레이션).

이렇게 말하면 좋다

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

피해야 할 답변

"Kafka를 쓰겠습니다" — 틀린 답은 아니지만, Amazon 내부 기본값은 Kinesis이므로 이렇게 말한다면 곧바로 트레이드오프를 설명하고 Kinesis가 Amazon 네이티브 옵션임을 인정하는 것이 좋다.

Common Mistakes

  • 명확화 질문 없이 곧바로 "Kinesis와 Redshift를 쓰겠습니다"로 뛰어든다 — 실제 엔지니어링 작업에서 문제를 스코핑하는 습관이 없다는 신호로 읽힌다
4 Behavioral Deep-Dive with the Bar Raiser 순수 행동 인터뷰 — 코드도, 시스템 설계도 없음. Bar Raiser가 3~4개의 Leadership Principle 질문을 각각 후속 질문과 함께 깊게 파고든다

Focus Areas

Dive Deep — 자신의 작업을 얼마나 깊이 설명할 수 있는가(가장 중요)OwnershipDeliver ResultsInsist on the Highest StandardsEarn TrustBias for ActionInvent and Simplify

Sample Question

"복잡한 데이터 파이프라인 이슈를 디버깅했던 경험"(Dive Deep) / "본인 책임이 아니었는데도 데이터 품질 문제의 오너십을 가졌던 경험"(Ownership) / "촉박한 마감 속에서 데이터 프로젝트를 전달했던 경험"(Deliver Results) / "충분히 좋지 않은 데이터 솔루션에 대해 반대 의견을 냈던 경험"(Insist on the Highest Standards) / "이해관계자에게 데이터 품질에 대한 나쁜 소식을 전해야 했던 경험"(Earn Trust) / "불완전한 정보로 데이터 아키텍처 결정을 내려야 했던 경험"(Bias for Action) / "복잡한 데이터 파이프라인을 단순화했던 경험"(Invent and Simplify)

Solution Approach

Bar Raiser는 하나의 LP(예: Dive Deep)를 골라 STAR 스토리를 요청한 뒤, 5~7개의 후속 질문으로 기술적 세부사항, 의사결정 과정, 결과를 12~15분간 파고들고 다음 LP로 넘어간다. "어떻게 개선했나요?"에 "파이프라인 실행 시간을 개선했습니다"처럼 답하면 "얼마나 개선했나요? 병목은 무엇이었나요? 처음에 시도했다가 실패한 방법은? 다른 누가 관여했나요? 반대 의견은 없었나요?" 같은 후속 질문이 이어지며, 구체적으로 답하지 못하면 스토리가 무너진다.

Common Mistakes

  • 구체적 수치 없이 뭉뚱그린 스토리("파이프라인을 개선했습니다")로 답한다 — "4시간에서 22분으로 실행 시간을 줄였습니다" 같은 구체적 결과가 필요하다
  • "더 말해달라"는 요청(Dive Deep 테스트)에 3~4단계 더 깊이 들어가지 못한다
  • PM이나 플랫폼 팀 등 남 탓을 하는 스토리를 이야기한다 — Ownership을 실패하는 것으로 읽힌다
  • 데이터 엔지니어링과 무관한 일반적인 리더십 경험(예: 마케팅 캠페인에서 8명을 이끈 경험)을 사용한다
  • 4개의 일반적인 스토리만 준비해 후속 질문에서 금방 밑천이 드러난다

Prep Strategy

Key Takeaways