데이터 분석가 면접 예상질문 — SQL 정답만 맞히면 평가표 두 칸이 빕니다

면접 일정이 잡혔습니다. 창에는 조인, 윈도우 함수, 유의확률 설명이 빼곡합니다. 예상질문도 잔뜩 저장했죠. 그런데 면접관이 예를 들어 이렇게 묻습니다. ‘결제 전환율이 내려갔습니다. 왜죠?’ 당신은 쿼리 순서까지 잘 설명합니다. 다음 질문이 옵니다. ‘그 전환율, 취소 주문은 뺐나요? 그래서 내일 무엇을 바꾸면 됩니까?’ 여기서 준비한 답이 끊깁니다.

먼저 결론부터. 데이터 분석가 면접 예상질문은 SQL·통계·사업 질문이 따로 노는 목록이 아닙니다. 한 숫자를 ‘믿어도 되나 → 무슨 뜻인가 → 무엇을 바꿀 건가’로 넘기는 한 줄짜리 검증입니다. SQL 정답만 준비하면 뒤의 두 칸은 깨끗합니다. 너무 깨끗해서 문제입니다. 🙃

🧾 실제 전형도 SQL과 판단을 따로 봅니다

원티드에 실린 콴다 Data Analyst 인턴 공고를 보면 사전 과제는 실제 데이터팀이 고민하는 문제를 다루고, 첫 면접에서는 그 과제를 놓고 하는 정성 토론과 SQL 테스트를 함께 진행합니다. 공고는 SQL 테스트를 ‘데이터 집계 능력’ 확인이라고 범위까지 좁혀 적었습니다.

이 공고 하나로 모든 회사를 일반화할 수는 없습니다. 다만 실제 채용 절차 하나만 봐도 집계 능력과 문제를 두고 토론하는 능력을 같은 것으로 치지 않는다는 점은 확인됩니다.

20년 넘게 뽑아본 입장에서, 겪은 바로는 데이터 분석가 면접이 끝나면 면접관들이 답을 숫자 신뢰성·문제 정의·의사결정 칸에 따로 옮겨 적고, 핵심 칸 하나가 비면 SQL 점수가 좋아도 다음 전형에 올리지 않았습니다.

평가표가 하는 일은 감상을 모으는 게 아닙니다. ‘쿼리를 짰다’를 ‘이 숫자를 회의에 가져가도 된다’로 바꿀 증거가 있는지 확인하는 겁니다.

🔍 예상질문 하나를 세 칸으로 쪼개세요

예시 상황은 하나면 됩니다. ‘이번 주 결제 전환율이 지난주보다 내려갔다.’ 이 문장을 놓고 질문 세 개를 만드세요.

① 숫자 신뢰성 — 그 수치를 믿어도 됩니까?
‘주문의 기준 시각은 결제 시각입니까, 생성 시각입니까?’ ‘취소·중복 주문은 어떻게 처리했습니까?’를 묻습니다. 정답 쿼리를 자랑하는 자리가 아니라, 그 쿼리가 틀릴 자리를 먼저 찾는 칸입니다.

② 문제 정의 — 무엇이 내려갔다고 부르는 겁니까?
‘분모는 방문자입니까, 결제창 진입자입니까?’ ‘지난주와 비교한 이유는 무엇입니까?’를 묻습니다. 숫자가 같아도 분모와 비교 기준이 바뀌면 뜻이 바뀝니다.

③ 의사결정 — 그래서 누가 무엇을 바꿉니까?
‘결제팀이 오류 구간을 먼저 되돌릴까요, 유입 채널부터 나눠 볼까요?’ ‘어떤 결과가 나오면 이 제안을 접겠습니까?’를 묻습니다. 함께 지켜야 할 부작용 지표, 즉 가드레일 지표도 여기 붙습니다.

세 질문은 지식 퀴즈가 아닙니다. 숫자가 행동으로 넘어가는 동안 부러질 곳을 찾는 순서입니다.

🪤 ‘올랐습니다’보다 ‘이러면 틀렸습니다’가 강합니다

지원자는 성과를 확신 있게 말해야 한다고 배웁니다. 데이터 분석가 면접에서는 반쪽만 맞는 조언입니다. 숫자를 세게 말하는 것보다 내 해석이 깨지는 조건을 먼저 말하는 편이 더 강합니다.

예를 들어 ‘새 추천 영역을 낸 뒤 구매가 늘었습니다’에서 끝내지 마세요. ‘다만 같은 기간 광고 유입 비중도 바뀌어서 추천 영역의 효과라고 단정할 수 없었습니다. 기존 유입군만 나눠 다시 비교했고, 그래도 차이가 남는지 확인했습니다’까지 가세요.

여기서 반증은 어려운 말이 아닙니다. ‘무엇이 나오면 내 설명이 틀렸다고 인정할 것인가’입니다. 이 한 줄이 있으면 면접관은 당신이 숫자를 만드는 사람인지, 숫자를 의심할 줄 아는 사람인지 구분할 수 있습니다. 😐

🗂 프로젝트 하나를 세 문장으로 다시 쓰세요

오늘 예상질문 목록을 더 저장하지 마세요. 당신 프로젝트 하나를 고르고 아래 세 문장만 적으세요.

신뢰 — ‘이 숫자는 ○○를 제외했고, △△이면 틀릴 수 있습니다.’
정의 — ‘이 지표를 고른 이유는 ○○ 결정과 가장 가깝기 때문입니다.’
결정 — ‘그래서 ○○팀이 △△를 바꿨고, □□가 나오면 되돌리기로 했습니다.’

실제 행동이 바뀌지 않은 분석이라면 꾸미지 말고 ‘제안했으나 채택 여부는 확인하지 못했습니다’라고 쓰세요. 빈칸을 허풍으로 채우면 꼬리질문에서 바로 다시 빕니다.

완료 기준은 세 문장 모두에 주어와 조건이 들어가는 것입니다. 그 뒤에 SQL, 실험, 시각화 질문을 붙이세요. 이제 기술명이 공중에 뜨지 않고 당신의 판단에 매달립니다.