Companies

Stripe

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

Overview

Stripe의 Data Engineer 채용 프로세스는 리크루터 스크린부터 오퍼까지 보통 3~4주가 걸리는, 업계에서 가장 빠른 축에 속하는 루프다. 가장 큰 특징은 알고리즘 문제(LeetCode)를 의도적으로 배제하고 대신 'SQL Bug Squash'라는 전용 라운드와 48시간짜리 실전형 테이크홈 프로젝트로 대체했다는 점이다. 모든 질문이 결제(payments) 도메인 맥락 위에서 출제되며, idempotency·reconciliation·exactly-once 같은 개념을 얼마나 깊이 이해하는지가 통과 여부를 가른다.

LeetCode를 전혀 쓰지 않는다 — Stripe는 알고리즘 퍼즐을 채용 시그널로 쓰지 않는다고 공개적으로 밝혔으며, 모든 코딩 문제는 실전 데이터 엔지니어링(지저분한 이벤트 로그 변환, 엣지 케이스가 있는 CSV 파싱, 정산 함수 구현) 형태다.
'SQL Bug Squash'라는 45~60분 전용 라운드가 있다 — 4~5개의 서브틀하게 깨진 프로덕션 SQL 쿼리를 디버깅하는, 다른 주요 빅테크 DE 인터뷰에는 없는 독자적인 라운드다.
48시간짜리 테이크홈 프로젝트가 형식적 절차가 아니라 실제 채용 결정에 크게 반영된다 — 코드 품질, 테스트, 문서화, 엣지 케이스 처리를 정밀하게 채점한다.
모든 질문이 결제 도메인에 뿌리를 두고 있다 — idempotency, reconciliation, exactly-once, audit trail을 이해하지 못하면 통과할 수 없다.

Timeline

#	단계	형식	소요 시간	평가 항목
1	Recruiter Screen	Phone call	30 min	Role fit, comp expectations, payments interest signal
2	Take-Home Project	Async	48 hours window	Data modeling, code quality, tests, documentation
3	Technical Phone Screen	Video call	60 min	Take-home walkthrough + extra technical questions
4	Onsite Loop	3-4 rounds, 45-60 min each	1일(분산 가능)	SQL Bug Squash, Data Modeling, Coding, Values
5	Debrief & Decision	Internal	영업일 2~4일	Hiring committee sync, decision, offer call

Rounds

0 Take-Home Project (Async, 48시간) 이메일로 프로젝트 스펙을 받아 48시간 창 내에 제출한다. 데이터 모델링, ETL 설계, 또는 결제 유사 데이터에 대한 분석 위주의 현실적인 과제다. 48시간은 창(window)일 뿐 실제 집중 작업 시간은 4~8시간이면 충분하도록 설계됐다. 저자에 따르면 이 단계에서 지원자의 약 절반이 필터링될 만큼 결코 형식적인 절차가 아니다.

Focus Areas

데이터 모델 설계 — 유스케이스에 맞는 합리적인 스키마인가코드 품질 — 읽기 쉽고 모듈화되어 있으며 프로덕션 수준인가테스트 — 트랜스포메이션 단위 테스트와 파이프라인 통합 테스트가 있는가문서화 — 설계 결정과 트레이드오프를 설명하는 README가 있는가엣지 케이스 처리 — null 값, 지연 도착 데이터, 중복을 고려했는가속도보다 완성도 — 잘 다듬은 6시간짜리 제출물이 엉성한 12시간짜리보다 낫다

Sample Question

결제 프로세서의 데이터를 나타내는 4개의 CSV 파일(charges, refunds, disputes, customers)이 주어진다. 이 파일들을 인제스트하고, 깔끔한 분석 스키마로 모델링하며, 고객 세그먼트별로 나눈 일별 매출 리포트를 생성하는 데이터 파이프라인을 만들라. 테스트, 문서화, 설계 선택에 대한 간단한 서술을 포함하라.

