Airbnb

Focus Areas

Sample Question

예약 테이블(booking_id, guest_id, listing_id, check_in, check_out, status)과 리스팅 테이블, 호스트 테이블이 주어진다. 2025년 기준 각 호스트의 fill rate(예약된 밤 수를 총 가용 밤 수로 나눈 값)를, 호스트가 된 지 첫 90일 이내에 해당하는 밤에 한정해 계산하라. 그다음 각 마켓(도시) 내에서 fill rate로 호스트 순위를 매겨라.

Solution Approach

호스트별 파티션의 야간(night) 단위로 예약을 확장하는 CTE를 만들고, 호스트 온보딩일 기준 90일 윈도우로 조인한 뒤 가용 밤 수를 세는 분모를 구성하고, 마지막으로 마켓 내 순위를 매기는 윈도우 함수를 적용하는 식으로 접근한다. SQL 문법만 암기하고 분모 구성 자체를 고민해보지 않은 지원자를 걸러내는 유형의 문제라고 저자는 설명한다.

Common Mistakes

• 야간 단위 질문에 예약(booking) 단위를 그대로 그레인으로 쓴다 — 야간 단위 확장이 필요하다
• 체크아웃이나 취소 타임스탬프의 NULL 처리를 건너뛴다
• 타임존과 마켓(지역) 맥락을 잊는다 — Airbnb는 글로벌로 운영된다

Focus Areas

Sample Question

booking_id, status(requested/confirmed/modified/cancelled/completed), event_ts, 그리고 check_in/check_out이 담긴 payload를 가진 예약 이벤트 딕셔너리 스트림을 받는다. 일부 이벤트는 순서가 뒤바뀌어 있고 일부는 중복이다. 각 예약의 최종 상태(가장 최근의 유효한 체크인/체크아웃 포함)를 반환하는 함수를 작성하라.

Solution Approach

상태 관리, 뒤늦게 도착하는 이벤트, 멱등적 처리를 시험하는 실전 DE 문제로, LeetCode식 퍼즐이 아니라고 저자는 설명한다.

Common Mistakes

• booking_id별 상태를 고려하지 않고 단일 패스 루프만 작성한다
• event_ts 동률 처리를 잊는다 — 타이브레이커 규칙을 정하고 명시해야 한다
• 취소 후 확정(cancelled-then-confirmed) 같은 엣지 케이스를 가정만 하고 확인 질문을 하지 않는다

Focus Areas

Sample Question

"Airbnb의 예약 비즈니스용 데이터 모델을 설계하라. 호스트 분석, 게스트 리텐션, 마켓별 매출 리포팅을 지원해야 한다" / "Airbnb의 검색 경험용 데이터 모델을 설계하라. 검색 랭킹 분석, 전환 퍼널, search-to-book 어트리뷰션을 지원해야 한다" / "Airbnb의 가격 시스템용 데이터 모델을 설계하라. 일별 가격 추적, 호스트 가격 결정, 다이내믹 프라이싱 실험을 지원해야 한다"

Solution Approach

저자가 제시하는 프레임워크: (1) 5~7분간 이 모델이 답해야 할 비즈니스 질문을 명확히 하고 웨어하우스 레이어인지 서빙 레이어인지 확인, (2) 3분간 그레인을 한 문장으로 정의하고 고려했던 대안 그레인과 기각 이유를 설명(예약 단위 vs 야간 단위 vs 이벤트 단위), (3) 10분간 팩트 테이블 스케치 — 트랜잭션 팩트(fact_booking), 누적 스냅샷(fact_booking_lifecycle), 주기적 스냅샷(fact_listing_availability_daily) 등 필요에 따라 여러 개, (4) 15분간 차원 스케치(dim_listing, dim_host, dim_guest, dim_date, dim_market, dim_payment_method) — dim_listing은 가격·상태 변경 이력이 매출 리포팅에 중요하므로 거의 항상 Type 2로 설계하는 것이 맞다고 저자는 설명, (5) 10분간 모델에 대한 2~3개 쿼리(예: 예약 시점 가격을 포함한 리스팅별 전환율, 가입월별 게스트 코호트 리텐션)를 실제로 짚어보며 그레인 실수를 검증.

Common Mistakes

• 그레인에 대한 논의를 건너뛴다 — 모든 팩트 테이블은 한 문장으로 그레인이 정의되어야 한다
• 측정값(measure)을 차원 테이블에 넣는다 — 예약 매출은 팩트에 있어야지 dim_listing에 있으면 안 된다
• 모든 차원을 Type 2로 설계한다 — 비용이 크므로 각각 정당화가 필요하다
• 리스팅 속성이 시간에 따라 바뀐다는 점을 놓친다 — 매출 리포팅에는 예약 시점의 리스팅 속성이 중요하므로 dim_listing의 Type 2가 거의 항상 정답에 가깝다
• 게스트-호스트-리스팅-예약-리뷰의 관계가 트리가 아니라 그물망(web) 구조라는 마켓플레이스 복잡도를 처리하지 못한다

