Companies

Uber

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

Overview

Uber의 Data Engineer 채용 프로세스는 리크루터 스크린부터 오퍼까지 보통 3~5주가 걸리며, 병목은 파이프라인 자체가 아니라 온사이트 일정 조율이라는 것이 저자의 관찰이다. 가장 큰 차별점은 시스템 설계에 묻어가는 방식이 아니라 데이터 모델링을 45~60분짜리 전용 라운드로 따로 떼어내 grain·fact 테이블·SCD까지 깊게 파고든다는 점이고, 두 번째 차별점은 Uber의 비즈니스 자체가 실시간이라 Kafka·Flink·exactly-once·워터마크·윈도잉에 대한 유창함을 시스템 설계 전반에서 기대한다는 점이다.

독립된 데이터 모델링 라운드 — 대부분의 회사는 모델링을 시스템 설계 안에 녹여 넣지만 Uber는 45~60분을 통째로 할애해 그라운드업으로 라이드헤일링/음식배달 도메인의 차원 모델을 설계하게 한다. 저자에 따르면 시간 압박 속에서 연습해보지 않은 지원자의 약 60%가 이 라운드에서 얼어붙는다.
스트리밍이 선택이 아니다 — 라이드 매칭, 서지 프라이싱, 디스패치, ETA 예측, 사기 탐지 등 비즈니스 자체가 실시간이라 Kafka, Flink, exactly-once 시맨틱스, 워터마크, 윈도잉에 대한 추론 능력을 기대한다.
마켓플레이스 데이터 복잡도 — 라이더, 드라이버, 트립, 결제, 평점, 환불, 분쟁, 서지 존, 도시 간의 관계가 일반적인 이커머스 스키마보다 훨씬 복잡하며 데이터 모델과 시스템 설계 모두에서 이를 깔끔하게 다뤄야 한다.
직접 만든 도구를 묻는다 — Hudi, Pinot, Cadence, AthenaX, Michelangelo 등 Uber가 오픈소스화한 데이터 스택을 정확히 인용하면 아무 사전 조사 없이 온 지원자 풀과 확실히 구분된다는 것이 저자의 관찰이다.

Timeline

#	단계	형식	소요 시간	평가 항목
1	Recruiter Screen	Phone call	30 min	Role fit, comp, visa, team mapping
2	Technical Phone Screen	Video call	60 min	SQL + Python, medium-hard
3	Onsite Loop	4-5 rounds, 45-60 min each	1~2주 간격 후 진행(보통 가상으로 진행)	SQL, Coding, Data Modeling, System Design, Behavioral
4	Hiring Manager Round	Video call	45 min	Team fit, leadership, scope
5	Debrief & Decision	Internal	영업일 3~5일	Cross-interviewer sync, hiring committee

Rounds

0 Technical Phone Screen (필터 라운드) 화상 통화, 60분. 사소한 워밍업 라운드로 취급하기 쉽지만 저자에 따르면 이 단계에서 지원자의 절반가량이 필터링될 만큼 실제 온사이트 라운드와 다름없는 강도로 다뤄야 한다. 60분 안에 만만치 않은 데이터셋을 상대로 실제 SQL과 실제 Python을 모두 수행해야 한다.

Focus Areas

SQL 실력 — 실제 사이즈의 데이터셋에 대한 문제 해결Python 실력 — 실전형 데이터 처리 코드60분 안에 SQL과 Python 양쪽 모두에서 무너지지 않는 안정성

Solution Approach

온사이트 SQL·Python 라운드와 동일한 강도로 준비해야 한다 — 워밍업이라는 착각이 가장 흔한 실수라는 것이 저자의 지적이다.

1 SQL 온사이트, 45~60분. 공유 에디터에서 라이브 코딩. 보통 난이도가 점점 올라가는 2~3문항이며 라이드 데이터, 마켓플레이스 데이터, 시계열 패턴 위주다.

Focus Areas

윈도우 함수 — ROW_NUMBER, RANK, LAG, LEAD, 슬라이딩 윈도우. RANK와 DENSE_RANK의 차이를 즉석에서 설명하지 못하면 미리 정리해둬야 한다이벤트 스트림의 세션화 — "이 라이드 이벤트들을 트립으로 묶어라" 같은 Uber의 대표 패턴시계열 집계 — 시간대별 수요, 존별 공급, 서지 지속시간, 평균 대기시간다단계 퍼널 — 앱 오픈부터 라이드 요청, 드라이버 배정, 라이드 완료까지 각 단계의 이탈마켓플레이스 지표 — 수락률, 취소율, 완료율, 서지 반영 수익

