← 회사 목록

Companies

DoorDash

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

Overview

DoorDash의 Data Engineer 채용 프로세스는 FAANG 기준으로는 상대적으로 짧은 편으로, 저자에 따르면 리크루터 스크린부터 오퍼까지 보통 3~5주가 걸린다. 가장 큰 특징은 기술 폰스크린이 60분 안에 SQL 4문제와 Python 1문제를 푸는 매우 빠른 속도전이라는 점과, 온사이트에 데이터 엔지니어가 아닌 프로덕트 매니저가 직접 진행하는 'Business Partner' 라운드가 있다는 점이다. 저자의 관찰상 이 두 라운드에서 지원자의 상당수가 걸러지며, SQL 실력만으로는 통과할 수 없는 구조다.

Timeline

# 단계 형식 소요 시간 평가 항목
1 Recruiter Screen Phone call 30 min Role fit, comp, visa, team mapping
2 Technical Phone Screen Video call 60 min 시간 압박 속 SQL 4문제 + Python 1문제
3 Onsite Loop 4-5 rounds, 45-60 min each 1일(분산 가능) SQL, Coding, System Design, Business Partner, Behavioral
4 Debrief & Decision Internal — 전체 인터뷰어 + hiring committee 영업일 3~5일 종합 hire/no-hire 결정

Rounds

0 Technical Phone Screen (필터 라운드) 공유 에디터에서 라이브 코딩. 인터뷰어가 문제를 읽어주면 쿼리를 작성하며 논리를 설명하고, 인터뷰어가 통과시키거나 반박한 뒤 다음 문제로 넘어간다. 망설일 시간이 거의 없다.

Focus Areas

빠르고 정확하게 SQL을 작성할 수 있는가시계가 돌아가는 상황에서도 침착함을 유지하는가마켓플레이스 데이터 패턴(주문, 배달, 배달원, 가맹점)을 얼어붙지 않고 다루는가SQL에서 Python으로 맥락을 전환하면서도 흐름을 잃지 않는가

Sample Question

"order_id, consumer_id, merchant_id, dasher_id, order_ts, delivered_ts, order_status를 가진 orders 테이블이 있다. 최근 30일간 평균 배달 시간이 가장 긴 가맹점을 찾되, 실제로 배달 완료된 주문만 카운트하라. 해당 기간 배달 완료 주문이 최소 50건 이상인 가맹점으로 한정하라"(SQL, 숙련자 기준 8~10분 내 — 필터링용 CTE, AVG 집계, 50건 기준 HAVING, ORDER BY DESC) / "order_id, status, event_ts를 가진 주문 이벤트 딕셔너리 리스트를 받는다. 일부 이벤트는 순서가 뒤바뀌어 있고 일부는 중복이다. 각 주문의 가장 최근 유효 상태를 반환하는 함수를 5분 이내에 작성하라"(Python, 숙련자 기준 8~10분 내 — order_id별 상태 관리, event_ts 동률 처리, 재실행 시 멱등성)

Solution Approach

문제당 8~10분 내에 정확한 SQL/Python을 작성하는 속도와 정확성 자체가 이 라운드의 시험 대상이라고 저자는 강조한다. 4문제 SQL을 다 풀고도 Python 문제에 도달하지 못하는 지원자가 많다고 한다.

이렇게 말하면 좋다

말은 거의 하지 않는다. 짧고 날카로운 내레이션만 한다. "필터링된 주문용 CTE. HAVING으로 AVG. 완료." 인터뷰어는 속도와 정확성을 보고 싶어하지, 문제당 4분짜리 아키텍처 강연을 원하지 않는다.

피해야 할 답변

"엣지 케이스를 1분만 생각해볼게요" — 1분의 여유가 없다. 문제당 총 12분 중 1분은 인터뷰어가 말하는 시간이다. 엣지 케이스는 30초 안에 파악하고 명확화 질문은 많아야 1~2개만 한 뒤 곧바로 작성해야 한다.

Common Mistakes

  • 일반적인 SQL 인터뷰처럼 여유 있게 접근한다 — 속도 자체가 시험 대상이다
  • 쉬워 보인다고 첫 문제에 4분을 쓴다 — 남은 4문제에 56분만 남아 이미 뒤처진 셈이 된다
  • 침묵한 채 코딩한다 — 인터뷰어가 진행 상황을 추적해야 하므로 5단어 단위로 짧게 내레이션해야 한다
  • Python 문제를 건너뛴다 — SQL에 50분을 다 쓰고 Python에 시간이 없으면 사실상 자동 감점이다