Solution Approach

README.md에 데이터 모델과 그 이유, 시간이 더 있었다면 무엇을 다르게 했을지를 설명하고, src/·tests/·data/·output/로 나뉜 깔끔한 디렉터리 구조를 갖추며, 모든 변환 함수에 단위 테스트와 엔드투엔드 통합 테스트를 작성한다. 의사결정 지점마다 "이건 함수입니다"가 아니라 "환불 없는 charge도 리포트에 나타나야 하므로 여기서는 left join을 선택했습니다"처럼 이유가 담긴 주석을 남기고, README에 처리한 엣지 케이스와 시간이 더 있었다면 처리했을 엣지 케이스를 정직하게 적는다.

Common Mistakes

테스트가 없다 — Stripe에서는 자동 탈락 시그널이다
400줄짜리 단일 스크립트에 함수 분리가 없다 — 자동 탈락 시그널이다
README를 생략한다 — README가 평가 비중의 절반을 차지한다
코딩 과제로만 취급한다 — 이것은 데이터 엔지니어링 과제이며 코드보다 데이터 모델이 더 중요하다
20시간을 쏟는다 — 오버엔지니어링은 보상받지 못하며, Stripe가 보고 싶은 것은 판단력이다

1 Technical Phone Screen 화상 통화, 60분. 인터뷰어가 30~40분간 지원자의 테이크홈을 함께 훑어본 뒤, 남은 시간에 1~2개의 추가 기술 질문을 던진다.

Focus Areas

왜 이 데이터 모델을 선택했는가, 어떤 대안을 고려했는가왜 그 테스트들을 작성했는가, 시간이 더 있었다면 어떤 테스트를 추가했을 것인가동일 파일이 중복 인제스트되는 상황을 이 파이프라인이 어떻게 처리하는가아직 존재하지 않는 고객을 참조하는 charge 레코드가 들어오면 어떻게 되는가데이터가 1000배 더 커진다면 어떻게 되는가

Sample Question

결제 API가 초당 5만 건의 이벤트를 인제스트한다고 할 때, idempotency를 어떻게 설계할지 코드 없이 설계와 트레이드오프만 말로 설명하라.

Solution Approach

인터뷰어는 기억력이 아니라 판단력을 시험한다. 정직하게 답하는 것이 핵심이다. 예를 들어 "고객 테이블에 SCD Type 2를 쓸까 고민했지만 이 스코프에서는 단순 스냅샷으로 충분했다. 시간이 더 있었다면 고객 세그먼트가 시간에 따라 변하므로 SCD Type 2를 추가했을 것이다"처럼 답한다.

이렇게 말하면 좋다

테이크홈에서 내린 결정을 정직하게 방어한다. "고객 테이블에 SCD Type 2를 쓸까 고민했지만 이 스코프에서는 단순 스냅샷으로 충분했습니다. 시간이 더 있었다면 SCD Type 2를 추가했을 것입니다."

2 SQL Bug Squash 온사이트, 45~60분. Stripe 루프를 정의하는 라운드로 다른 주요 빅테크 DE 인터뷰에는 없다. 공유 에디터/문서에서 라이브 디버깅을 진행하며, 서브틀하게 깨진 프로덕션 SQL 쿼리 4~5개가 샘플 데이터 및 '기대 출력'과 함께 주어진다. 실제 출력은 틀려 있고, 그 이유를 찾아 고쳐야 한다.

Focus Areas

잘못된 join 타입 — inner join이어야 할 자리에 있어야 할 행을 누락시키는 경우, 특히 환불 없는 charge 조회에서 자주 나온다윈도우 함수의 off-by-one — ROW_NUMBER는 1부터 시작하는데 쿼리가 0-인덱스처럼 다루거나, LAG의 기본값이 NULL이어야 할 자리에 0을 기대하는 경우타임존 처리 오류 — 데이터는 UTC인데 리포트는 사용자 로컬 시간이어야 하고 쿼리가 변환을 하지 않는 경우NULL 처리 — status != 'refunded' 같은 WHERE 절이 status가 NULL인 행을 조용히 걸러내 버리는 경우필터링 전 집계 — WHERE로 테스트 트랜잭션을 걸러내기 전에 SUM이 먼저 일어나 매출이 부풀려지는 경우통화 불일치 — 서로 다른 통화의 charge를 변환 없이 합산하는, Stripe에 특히 치명적인 버그 유형