Sample Question

trip_id, rider_id, driver_id, event_type(requested, accepted, started, completed, cancelled), event_ts를 가진 trip events 테이블이 있다. 각 라이더별로 requested와 accepted 사이 간격이 90초를 넘는 트립을 찾은 뒤, 이를 시간대(hour-of-day)와 도시별로 버킷화하여 지연 수락 트립 수가 가장 많은 버킷을 반환하라.

Solution Approach

LeetCode식 SQL만 공부한 지원자를 걸러내는 문제다. 이벤트를 wide 포맷으로 피벗하고, 간격을 계산해 필터링한 뒤, 타이브레이커와 함께 집계해야 한다. 깔끔한 답은 조건부 집계로 피벗하는 CTE, 필터링하는 두 번째 CTE, 버킷 순위를 매기는 세 번째 CTE로 구성된다.

이렇게 말하면 좋다

코딩하는 내내 생각의 흐름을 계속 말한다. "먼저 조건부 max로 이벤트를 피벗해서 request_ts와 accept_ts를 한 행에 놓겠습니다. 그다음 간격으로 필터링하고, 그다음 버킷화해서 카운트하겠습니다." 침묵한 채 코딩하면 인터뷰어가 사고 과정을 따라갈 수 없어 no-hire로 이어진다.

피해야 할 답변

"이건 Pandas로 하겠습니다" — 나중에 쓰게 되겠지만 SQL 라운드에서 할 말은 아니다. "저희는 이걸 대신 해주는 BI 툴이 있었습니다"도 피해야 한다 — SQL을 깊이 있게 다루지 못한다는 신호로 읽힌다.

Common Mistakes

CTE 체인이 더 명확한 상황에서 중첩 서브쿼리를 쓴다 — Uber 인터뷰어는 읽기 쉬운 SQL을 높게 평가한다
rider_id나 event_ts의 NULL 처리를 건너뛴다 — 작성 전에 "event_ts가 null일 수 있나요? 고아 이벤트가 있나요?"를 먼저 물어야 한다
세션화를 라이드가 절대 겹치지 않는 것처럼 다룬다 — 실제로는 겹친다(드라이버가 재배정될 수 있음). 이를 먼저 물어야 한다

2 Coding in Python 온사이트, 45~60분. 라이브 코딩이며 Python이 기본이다. 일부 인터뷰어는 Scala나 Java도 허용하지만 강력한 이유가 없다면 Python을 쓰는 것이 좋다.

Focus Areas

스트림 처리 로직 — 순서가 뒤바뀐 이벤트 처리, 중복 제거, 키별 상태 유지재시도·레이트 리밋·부분 실패를 고려한 파일/API 파싱ETL 변환 — 중첩된 JSON을 깔끔한 표 형태로 재구성idempotency — 같은 입력을 리플레이해도 같은 결과를 내는 함수

Sample Question

driver_id, lat, lng, ts를 가진 딕셔너리 형태의 드라이버 위치 핑 스트림을 받는다. 일부 핑은 늦게 도착하고 일부는 중복이다. 각 드라이버에 대해, 해당 드라이버의 가장 최근 핑보다 30초 넘게 오래된 핑은 무시하고 가장 최근의 유효한 위치를 반환하는 함수를 작성하라.

Solution Approach

이 문제는 키별 상태 관리, 지연 도착 데이터 처리, 워터마크 방식 필터링을 시험하는 Flink 잡의 축소판이다. 스트림 처리 로직을 작성해본 적이 없다면 이 라운드에서 어려움을 겪게 될 것이라고 저자는 지적한다.

이렇게 말하면 좋다

코드를 쓰기 전에 먼저 엣지 케이스를 묻는다. "입력이 정확히 어떤 형태인가요? 스트림이 정렬되어 있나요? 로그오프한 드라이버의 lat/lng가 null일 수 있나요? 중복은 타임스탬프 동률로 판단해야 하나요, 아니면 lat/lng도 봐야 하나요?" 이런 질문을 코드를 쓰기 전에 던지는 지원자는 이미 지원자 풀의 70%와 차별화된다는 것이 저자의 관찰이다.

Common Mistakes

상태를 고려하지 않은 원패스 루프로 작성한다 — driver_id를 키로 하는 딕셔너리가 필요하다
타임스탬프 동률 처리를 잊는다 — 규칙을 하나 정하고 명시해야 한다
출력 포맷을 묻지 않는다 — 인터뷰어가 딕셔너리를 원하는지, 레코드 리스트를 원하는지, 제너레이터를 원하는지 확인해야 한다