Focus Areas

Sample Question

"Airbnb의 메트릭 플랫폼(Minerva 같은)을 설계하라" / "A/B 테스트용 실험 데이터 파이프라인을 설계하라" / "검색 랭킹 데이터 파이프라인을 설계하라" / "다이내믹 프라이싱 데이터 인프라를 설계하라"

Solution Approach

(1) 5~7분 요구사항 확인 — 어떤 데이터를 서빙하는지, 소비자가 필요로 하는 지연 수준, 일별 리포트인지 준실시간 대시보드인지. (2) 3~5분 백오브엔벨로프 추정 — 일별 예약/검색 건수, 이벤트 크기, 스토리지 증가량. (3) 10~15분 상위 아키텍처 스케치 — Ingestion → Processing → Storage → Serving → Metrics layer, Kafka/Spark/Hive/Airflow/Presto/Minerva를 이름으로 명시. (4) 15~20분 인터뷰어가 지목한 영역 심화 — 백필, 스키마 진화, 데이터 품질, exactly-once vs at-least-once, 늦게 도착하는 데이터. (5) 5분 트레이드오프 — 예: "생태계 때문에 Airflow를 선택했지만 초단위 스케줄링이 필요하면 이벤트 드리븐 방식을 고려하겠다".

Common Mistakes

• 요구사항 확인 단계를 건너뛰고 곧바로 다이어그램으로 들어간다
• Airflow를 깊이 알지 못한다 — 백필을 어떻게 처리하는지 물으면 catchup, max_active_runs, 멱등적 DAG를 이야기할 수 있어야 한다
• 메트릭 레이어를 언급하지 않는다 — Minerva는 업계에서 자주 인용되는 데이터 시스템이므로 메트릭 레이어가 왜 웨어하우스와 별도로 존재하는지 알아야 한다
• 스키마 진화 계획이 없다 — 예약/리스팅 스키마는 계속 바뀐다

Focus Areas

Sample Question

"Airbnb에서 호스트 품질을 어떻게 측정하겠는가?" / "예약량이 전주 대비 5% 감소했다. 어떻게 조사하겠는가?" / "'성공적인 Airbnb 숙박'을 정의하고 어떻게 측정할지 설명하라" / "제품팀이 새로운 가격 기능을 출시하려 한다. 이를 평가하기 위해 어떤 지표를 추적하겠는가?"

Solution Approach

지표 정의형 질문: (1) 목표를 명확히 한다(랭킹용인지, 호스트 코칭용인지, 마케팅용인지), (2) 후보 지표 2~3개와 트레이드오프를 제시, (3) 1~2개를 주 지표로 선택해 분자/분모/기간/제외 조건을 정확히 정의, (4) 엣지 케이스(신규 진입자, 이상치, 세그멘테이션)를 인지한다. 조사형 질문: (1) 기준선을 명확히 하고(전주 대비인지, 작년 동기 대비인지, 기대치 대비인지), (2) 분해해서 어떤 하위 지표가 움직였는지 찾고, (3) 전체 마켓/특정 지역, 디바이스, 리스팅 티어별로 세그먼트하고, (4) 계절성·릴리스·검색 랭킹 변경·가격 변경·경쟁사 움직임 등 가설을 제시하고, (5) 각 가설을 데이터로 어떻게 검증할지 설명한다.

Common Mistakes

• "전환율을 추적하겠습니다"처럼 무엇의 전환율인지, 어떤 기간인지 없는 뭉뚱그린 답변
• 조사형 질문에서 분해 단계를 건너뛴다 — 구조화된 사고를 보고 싶어한다
• 정의하기 전에 명확화 질문을 하지 않는다 — 점수의 절반이 명확화 단계에 있다는 것이 저자의 강조점
• 공급 측 지표와 수요 측 지표를 혼동한다 — 호스트 품질은 공급 측, 예약 전환은 수요 측, 마켓플레이스 유동성은 양쪽 모두에 걸친다

Focus Areas

Sample Question

"데이터 사이언티스트와 지표 정의를 두고 이견이 있었던 경험은? 어떻게 해결했는가?" / "데이터가 준비되지 않아 PM의 요청을 반려해야 했던 경험은?" / "이해관계자가 당신의 데이터를 근거로 내린 결정이 결국 틀렸던 경험은? 어떤 일이 있었는가?" / "왜 하필 Airbnb인가?"

Solution Approach

"왜 Airbnb인가"는 형식적인 질문이 아니다. 마켓플레이스 데이터, 미션, 혹은 지원 중인 특정 팀에 대한 구체적이고 진지한 답을 기대하며, "큰 회사에서 일하고 싶다" 같은 일반적인 답변은 잘해야 소극적인 통과에 그친다고 저자는 지적한다.

Common Mistakes

• "왜 Airbnb인가"에 데이터/미션/팀과 무관한 일반적인 답변을 한다

Focus Areas