Sample Question

성공한 charge에서 환불 금액을 제외한 월별 매출(USD)을 계산하도록 되어 있는 쿼리인데 결과가 틀렸다. SELECT DATE_TRUNC('month', c.created_at) AS month, SUM(c.amount - COALESCE(r.amount, 0)) AS revenue_usd FROM charges c LEFT JOIN refunds r ON r.charge_id = c.id WHERE c.status = 'succeeded' GROUP BY 1 — 왜 틀렸는가?

Solution Approach

버그가 최소 두 개 있다. 통화 변환이 없어서 EUR charge가 USD인 것처럼 합산된다. 그리고 한 charge에 환불이 여러 건이면 join이 charge 행을 여러 번 복제해 금액 차감이 부풀려진다. 깔끔한 수정은 charge별로 환불을 먼저 집계하는 CTE를 만든 뒤 단일 charge 행에 join하고, rates 테이블로 통화를 변환하는 것이다.

이렇게 말하면 좋다

생각의 흐름을 소리 내어 말한다. "쿼리를 위에서 아래로 읽어볼게요. LEFT JOIN은 맞는 것 같고, WHERE 절이 succeeded charge만 필터링하는 것도 괜찮아 보이네요. 잠깐, 통화 변환이 없네요. amount 컬럼이 항상 USD인가요?"

피해야 할 답변

"그냥 처음부터 다시 짤게요" — 핵심을 놓친 답이다. Bug Squash는 남의 코드를 읽고 문제를 찾아 외과적으로 고칠 수 있는지를 시험한다. 재작성은 탈락 시그널이며 실제 프로덕션 디버깅 방식과도 다르다.

Common Mistakes

디버깅 대신 재작성을 시도한다 — 자동 탈락 시그널
통화 버그를 놓친다 — Stripe는 135개 이상의 통화로 결제를 처리하므로 통화 인식 코드는 타협 불가다
샘플 데이터로 머릿속 시뮬레이션을 돌려보지 않는다 — "X가 null인 행이 있다면 이 쿼리는 무엇을 반환하는가"를 기본 점검으로 삼아야 한다
버그 하나만 찾고 멈춘다 — 쿼리당 보통 2~3개의 버그가 있으므로 계속 파고들어야 한다

3 Data Modeling and System Design 온사이트, 60분. 화이트보드(또는 가상 화이트보드)에서 결제 특화 문제에 대한 데이터 모델이나 파이프라인을 설계한다.

Focus Areas

idempotency를 올바르게 처리하는 트랜잭션 모델을 설계할 수 있는가reconciliation — 우리가 청구한 것과 은행이 정산한 것을 매칭하는 개념을 이해하는가스트리밍 맥락에서 exactly-once 시맨틱스를 추론할 수 있는가audit trail과 불변(immutable) 금융 이벤트를 모델링할 줄 아는가

Sample Question

"Stripe의 charges API 뒤에 있는 데이터 모델을 설계하라. charge는 생성, 캡처, 환불, 부분 환불, 분쟁(dispute) 상태를 거칠 수 있으며 임의 시점의 charge 전체 상태를 재구성할 수 있어야 한다" / "우리의 내부 결제 기록을 은행에서 받는 일일 정산 리포트와 매칭하는 reconciliation 파이프라인을 설계하라. 불일치는 24시간 내에 사람이 검토하도록 표면화되어야 한다" / "초당 5만 건이 들어오고 200ms 내에 판단이 내려져야 하는 실시간 사기 탐지 시그널 파이프라인을 설계하라"