3 Data Modeling 온사이트, 45~60분. Uber 루프를 결정짓는 라운드라고 저자가 반복해서 강조하는 라운드. 화이트보드(또는 가상 화이트보드)에서 인터뷰어가 도메인을 주면 그라운드업으로 차원 모델을 설계한다. Grain, fact 테이블, 차원, SCD 전략, surrogate key까지 전부 다룬다. 45분 타이머 아래 백지에서 스타 스키마를 설계해본 적이 없다면 얼어붙게 된다는 것이 저자의 경고다.

Focus Areas

차원 모델링 — 스타 스키마 vs 스노우플레이크, 언제 어느 쪽을 쓰는지(기본값은 스타, 차원이 정말 크거나 여러 곳에서 공유될 때만 스노우플레이크)Grain — "이 fact 테이블의 한 행은 무엇을 나타내는가"를 한 문장으로 답할 수 있는가Fact 테이블 유형 — transactional(트립 이벤트), periodic snapshot(드라이버 일별 수익), accumulating snapshot(트립 라이프사이클) 중 무엇이 어디에 맞는지Slowly Changing Dimensions — Type 1(덮어쓰기), Type 2(유효기간이 있는 새 행), Type 3(이전 값을 위한 새 컬럼). 저렴하게 재구축 가능한 속성은 Type 1, fact와 조인 시 히스토리 정확도가 중요한 속성은 Type 2가 기본값마켓플레이스 데이터 복잡도 — 라이더, 드라이버, 트립, 결제, 평점, 환불, 서지 존 간의 관계를 깔끔하게 모델링해야 한다

Sample Question

"Uber의 라이드 비즈니스를 위한 데이터 모델을 설계하라. 도시별 매출 대시보드, 드라이버 수익 리포트, 라이더의 주간 코호트 리텐션을 지원해야 한다" / "Uber Eats를 위한 데이터 모델을 설계하라. 가맹점별 성과, 배달원(dasher) 정산, 주문 퍼널 분석을 지원해야 한다"

Solution Approach

5단계 프레임워크로 진행한다. (1) 5~7분 명확화 질문 — 어떤 도메인을 모델링하는지, 이 모델이 답해야 할 질문은 무엇인지, 데이터 볼륨은, 지연시간 요구사항은, 웨어하우스 모델인지 서빙 레이어인지. (2) 3분 grain 옵션 나열 — 라이드 데이터라면 요청당 한 행, 라이프사이클 이벤트당 한 행, 완료된 트립당 한 행 중 트레이드오프를 밝히고 메인 fact로 하나를 정해 이유를 설명한다. (3) 10분 fact 테이블 스케치 — 보통 하나의 transactional fact(fact_trip)와 하나의 accumulating snapshot(fact_trip_lifecycle) 또는 periodic snapshot(fact_driver_daily)이 필요한 이유를 설명한다. (4) 10분 차원 스케치 — dim_rider, dim_driver, dim_city, dim_vehicle, dim_payment_method, dim_date, dim_time 중 어느 것에 SCD Type 2가 필요한지(드라이버 전화번호는 Type 1, 드라이버 평점은 일별 스냅샷을 곁들인 Type 2가 대개 더 깔끔함). (5) 10분 모델에 대한 쿼리 2~3개 실행 — "도시별 주간 매출을 보여달라", "당시 평점과 함께 월별 드라이버 수익을 보여달라" — 이 단계에서 인터뷰어가 grain 실수를 캐낸다.

이렇게 말하면 좋다

"먼저 이 모델이 어떤 비즈니스 질문에 답해야 하는지 묻겠습니다. 그다음 메인 fact 테이블의 grain을 정의하고, 차원을 스케치한 뒤, 검증을 위해 쿼리 몇 개를 실행해보겠습니다."

피해야 할 답변

"넓은 비정규화 테이블을 쓰겠습니다" — 서빙 레이어라면 실제 프로덕션에서 맞는 선택일 수 있지만, 이 라운드에서는 스타 스키마 설계에 대한 추론 능력을 보고 싶어한다. 비정규화 버전은 마지막에 최적화로 언급하는 정도가 적절하다.

Common Mistakes