1 SQL Deep Dive 공유 에디터에서 라이브 코딩. 폰스크린보다 난이도가 높고 문제당 시간도 더 여유롭다. 보통 45~60분에 2문항

Focus Areas

orders, dashers, merchants, consumers로 이루어진 3면 데이터에서의 복잡한 마켓플레이스 SQL시계열 패턴 — 배달 시간, 대기 시간, 배달원 유휴 시간, 가맹점 준비 시간퍼널 분석 — 주문 접수부터 배달원 배정, 픽업, 배달 완료까지마켓플레이스 헬스 지표 — 활성 배달원 수, 가용 가맹점 수, 존(zone)별 주문 대 배달원 비율시퀀스 분석용 윈도우 함수(배달원의 직전 배달, 가맹점의 누적 주문 수 등)

Sample Question

orders, dasher_assignments, delivery_events 테이블이 있다. 각 배달원에 대해, 하루에 최소 3건 이상 배달을 완료한 날에 한해 연속된 배달 사이의 평균 유휴 시간을 구하라. 그다음 존(zone)과 날짜 기준으로 유휴 시간이 가장 낮은 순으로 배달원 순위를 매겨라.

Solution Approach

배달원 기준으로 정렬한 윈도우에 대한 LAG, 날짜 파티셔닝, 건수 조건의 HAVING 필터, 마지막 순위 계산용 윈도우 함수가 필요하며 숙련자 기준 20~25분이 걸린다.

Common Mistakes

  • 그레인을 혼동한다 — 한 행이 주문인지, 배달 이벤트인지, 배달원-일(day) 단위인지 명시해야 한다
  • 배달원 근무 교대와 날짜 경계 간의 겹침을 처리하지 않는다 — 존 정의와 날짜 컷 규칙을 먼저 물어야 한다
  • LAG를 같은 배달원·같은 날로 한정하는 것을 잊는다 — 기본 윈도우는 모든 것을 포함해버린다
2 Coding in Python 라이브 코딩. Python이 기본이며, 다른 언어를 쓸 강력한 이유가 없는 한 Python을 권장

Focus Areas

실전 DE 코드 — 알고리즘이 아님데이터 변환과 엣지 케이스 처리중첩 JSON을 깔끔한 표 형태로 재구성늦게 도착하는 이벤트와 중복 이벤트가 있는 스트림 처리 로직ETL용 멱등적 함수날짜·시간대 처리(DoorDash는 여러 마켓에 걸쳐 운영됨)

Sample Question

dasher_id, lat, lng, ts를 가진 배달원 위치 핑(ping) 스트림을 받는다. 핑은 순서가 뒤바뀌어 도착할 수 있고 중복도 있을 수 있다. 해당 배달원에 대해 가장 최근에 본 핑보다 60초 이상 오래된 핑은 무시하고 현재 위치를 반환하는 함수를 작성하라. 그리고 배달원이 오프라인 상태가 되는 경우를 처리하려면 이를 어떻게 확장할지 설명하라.

Solution Approach

dasher_id별 상태 관리, 워터마크 방식 필터링, '오프라인' 감지 확장이 필요한 실전 스트림 처리 패턴이다.

이렇게 말하면 좋다

먼저 명확화 질문을 한다 — "입력이 미리 정렬되어 있나요? lat/lng가 null일 수 있나요? 타임스탬프 동률에서만 중복 제거해야 하나요, 아니면 lat/lng도 봐야 하나요?" 그다음 이름이 명확한 헬퍼 변수로 깔끔한 코드를 작성한다.

Common Mistakes

  • 상태 없는 단일 패스 루프로 취급한다 — 키별 딕셔너리가 필요하다
  • 워터마크 로직을 빠뜨린다 — '60초보다 오래된' 필터가 이 문제의 핵심이다
  • 확장 질문(오프라인 처리)에 답하지 않는다 — 의도적으로 추가된 질문이므로 깔끔하게 확장하는 방법을 보여줘야 한다
3 System Design 화이트보드. DoorDash 제품에 기반한 데이터 파이프라인 또는 분석 시스템 설계