Solution Approach

요구사항 확인(5~7분, 처리량·지연시간·일관성 요구사항과 exactly-once 여부를 명시적으로 질문) → 결제 특화 제약 명시(3~5분, idempotency·audit trail·다중 통화·exactly-once를 먼저 선언) → 상위 아키텍처(10~15분, Ingestion→Processing→Storage→Serving을 기술 이름과 함께) → 심화(15~20분, 장애 처리·백필·reconciliation·지연 도착 데이터) → 트레이드오프(5분) 순서로 진행한다. idempotency(재시도되어도 같은 응답을 내는 idempotency key + TTL 저장·중복 제거), reconciliation, exactly-once, append-only/event-sourced 모델(금융 데이터는 제자리 수정 대신 새 이벤트가 이전 상태를 대체하고 현재 상태는 계산됨), audit trail을 핵심 개념으로 삼는다. Stripe는 데이터 레이크에 Apache Iceberg를, 상태 기반 스트리밍에 Apache Flink를(idempotency와 exactly-once 요구 때문에 Flink가 기본 선택), 이벤트 전송에 Kafka를, 배치 오케스트레이션에 Airflow를 무겁게 쓰는 회사라는 점을 언급하면 좋다.

이렇게 말하면 좋다

항상 도메인부터 시작한다. "결제는 exactly-once 시맨틱스를 요구합니다. 아키텍처를 건드리기 전에 이게 설계를 어떻게 제약하는지부터 생각해보겠습니다."

피해야 할 답변

"at-least-once로 전달하고 다운스트림에서 dedupe하겠습니다" — 기술적으로 맞을 때도 있지만 Stripe에서는 exactly-once를 진지하게 여기지 않는 사람으로 읽힌다. 기본값은 exactly-once 설계로 잡고, 그다음에 트레이드오프를 논의해야 한다.

4 Practical Coding 온사이트, 45~60분. 라이브 코딩이며 Python이 기본이다. LeetCode식 퍼즐이 아니라 실전 문제가 나온다.

Focus Areas

적절한 에러 핸들링을 갖춘 깔끔하고 프로덕션급 코드테스팅 패턴 — "이 함수를 어떻게 테스트하겠는가"를 물을 수 있다엣지 케이스 — 금융 데이터에는 null 금액, 음수 금액, 통화 불일치, 지연 이벤트 등이 많다idempotency — 같은 입력에 항상 같은 출력을 내는 함수를 작성할 수 있는가

Sample Question

charge_created, charge_captured, charge_refunded, charge_disputed로 구성된 charge 이벤트 스트림을 받는다. 각 이벤트는 charge_id, event_type, amount_cents, currency, timestamp를 가진다. 일부 이벤트는 중복이고 일부는 순서가 뒤바뀌어 도착한다. 각 charge의 현재 상태(total_captured, total_refunded, total_disputed, current_status, last_updated)를 반환하는 함수를 작성하라.

Solution Approach

이 문제는 idempotency(중복 처리), 상태 관리(이벤트 로그로부터 현재 상태 계산), 순서 뒤바뀜 처리(더 이른 타임스탬프의 이벤트가 이후 상태를 덮어쓰면 안 됨), 통화 인식(통화 간 단순 합산 금지)을 동시에 시험하는 실제 Stripe형 문제다.

이렇게 말하면 좋다

코딩 전에 먼저 명확화 질문을 한다. "금액은 환불에서도 항상 양수인가요? 어떤 통화 변환을 가정해야 하나요? 중복의 정의는 무엇인가요 — 같은 event_id인가요, 아니면 같은 (charge_id, event_type, timestamp) 조합인가요?"

피해야 할 답변

"먼저 시간 복잡도부터 생각해보겠습니다" — Stripe는 이런 문제에서 Big-O를 신경 쓰지 않으며, 이를 신경 쓴다는 것 자체가 과제를 잘못 이해했다는 시그널이다.