grain 대화를 건너뛴다 — 모든 fact 테이블은 "한 행이 완료된 트립 하나와 같다"처럼 한 문장으로 grain을 말할 수 있어야 하며, 그러지 못하면 모델이 망가진 것이다
측정값(measure)을 차원에 넣는다 — 드라이버 수익은 fact에 있어야지 dim_driver에 있으면 안 된다
모든 차원을 기본값으로 SCD Type 2로 설계한다 — 비용이 많이 들고 대부분의 차원은 그럴 필요가 없다. 하나하나 정당화해야 한다
지연 도착 fact를 잊는다 — 라이더 정보가 바뀐 후에 트립이 완료될 수 있다. 이를 어떻게 처리할지 명시해야 한다

4 System Design 온사이트, 60분. 화이트보드. Uber 제품에 기반한 데이터 파이프라인 또는 분석 시스템을 설계한다.

Focus Areas

마켓플레이스 스케일에서의 트레이드오프를 추론할 수 있는가아키텍처보다 요구사항부터 시작하는가장애 모드, 백필, 스키마 진화, 데이터 품질을 처리하는가현대적인 스트리밍 + 레이크하우스 스택을 알아서 올바른 도구를 이름으로 댈 수 있는가

Sample Question

"서지 프라이싱 데이터 파이프라인을 설계하라"(가장 고전적인 문제) / "ETA 예측 데이터 인프라를 엔드투엔드로 설계하라" / "디스패치 팀을 위한 실시간 마켓플레이스 헬스 대시보드를 설계하라" / "드라이버 수익 정산 데이터 플랫폼을 설계하라"

Solution Approach

요구사항(5~7분, 기능/비기능 요구사항, 데이터 볼륨, 지연시간, 신선도, 누가 소비하는지, 어떤 의사결정을 지원하는지, 지연 데이터 SLA) → 백오브엔벨로프 추정(3~5분, 실제 숫자에 설계를 고정시킨다 — 예를 들어 "하루 트립 1억 건, 트립 라이프사이클당 이벤트 10개, 이벤트당 1KB라면 하루 1TB"처럼 예시 숫자로 추정해본다) → 상위 아키텍처(10~15분, Ingestion→Processing→Storage→Serving을 도구 이름과 함께 — 인제스천에 Kafka, 처리에 Flink, 서빙에 Pinot, 오프라인 레이어에 Hudi) → 심화(15~20분, 백필·스키마 진화·exactly-once vs at-least-once·워터마크 처리·지연 이벤트 중 인터뷰어가 파고드는 한두 영역) → 트레이드오프(5분, 예: "이벤트 타임 네이티브 윈도잉 때문에 Spark Streaming 대신 Flink를 선택했지만, 팀이 Spark에 더 익숙하다면 텀블링 윈도우에는 유효한 대안이다") 순서로 진행한다. 알아둘 핵심 스택: Kafka(이벤트 인제스천 — 토픽, 파티션, 컨슈머 그룹, exactly-once), Flink(스트림 처리 — 텀블링/슬라이딩/세션 윈도잉, 워터마크, 체크포인트, Uber의 기본 스트리밍 엔진), Apache Pinot(실시간 OLAP — Uber가 공동 개발, 스트리밍 데이터에 대한 서브세컨드 쿼리), Apache Hudi(레이크하우스 레이어 — Uber가 만듦, 증분 인제스천·업서트·타임 트래블), HDFS+Hive(장기 저장소), Spark(배치 ETL), Presto(애드혹 분석).

이렇게 말하면 좋다

명확화 질문부터 시작한다. "피크 QPS는 얼마인가요? 신선도 요구사항은 무엇인가요? 이 데이터를 디스패치 서비스가 쓰나요, 대시보드가 쓰나요? 지연 데이터에 대한 SLA는요?"를 5~7분간 물은 뒤 상위 아키텍처를 스케치하고 인터뷰어가 파고드는 곳을 깊게 판다.

피해야 할 답변

"매시간 실행되는 배치 잡을 작성하겠습니다" — 서지 프라이싱에도 ETA에도 맞지 않는다. 인터뷰어는 스트리밍을 기대하며, 스트리밍이 필요한 상황에서 배치를 기본값으로 삼으면 잘못된 직관을 신호하게 된다.

Common Mistakes

요구사항 단계를 건너뛰고 곧바로 다이어그램으로 들어간다 — Uber 인터뷰어는 이에 대해 감점한다
왜 Flink가 아닌지 설명 없이 Kafka+Spark Streaming을 고른다 — Uber 내부 기본값은 Flink다
백필을 잊는다 — Pinot 테이블이 손상됐을 때 최근 30일을 어떻게 리플레이할지, Hudi 기반 오프라인 경로가 필요하다
스키마 진화를 처리하지 않는다 — 트립 이벤트 스키마는 분기마다 바뀌는데 파이프라인이 이를 어떻게 견디는지 설명해야 한다