Focus Areas

실시간 마켓플레이스 데이터를 추론할 수 있는가아키텍처 이전에 요구사항부터 확인하는가백필, 스키마 진화, 데이터 품질, exactly-once 시맨틱스를 처리하는가현대적인 lakehouse + 스트리밍 스택을 아는가

Sample Question

"ETA 예측 데이터 파이프라인을 설계하라" / "마켓플레이스 헬스 모니터링 데이터 인프라를 설계하라" / "가맹점 성과 분석 플랫폼을 설계하라" / "배차 최적화용 데이터 인프라를 설계하라"

Solution Approach

(1) 5~7분 요구사항 확인 — ETA의 신선도 요구사항은? 소비자 앱이 소비하는지 배차 서비스가 소비하는지? 피크 QPS는? 지연 데이터의 SLA는? DoorDash에서는 신선도(freshness)가 종종 가장 까다로운 요구사항이며 ETA는 서브세컨드 수준을 요구한다. (2) 3~5분 백오브엔벨로프 추정 — 일별 주문 수, 피크 QPS, 이벤트 크기, 스토리지 증가량. (3) 10~15분 상위 아키텍처 — Ingestion → Processing → Storage → Serving, Kafka/Flink/Pinot/Delta Lake를 이름으로 명시. (4) 15~20분 심화 — exactly-once 시맨틱스, 워터마크, 백필, 스키마 진화, 데이터 품질. (5) 5분 트레이드오프 — 예: "이벤트 타임 윈도잉을 네이티브로 지원해서 Spark Streaming 대신 Flink를 선택했다. 팀이 Spark에 더 익숙하다면 텀블링 윈도우에는 타당한 대안이지만 세션 윈도우에는 맞지 않는다." 알아둘 핵심 스택: Kafka(이벤트 인제스천 — 토픽, 파티션, exactly-once), Flink(스트림 처리 — 윈도잉, 워터마크, 체크포인트, DoorDash의 기본 스트리밍 엔진), Delta Lake(레이크하우스 레이어 — 오브젝트 스토리지 위의 ACID, 타임 트래블, 스키마 강제), Pinot(실시간 OLAP — 스트리밍 데이터에 대한 서브세컨드 쿼리), Spark(배치 ETL), Airflow(오케스트레이션), Presto(레이크하우스 애드혹 분석).

이렇게 말하면 좋다

"ETA의 신선도 요구사항은 무엇인가요? 이 데이터를 소비자 앱이 쓰나요, 배차 서비스가 쓰나요? 피크 QPS는 얼마나 되나요? 지연 데이터의 SLA는요?"로 5~7분간 요구사항부터 확인한다.

피해야 할 답변

"이건 매시간 배치로 처리하겠습니다" — ETA에도, 배차에도, 마켓플레이스 헬스에도 맞지 않는다. 스트리밍이 필요한 상황에서 배치를 기본값으로 삼으면 잘못된 직관을 신호하게 된다.

Common Mistakes

  • 요구사항 없이 곧바로 다이어그램으로 들어간다 — 감점 요인
  • 정당화 없이 Flink 대신 Spark Streaming을 선택한다 — DoorDash 내부에서는 Flink가 기본값이다
  • 백필을 잊는다 — Pinot을 재구축해야 할 때 최근 30일을 어떻게 리플레이할지, Delta Lake 기반 오프라인 경로가 필요하다
  • 데이터 품질 계획이 없다 — 주문 이벤트에는 null, 중복, 지연 도착이 있으므로 이를 다뤄야 한다
4 Business Partner 대화형, 가끔 화이트보드 스케치 포함. 프로덕트 매니저가 직접 인터뷰어로 진행하는, 저자에 따르면 지원자들을 가장 놀라게 하는 라운드

Focus Areas

비즈니스 문제에 대해 명확화 질문을 던질 수 있는가비즈니스 요구사항을 데이터 솔루션으로 번역할 수 있는가기술적 결정을 평이한 언어로 설명할 수 있는가3면 마켓플레이스(소비자, 배달원, 가맹점)를 이해하는가PM을 단순한 요청자가 아니라 파트너로서 협업할 수 있는가

Sample Question