Common Mistakes

명확화 없이 곧바로 코드부터 짠다 — Stripe에서는 자동 탈락 시그널
헬퍼 함수를 나누지 않는다 — 60줄짜리 함수 하나보다 10줄짜리 함수 6개가 테스트하기 쉽다
테스트를 잊는다 — 요청받지 않아도 어떻게 테스트할지 언급해야 한다
통화를 무시한다 — 항상 물어야 한다

5 Values / Culture 온사이트, 45~60분. 대화형이며 Stripe의 운영 원칙(operating principles)에 맞춰 프레이밍된 행동 질문을 던진다.

Focus Areas

Users First — 실제 사용자/고객 시그널에 근거해 무언가를 재설계한 경험Think Rigorously — 합의가 아니라 원칙에서부터 추론해 어려운 결정을 내린 경험Move with Urgency — 품질을 희생하지 않으면서 빠르게 출시한 경험Trust and Amplify — 자신의 결과물뿐 아니라 팀원을 더 효과적으로 만든 경험Global Optimization — 자기 팀 범위를 넘어 전체 시스템을 최적화하려 생각한 경험

Sample Question

"단순한 이해관계자 요청이 아니라 실제 사용자 시그널에 기반해 데이터 파이프라인을 재설계했던 경험을 말해달라" / "불확실한 상황에서 기술적 결정을 어떻게 내리는가? 구체적인 사례로 설명해달라" / "시간을 더 쓰고 싶었지만 빠르게 출시해야 했던 경험을 말해달라. 그 트레이드오프를 어떻게 조율했는가"

Solution Approach

구체적인 스토리와 수치화된 결과, 처음부터 끝까지 설명할 수 있는 의사결정이 핵심이다. 인터뷰어는 지원자가 실제로 Stripe가 일하는 방식대로 일하는지 증거를 찾는다. 일반적인 행동 답변은 통과하지 못한다.

이렇게 말하면 좋다

"내부 사용자들이 매일 raw 이벤트 테이블에 같은 다섯 개 쿼리를 반복 실행하고 있다는 걸 발견했습니다. 일별 집계 테이블을 만들어 쿼리 시간을 4분에서 6초로 줄였고, 한 분기 만에 채택 팀이 0개에서 12개 팀으로 늘었습니다."

피해야 할 답변

"저는 항상 속도와 품질의 균형을 맞추려고 합니다" — 일반론적인 답은 실패한다. 원칙이 아니라 스토리로 답해야 한다.

Culture — Stripe의 다섯 가지 문화 패턴(Users First / Think Rigorously / Move with Urgency / Trust and Amplify / Global Optimization)

Stripe의 문화는 인프라 빌더답고 엄격하며 사용자 중심적이라는 것이 저자의 평가다. 행동 인터뷰(Values/Culture 라운드)뿐 아니라 다른 라운드 전반에서도 이 다섯 가지 패턴이 반복적으로 관찰된다고 한다. 인터뷰어는 원칙을 말로만 아는지가 아니라 실제로 그렇게 일해왔는지 구체적 증거(무엇이 신호였는지, 어떤 대안을 검토하고 왜 기각했는지, 성공을 어떻게 측정했는지, 지금이라면 무엇을 다르게 할지, 누가 관여했고 이견은 없었는지)를 후속 질문으로 파고들어 확인한다.

Prep Strategy