5 Behavioral and Hiring Manager 온사이트, 45~60분. 대화형이며 코드나 화이트보드가 없다. 하이어링 매니저가 모호함·갈등·스케일을 어떻게 다뤘는지 탐색한다. Amazon의 Bar Raiser만큼 가혹하지는 않지만 하이어링 매니저가 거부권을 가지고 있어 문화 불일치 시그널이 보이면 이를 행사한다는 것이 저자의 설명이다. 공식 Leadership Principle 스코어카드는 없다.

Focus Areas

빠르게 움직이고 때로는 혼란스러운 환경에서 일할 수 있는가온콜을 포함해 파이프라인을 엔드투엔드로 오너십을 가지고 다루는가실제 데이터 품질 인시던트를 겪고 거기서 배운 적이 있는가PM, 데이터 사이언티스트, 소프트웨어 엔지니어와 같은 팀에서 협업할 수 있는가

Sample Question

"프로덕션에서 데이터 파이프라인이 고장 났던 경험을 말해달라. 무엇을 했는가?" / "이해관계자에게 나쁜 데이터 품질 소식을 전해야 했던 경험을 말해달라" / "데이터가 준비되지 않았다는 이유로 기능 요청을 반려한 경험을 말해달라" / "불완전한 정보로 기술적 결정을 내려야 했던 경험을 말해달라" (그 외 오너십/스케일/모호함/교차기능/실패/학습 테마별 질문도 준비해야 한다)

Solution Approach

STAR 구조를 따른다: Situation(20%, 간단한 맥락), Task(10%, 자신의 구체적 역할 — "그 분기에 결제 파이프라인 온콜 DE였다"처럼 정확하게), Action(50%, 자신이 한 일을 'I'를 적극적으로 쓰며 구체적 기술 결정과 검토했다가 기각한 대안까지), Result(20%, 수치화된 결과 — "파이프라인 실행 시간을 4시간에서 22분으로 줄였다. 연간 비용을 8만 달러 절감했다. 이 패턴이 다른 6개 파이프라인의 팀 기본값이 되었다"). 하이어링 매니저는 후속 질문으로 세부사항을 깊게 파고든다 — "얼마나 걸렸나요? 누가 관여했나요? 처음에 무엇을 시도했다가 안 됐나요? 영향은 수치로 어땠나요?" 이 후속 질문에 구체적으로 답하지 못하면 스토리가 얇다는 뜻이므로 다른 스토리를 골라야 한다.

이렇게 말하면 좋다

수치화된 결과가 담긴 구체적 스토리. "동일한 Kafka 토픽 위에서 일별 Spark 배치를 Flink 스트리밍 잡으로 전환해 p95 지연시간을 6시간에서 35분으로 줄였습니다"처럼 답하면 통과다.

피해야 할 답변

"파이프라인을 개선했습니다"처럼 수치 없는 모호한 답변은 실패다. "PM이 요구사항을 잘못 정리했고, 그다음 플랫폼 팀이 API를 망가뜨렸습니다"처럼 남 탓을 하는 것도 오너십 항목에서 실패로 이어진다.

Common Mistakes

숫자 없는 모호한 스토리를 말한다
남 탓을 한다 — 오너십 실패로 읽힌다
데이터 엔지니어링과 무관한 스토리(예: 마케팅 캠페인 이야기)를 고른다
돌아보기(reflection)가 없다 — 지금이라면 무엇을 다르게 할지 말하지 못하면 감점 요인이다

Culture — Uber의 문화 규범 (We Act Like Owners / We Are Customer Obsessed / We Build Globally, We Live Locally / We Make Big Bold Bets — 공식 Leadership Principle 체계는 아님)

공식 스코어카드는 없지만 하이어링 매니저가 거부권(veto power)을 가지고 있어 문화 불일치 시그널이 보이면 이를 행사한다는 것이 저자의 설명이다.