"가맹점들이 플랫폼에서 이탈(churn)하는 이유를 이해하고 싶다. 이를 분석할 데이터 인프라를 설계하라" / "제품팀이 새로운 배달원 등급제(tier program)를 출시하려 한다. 이를 평가하려면 어떤 데이터를 추적해야 하는가?" / "DoorDash에서 소비자 만족도를 어떻게 측정하겠는가? 사고 과정을 설명하라" / "한 가맹점이 자신의 주문이 줄고 있다고 불평한다. 데이터로 어떻게 조사하겠는가?"

Solution Approach

저자가 제시하는 프레임워크: (1) 문제를 자신의 언어로 다시 진술해 들었음을 보여준다, (2) 목표는 무엇인지, 누가 분석 결과를 소비하는지, 어떤 결정을 지원하는지, 타임라인은 어떤지, 이전에 다른 시도가 있었는지 등 3~5개의 명확화 질문을 던진다, (3) 구조화된 접근을 제안해 문제를 더 작은 데이터 질문으로 분해한다, (4) 데이터 소스와 모델을 평이한 언어로 설명한다(예: "가맹점 서비스에서 온보딩 이벤트를, 주문 팩트 테이블에서 일별 주문 지표를, CX 시스템에서 문의 데이터를 가져와 일별 가맹점 헬스 테이블을 만들겠다"), (5) 트레이드오프를 평이한 언어로 인지한다(예: "기본 대시보드는 2주면 나오지만, 제대로 된 이탈 모델은 2개월이 걸린다. 전자는 질문에 답하고, 후자는 더 잘 답하지만 비용이 더 든다").

이렇게 말하면 좋다

비즈니스 언어를 쓴다. "dim_merchant의 merchant_satisfaction_score"가 아니라 "가맹점 만족도", "delivered_ts non-null 체크에서 파생된 불리언 플래그"가 아니라 "주문 성공률"이라고 말한다.

피해야 할 답변

"fact_merchant_daily와 dim_merchant Type 2로 스타 스키마를 만들겠습니다" — PM은 이런 용어에 관심이 없다. "가맹점별로 핵심 지표와 현재 속성을 담은 일별 요약 테이블을 만들어 시간에 따른 변화를 추적하겠다"처럼 번역해야 한다.

Common Mistakes

  • 기술 전문 용어로만 말한다 — PM은 웃으며 고개를 끄덕이지만 디브리핑에는 '소통이 약함'이라고 적힌다
  • 명확화 질문을 건너뛰고 곧바로 "이렇게 설계하겠습니다"로 들어간다 — 비즈니스 목표를 묻지 않으면 실패로 이어진다
  • PM을 단순 요청자로 대한다 — PM은 지원자를 파트너로 평가하고 있으므로 "이걸 만들기 전에 기존 지표가 이미 이 질문에 답하는지 확인해봐도 될까요?"처럼 정중하게 되물어야 한다
  • 3면 마켓플레이스를 이해하지 못한다 — 소비자 측 문제와 가맹점 측 문제를 혼동하는 것은 레드플래그다
5 Behavioral and Culture 대화형 행동 인터뷰. 모호함, 갈등, 속도에 어떻게 대응했는지를 탐색

Focus Areas

Bias for action — 논쟁 대신 실행할 수 있는 DE를 원한다는 것이 DoorDash의 문화적 가치Customer obsession — 여기서 고객은 데이터와 의사결정을 소비하는 배달원, 가맹점, 소비자를 의미One team — PM, 데이터 사이언티스트, 엔지니어 간의 강한 협업Iteration speed — 만들고, 측정하고, 배우고, 반복. 느린 DE는 DoorDash에서 살아남지 못한다는 것이 저자의 표현

Sample Question

"원래 계획보다 더 빠르게 데이터 제품을 출시했던 경험은?" / "데이터 품질에 대한 나쁜 소식을 이해관계자에게 전해야 했던 경험은?" / "PM이나 데이터 사이언티스트와 지표 정의를 두고 이견이 있었던 경험은? 어떻게 해결했는가?" / "데이터 품질 이슈를 끝까지 오너십을 가지고 처리했던 경험은?"

Solution Approach

후속 질문이 세부사항을 파고든다 — "얼마나 걸렸나요? 누가 관여했나요? 영향은 수치로 어땠나요?" 구체적 수치로 답하지 못하면 스토리가 얇다는 것이 드러난다고 저자는 지적한다.

Prep Strategy

Key Takeaways