1주차 — 결제 도메인과 SQL 디버깅: idempotency, payment intent, reconciliation, chargeback, dispute, settlement 등 Stripe 결제 기초 문서를 읽고, SQL을 새로 작성하는 대신 남의 SQL(오픈소스 프로젝트, Stack Overflow 등)을 읽고 답을 보기 전에 버그를 먼저 찾는 연습을 한다. 하루 2~3개씩 SQL Bug Squash 스타일 문제를 푼다.
2주차 — 테이크홈 대비와 데이터 모델링: Kaggle 등의 소규모 공개 금융 트랜잭션 데이터셋으로 6~8시간 타임박스를 걸고 테스트와 README를 갖춘 파이프라인을 만들어 실전 테이크홈을 모의 진행한다. 매일 1개씩 원장(ledger) 모델, 트랜잭션 상태 테이블, reconciliation 페어링 위주의 데이터 모델링 연습을 하고, Stripe 엔지니어링 블로그의 'Data at Stripe' 시리즈를 읽는다.
3주차 — 시스템 설계와 Python: 결제 특화 시스템 설계 문제를 주 2개씩, 60분 타이머를 걸고 5단계 프레임워크(요구사항 확인→도메인 제약 명시→상위 아키텍처→심화→트레이드오프)로 연습한다. 하루 2~3개씩 상태 기반 처리·idempotency·다중 통화 연산·엣지 케이스를 다루는 Python 문제를 풀고 매 풀이마다 테스트를 작성하며, Stripe의 5가지 가치를 다시 읽고 자신의 문화 스토리 5~7개 초안을 작성한다.
4주차 — 마무리와 풀 모의면접: SQL Bug Squash 라운드와 결제 테마 데이터 모델링 라운드를 최소 1회씩 포함한 풀 모의면접을 2회 진행하고, 가장 약한 문화 스토리를 다른 사람이 후속 질문을 던지는 방식으로 다시 다듬는다. 2주차에 만든 테이크홈을 4시간 안에 처음부터 다시 만들어 더 깔끔한 버전이 나오는지 확인하고, 면접 전날에는 스토리를 복습하고 Stripe 데이터 플랫폼에 대한 질문 3~4개를 준비한다.
준비 기간이 4주 미만이면 이 일정을 압축하고, 6~8주 이상 여유가 있다면 테이크홈 시뮬레이션과 풀 모의 루프를 각각 두 번씩 진행하라는 것이 저자의 조언이다.

Key Takeaways

Stripe의 DE 인터뷰는 알고리즘이 아니라 (1) SQL 디버깅 능력과 (2) 결제 도메인(idempotency, reconciliation, exactly-once) 이해를 동시에 요구한다는 것이 핵심 주장이다 — 저자에 따르면 대부분의 지원자가 LeetCode에는 과도하게 준비하고 이 두 가지에는 준비가 부족하다.
48시간 테이크홈은 형식적 절차가 아니다 — 저자의 관찰상 이 단계에서 지원자의 절반가량이 걸러지며, 테스트 부재나 함수 분리 없는 단일 스크립트는 자동 탈락 시그널로 취급된다.
SQL Bug Squash는 SQL 작성이 아니라 SQL 읽기·디버깅 능력을 시험하는 Stripe 고유의 라운드로, 쿼리 하나에 보통 2~3개의 버그가 있으므로 첫 번째 버그를 찾고 멈추면 안 되며, 특히 통화 변환 누락은 Stripe에서 치명적인 버그 유형으로 꼽힌다.
데이터 모델링은 저자의 관찰상 약 70%의 루프에 별도 라운드로 포함될 만큼 비중이 높은 스킬이며, append-only/event-sourced 원장 모델과 amount+currency를 항상 함께 저장하는 습관이 반복적으로 강조된다.
시스템 설계에서는 exactly-once를 기본값으로 놓고 설계한 뒤 트레이드오프를 논의해야 하며, at-least-once+dedupe를 기본값으로 제시하면 도메인을 진지하게 여기지 않는 신호로 읽힐 수 있다.
행동 인터뷰는 Users First, Think Rigorously, Move with Urgency, Trust and Amplify, Global Optimization 다섯 가지 원칙에 대한 구체적이고 수치화된 스토리를 요구하며, 일반론적인 답변("항상 속도와 품질의 균형을 맞춘다")은 통과하지 못한다는 것이 저자의 지적이다.