We Act Like Owners(온콜과 포스트모템을 포함한 파이프라인의 엔드투엔드 오너십), We Are Customer Obsessed(DE 입장에서는 데이터 품질 — 나쁜 데이터가 곧바로 라이더·드라이버 경험에 반영됨), We Build Globally, We Live Locally(70개국 이상에서 운영되므로 타임존·통화·규제·파트너 데이터를 데이터 시스템이 감당해야 함), We Make Big Bold Bets(문제가 요구할 때 익숙한 패턴을 넘어서려는 의지) 네 가지가 DE 롤에서 특히 중요하게 관찰되는 문화 규범이라고 저자는 설명한다.

Prep Strategy

1주차 — 데이터 모델링 숙달: 1~2일차에 grain, fact 유형, SCD 유형 등 차원 모델링 기본기를 복습하고, 3~7일차에는 라이드헤일링·음식배달·화물·결제·평점 등 다양한 도메인으로 하루 하나씩 30분 타이머를 걸고 백지에서 모델을 설계하는 연습을 한다. Uber 기술 블로그의 Hudi·Pinot 관련 포스트를 2~3개 읽는다.
2주차 — SQL + 스트리밍 개념: 세션화·시계열·퍼널에 초점을 맞춘 SQL 문제를 하루 4개씩 풀고, Kafka 토픽·파티션, Flink 윈도잉, exactly-once vs at-least-once, 워터마크, 지연 이벤트 같은 스트리밍 기본 개념을 공부해 주말까지 화이트보드에 Flink 잡을 그릴 수 있는 수준을 목표로 한다.
3주차 — 시스템 설계 + Python: 주 2~3개의 시스템 설계 문제(서지 프라이싱 파이프라인, ETA 데이터 인프라, 마켓플레이스 헬스 대시보드, 드라이버 수익 정산 등)를 45분 타이머로 연습하고, 하루 3개씩 상태 관리와 스트림 처리 로직 위주의 Python 문제를 풀며, Cadence·AthenaX·Michelangelo 관련 기술 블로그 포스트를 추가로 읽는다.
4주차 — 마무리와 풀 모의면접: 4~5라운드를 연달아 진행하는 풀 모의 루프를 한 번 진행하며(에너지 관리가 생각보다 중요하다는 점을 유의), 행동 인터뷰에서 가장 약한 스토리를 다듬고, 이 루프의 차별점인 데이터 모델링 라운드를 최소 3회 더 타이머를 걸고 재훈련한다. 면접 전날에는 프로세스를 복습하고 충분히 수면하며 팀의 기술 스택 변화와 온콜 로테이션에 대한 질문 3~4개를 준비한다.
준비 기간이 4주 미만이면 이 일정을 압축하고, 6~8주 이상 여유가 있다면 Uber 기술 블로그를 더 깊이 읽고 모의 루프를 여러 번 진행하라는 것이 저자의 조언이다.

Key Takeaways

Uber DE 인터뷰의 가장 큰 차별점은 45~60분짜리 독립된 데이터 모델링 라운드다 — 저자에 따르면 시간 압박 속에서 백지 상태로 스타 스키마를 설계해본 적이 없는 지원자의 약 60%가 이 라운드에서 얼어붙는다.
Uber의 비즈니스는 실시간이므로 스트리밍은 선택이 아니다 — Kafka, Flink, Pinot, Hudi에 대한 유창함이 시스템 설계 전반에서 기대되며, 스트리밍이 필요한 상황에서 배치를 기본값으로 제시하면 회사를 조사하지 않았다는 신호로 읽힌다.
기술 폰스크린도 워밍업이 아니다 — 저자의 관찰상 이 단계에서 지원자의 대략 절반이 필터링되므로 온사이트 라운드와 동일한 강도로 준비해야 한다.
라이더-드라이버-트립-결제-평점-환불-분쟁-서지존으로 이어지는 마켓플레이스 데이터 복잡도는 일반적인 이커머스 스키마보다 훨씬 얽혀 있어 데이터 모델링과 시스템 설계 양쪽에서 신중하게 다뤄야 한다.
행동 인터뷰는 Amazon Bar Raiser만큼 형식화되어 있지는 않지만 하이어링 매니저가 거부권을 가지므로 가볍게 볼 라운드가 아니며, STAR 구조에서 Action(50%)과 수치화된 Result를 갖춘 구체적 스토리가 필수다.
저자가 권하는 준비 순서는 데이터 모델링을 가장 먼저 마스터한 뒤 SQL·스트리밍을 쌓고 시스템 설계, 마지막으로 모의면접을 진행하는 것이며, 이 순서를 거꾸로 해서 SQL과 시스템 설계에만 치중하고 데이터 모델링을 소홀히 하는 것이 가장 흔한 지원자의 실수라고 지적한다.