데이터 분석가 면접은 모호한 사업 질문을 신뢰할 수 있는 분석으로 바꾸는 능력을 평가합니다. 좋은 지원자는 SQL, 지표 판단, 데이터 품질, 명확한 사업 커뮤니케이션을 결합합니다.
3~5회
일반적인 면접 횟수
45~60분
SQL 및 사례 면접 시간
5개 이상
핵심 역량 영역
3~6주
권장 준비 기간
면접관이 평가하는 역량
—
SQL: 조인, 필터링, 집계, 윈도 함수, 데이터 수정을 정확히 수행할 수 있는가.
—
지표: 숫자를 나열하는 데 그치지 않고 사업을 올바르게 나타내는 척도를 정의할 수 있는가.
—
사업 이해: 결과를 고객, 매출, 위험, 운영에 연결할 수 있는가.
—
품질: 결측, 중복, 이상치, 계측 오류, 편향된 표본을 찾을 수 있는가.
—
대시보드: 보기 좋은 화면을 넘어 의사결정에 유용한 보고를 설계할 수 있는가.
—
커뮤니케이션: 가정, 확신도, 한계, 제안을 명확히 전달할 수 있는가.
좋은 분석가는 쿼리에만 답하지 않습니다
실제로 알아야 할 질문을 확인하고, 데이터로 답할 수 있는지 검증하며, 가정을 밝히고, 분석이 어떤 의사결정을 지원하는지 설명합니다. 정확성과 판단력이 모두 필요합니다.
데이터 분석가 채용 절차
일반적인 전형은 초기 면담, SQL, 분석 사례, 대시보드 및 시각화, 이해관계자 커뮤니케이션, 행동 면접으로 구성됩니다.
일반적인 전형 단계
1
채용 담당자 면담: 직무 적합성, 사용 도구, 업계, 보상, 지원 동기를 확인합니다.
2
채용 책임자 면담: 과거 분석, 이해관계자, 성과, 설명 방식을 깊이 살펴봅니다.
3
SQL 면접: 조인, 집계, 필터링, 윈도, 날짜, null, 디버깅을 평가합니다.
4
분석 사례: 지표 변화를 진단하고 제품 변경을 평가하며 대응을 제안합니다.
5
대시보드 및 시각화: 지표, 차트, 필터, 보고 빈도를 평가합니다.
6
행동 면접: 주인의식, 모호함, 우선순위, 이해관계자, 불완전한 데이터 대응을 봅니다.
SQL 면접
분석 사례
핵심 질문
올바른 데이터를 정확히 조회하고 변환할 수 있는가.
데이터를 근거 있는 의사결정으로 바꿀 수 있는가.
강한 평가 신호
정확한 조인과 조건, 적절한 세분성, 목적에 맞는 윈도 함수
명확한 가정, 세분화, 정의, 한계, 제안
흔한 실수
서로 다른 세분성의 데이터를 조인해 행을 부풀리기
품질이나 세그먼트를 확인하지 않고 결론 내리기
효과적인 준비
현실적인 스키마, 코호트, 유지율, 퍼널, 디버깅 연습
진단, 실험, 대시보드 비평, 경영진용 요약 연습
세분성은 흔한 함정입니다
사용자, 주문, 주문 항목, 세션, 이벤트처럼 서로 다른 세분성의 데이터를 조인하면 많은 오류가 생깁니다. SQL을 작성하기 전에 분석 단위와 각 행이 무엇을 나타내는지 정의하세요.
SQL 면접 기초
드문 문법보다 세분성, 조인, 조건, 집계, 날짜, null, 검증을 정확히 판단하는 능력이 중요합니다.
SQL 문제를 푸는 확실한 절차
1
작성 전에 사업 질문과 필요한 출력 열을 확인합니다.
2
한 행이 사용자, 주문, 주문 항목, 세션, 이벤트, 계정, 날짜 중 무엇을 나타내는지 정의합니다.
3
필요한 테이블을 찾고 각 조인의 카디널리티를 확인합니다.
4
날짜, 상태, 테스트, 취소, 환불, 내부 계정 조건을 신중히 정의합니다.
5
세분성을 정한 뒤 집계하고 필요하면 CTE에서 사전 집계한 후 조인합니다.
6
순위, 누계, 중복 제거, 이전 및 다음 이벤트에는 윈도 함수를 사용합니다.
7
건수, 고유값, 합계, null, 중복, 사업 규칙으로 결과를 검증합니다.
핵심 개념
세분성
각 행이 나타내는 단위입니다. 잘못 정하면 매출, 사용자, 주문, 이벤트가 부풀려집니다.
LEFT JOIN
일치하는 행이 없어도 왼쪽의 모든 행을 유지합니다. 활동이 없는 사용자나 날짜를 포함할 때 사용합니다.
윈도 함수
관련 행을 하나로 집계하지 않고 순위, 누계, LAG, LEAD, 중복 제거를 계산합니다.
코호트
가입 월, 첫 구매, 유입 채널, 요금제처럼 공통 시작점이나 특성을 가진 집단입니다.
✓ 권장 사항
—
조인 전에 세분성 정의하기
—
읽기 쉬운 CTE로 복잡한 로직 정리하기
—
조건을 WHERE와 JOIN 중 어디에 둘지 확인하기
—
명확한 이유가 있을 때만 DISTINCT 사용하기
—
건수와 구체적인 예시로 출력 검증하기
✗ 피해야 할 사항
—
SELECT DISTINCT로 중복의 원인을 숨기기
—
주문 항목 세분성의 매출을 사전 집계하지 않고 사용자에 조인하기
—
LEFT JOIN으로 남긴 null을 조건 때문에 의도치 않게 제외하기
—
시간대와 날짜 경계를 무시하기
—
지표를 의사결정에 연결하지 않고 제시하기
SQL 면접 질문
사용자, 주문, 이벤트, 구독, 유지율, 매출, 퍼널에 관한 현실적인 질문을 연습합니다.
답변 구조 — 필터링 → 조인 → 집계 → 정렬 → 행 제한
취소 및 환불된 주문을 포함할지 확인하고 보통 완료 주문만 대상으로 합니다. 주문을 날짜와 상태로 필터링하고 고객별로 그룹화해 매출 합계를 구한 뒤 내림차순 상위 5개를 선택합니다.
날짜 기준과 세분성이 중요합니다. 매출이 주문 항목 테이블에 있다면 먼저 집계해 조인으로 부풀지 않게 합니다. 5위 동률을 모두 포함하려면 LIMIT 대신 순위 함수를 사용합니다. 마지막으로 대상 매출 합계, 건수, 중복을 검증합니다.
예상 추가 질문
5위와 같은 금액의 고객을 모두 포함하려면 어떻게 하겠습니까?
매출이 주문 항목 세분성이라면 무엇이 달라집니까?
환불을 어떻게 제외하겠습니까?
답변 구조 — 코호트 정의 → 재방문 정의 → LEFT JOIN → 집계
먼저 유지율을 가입 후 정확히 7일 차 활동으로 볼지 첫 7일 중 한 번이라도 활동한 것으로 볼지 정의합니다. 7일 차라면 1월 가입자의 user_id와 signup_date를 CTE에 두고 7일 차 유효 이벤트를 LEFT JOIN합니다.
LEFT JOIN을 사용하면 돌아오지 않은 사용자도 남습니다. 분모는 관측 가능한 대상 사용자, 분자는 이벤트가 있는 고유 사용자입니다. 7일의 관측 기간이 아직 지나지 않은 사용자는 분모에서 제외합니다. 유입 채널, 기기, 지역, 가입 주차별로도 나눌 수 있습니다.
예상 추가 질문
7일 차 유지율과 7일 이동 구간은 어떻게 다릅니까?
관측 기간이 7일 미만인 사용자는 어떻게 처리하겠습니까?
어떤 이벤트를 활동으로 계산하겠습니까?
답변 구조 — 사용자별 구매에 순번 부여
유효하고 완료된 구매만 필터링한 뒤 row_number() over (partition by user_id order by purchase_at, order_id)로 번호를 부여하고 2번 행을 선택합니다. 같은 시각의 구매가 있어도 order_id로 순서를 고유하게 만듭니다.
모든 사용자를 표시하려면 결과를 사용자 테이블에 LEFT JOIN해 두 번째 구매가 없는 사람은 null로 둡니다. 큰 테이블에서는 user_id와 구매 시각 인덱스가 유용합니다.
예상 추가 질문
두 번째 구매가 없는 사용자도 어떻게 표시하겠습니까?
같은 시각의 구매는 어떻게 처리하겠습니까?
첫 구매와 두 번째 구매 사이의 일수는 어떻게 계산하겠습니까?
답변 구조 — 사용자마다 각 단계의 최초 시각을 하나씩 유지
조건부 집계로 사용자당 한 행을 만들고 각 단계의 최초 시각을 가져와 반복 이벤트를 중복 계산하지 않습니다. 순서가 필수라면 인증은 가입 후, 온보딩은 인증 후, 구매는 온보딩 후에 일어나도록 조건을 둡니다.
단계 간 전환율과 전체 전환율을 계산하며 각 분자는 다음 단계의 고유 사용자, 분모는 이전 단계의 고유 사용자입니다. 기기, 유입 채널, 지역, 코호트별로 나누면 이탈 지점을 찾을 수 있습니다. 중복, 단계 건너뛰기, 시간대, 테스트 계정, 지연 이벤트도 확인합니다.
예상 추가 질문
이벤트 순서를 어떻게 강제하겠습니까?
온보딩의 급격한 하락을 어떻게 조사하겠습니까?
퍼널을 어떻게 시각화하겠습니까?
지표 및 사업 사례 질문
적절한 지표를 정의하고, 변화를 의미 있는 단위로 나누며, 근거 수준에 맞는 확신도로 대응을 제안하는 능력을 평가합니다.
답변 구조 — 검증 → 세분화 → 퍼널 → 외부 요인 → 제안
먼저 계측 변경, 처리 지연, 시간대, 봇 제외, 앱 업데이트를 확인하고 원시 데이터와도 비교합니다. 다음으로 플랫폼, 버전, 지역, 유입 채널, 사용 기간, 요금제, 기기, 유입원별로 나눕니다.
앱 실행, 로그인, 탐색, 핵심 행동 중 어디가 줄었는지 확인합니다. 실행은 같고 활동이 줄었다면 제품 내부, 실행 자체가 줄었다면 알림, 유입, 계절성, 장애, 외부 요인이 후보입니다. 업데이트 후 오류가 원인이면 롤백합니다. 데이터 지연이라면 잘못된 긴급성을 만들지 않고 한계를 알립니다.
예상 추가 질문
먼저 어떤 시각화를 확인하겠습니까?
계절성과 제품 회귀를 어떻게 구분하겠습니까?
DAU는 줄고 매출은 늘었다면 무엇을 의미합니까?
답변 구조 — 목표 → 주요 지표 → 선행 지표 → 가드레일 → 세그먼트
목표가 발견, 사용, 구매, 유지, 객단가 중 무엇인지 확인합니다. 주요 지표는 클릭만이 아니라 가치를 나타내야 합니다. 전자상거래라면 활성 사용자당 추천을 통한 구매가 될 수 있습니다.
노출, 클릭률, 장바구니 추가, 전환율, 세션 매출, 범위, 다양성을 선행 지표로 보고 반품, 환불, 무관한 클릭, 지연, 문의, 자기잠식을 가드레일로 둡니다. 신규 및 기존 사용자, 카테고리, 기기, 노출 위치별로 나눕니다. 단기에는 A/B 테스트, 장기에는 유지와 재구매로 가치를 확인합니다.
예상 추가 질문
클릭률은 오르지만 구매가 늘지 않으면 어떻게 하겠습니까?
추천 품질을 어떻게 측정하겠습니까?
기존 구매의 자기잠식을 어떻게 찾겠습니까?
답변 구조 — 매출을 트래픽, 전환, 객단가, 구성, 가격, 유지로 분해
트래픽 증가가 전환율 하락보다 컸을 수 있습니다. 가격 인상, 번들 판매, 대형 고객, 고가 제품 구성으로 객단가가 올랐을 수도 있습니다. 방문자가 줄어도 가치가 높은 층으로 바뀌었거나 계측 정의가 변경됐을 가능성도 있습니다.
유입 채널, 제품, 지역, 신규 및 기존 사용자, 고객층, 기기별로 나누고 매출을 세션, 전환, 객단가, 환불, 재구매로 분해합니다. 전환율 분모가 세션, 사용자, 방문자 중 무엇인지도 확인합니다. 매출 증가의 질과 지속 가능성으로 평가합니다.
예상 추가 질문
먼저 어떤 분해를 하겠습니까?
매출 증가가 가격 인상 때문이라면 어떻게 판단하겠습니까?
지속 가능성을 어떻게 검증하겠습니까?
대시보드 및 시각화
좋은 대시보드는 차트 모음이 아니라 명확한 대상자를 위한 의사결정 도구입니다.
답변 구조 — 대상자 → 의사결정 → 지표 → 세그먼트 → 알림
먼저 대상자와 의사결정을 확인합니다. 경영진에게는 세부 운영 지표 전체가 아니라 성장, 유지, 수익화, 위험에 대한 요약이 필요합니다.
상단에는 MRR, 순 및 총매출유지율, 신규·확장·축소·해지 MRR, 유료 고객 수, 체험판에서 유료로의 전환율, ARPU, 필요하다면 CAC 회수기간과 목표 대비 실적을 둡니다. 고객 유형, 유입 채널, 요금제, 지역, 규모, 영업 지원 및 셀프서비스별로 나눌 수 있게 합니다.
시계열, 코호트, MRR 브리지, 해지 사유, 목표 차이로 성장 여부와 원인, 위험, 조사할 영역을 보여 줍니다. 정의, 갱신 시각, 필터, 책임자, 임계값도 표시합니다.
예상 추가 질문
첫 화면에 무엇을 표시하겠습니까?
프로덕트 매니저용이라면 어떻게 바꾸겠습니까?
오해를 막기 위해 무엇을 하겠습니까?
답변 구조 — 의사결정 확인 → 위험 설명 → 더 나은 표현 제안
먼저 그 차트가 지원할 의사결정을 확인합니다. 누적 매출이 둔화를 숨기거나, 카테고리가 많은 원형 차트가 차이를 가리거나, 구간을 표시하지 않아 과도한 확신을 줄 수 있다는 위험을 객관적으로 설명합니다.
같은 질문에 답할 수 있는 시계열, 코호트, 퍼널, 분포, 누적 막대, 요인 분해를 제안합니다. 원래 표현이 필요하다면 한계를 명시해 함께 보여 줄 수 있지만 자신의 권고안으로 삼지는 않습니다. 유용성과 분석적 정직성은 함께 지킬 수 있습니다.
예상 추가 질문
임원의 압박을 받으면 어떻게 하겠습니까?
오용되기 쉬운 차트에는 무엇이 있습니까?
불확실성을 어떻게 표현하겠습니까?
효과적인 대시보드 원칙
—
차트 유형이 아니라 의사결정과 대상자에서 시작하기.
—
대시보드 안에서 각 지표 정의하기.
—
가능하면 추세, 목표, 세그먼트를 함께 보여 주기.
—
갱신 시각, 출처, 책임자, 알려진 한계를 표시하기.
—
경영, 제품, 재무, 운영 용도를 한 화면에 억지로 담지 않기.
—
조치가 필요한 변화에만 알림 설정하기.
Excel 및 스프레드시트 질문
스프레드시트를 많이 사용하는 직무에서는 수식, 피벗 테이블, 데이터 정리, 대조, 검증 가능한 모델을 평가합니다.
답변 구조 — 파악 → 표준화 → 검증 → 문서화
먼저 행과 열, null, 중복, 데이터형, 불가능한 값, 날짜, 이상치를 파악하고 변경하지 않은 원본을 보존합니다. 공백을 제거하고 이름을 통일하며 날짜를 파싱하고 단위를 맞추고 표기 변형을 관리되는 카테고리에 매핑합니다. 중복 제거 전에 사업상 고유 키를 정의합니다.
합계와 건수를 신뢰할 수 있는 정보원에 대조하고 null, 고유값, 범위를 확인합니다. 변환 내용을 기록하고 원본과 정제된 데이터를 분리하며 보이지 않는 수작업을 피합니다.
예상 추가 질문
중복 행을 어떻게 처리하겠습니까?
자주 사용하는 수식은 무엇입니까?
파일을 검증 가능하게 만들려면 어떻게 하겠습니까?
답변 구조 — 탐색과 통제된 계산의 구분
피벗 테이블은 차원별로 빠르게 탐색, 집계, 요약하는 데 적합합니다. 수식은 코호트, 브리지, 가중 점수, 예외, 대조처럼 맞춤형이고 여러 단계이며 감사 가능한 로직에 적합합니다.
실무에서는 피벗으로 추세를 찾은 뒤 통제된 모델을 만듭니다. 정기 보고서는 깨지기 쉬운 수작업 시트에 의존하지 않고 재현 가능한 SQL 또는 BI 파이프라인으로 옮겨야 합니다.
예상 추가 질문
피벗 테이블에는 어떤 위험이 있습니까?
VLOOKUP과 INDEX/MATCH 또는 XLOOKUP을 어떻게 비교하겠습니까?
분석을 Excel에서 SQL이나 BI로 옮길 때는 언제입니까?
핵심 기술
XLOOKUP / INDEX MATCH
테이블 사이의 값을 매핑합니다. 키, 누락, 중복, 정확 일치와 근사 일치를 확인해야 합니다.
피벗 테이블
데이터를 빠르게 집계하고 분류합니다. 원본 범위, 집계 방식, 필터를 검증해야 합니다.
대조
합계가 재무, 제품 분석, CRM, 청구 같은 신뢰할 수 있는 정보원과 일치하는지 확인합니다.
실험 및 A/B 테스트
실험을 설계, 분석, 비판적으로 평가하고 데이터에서 실제로 어느 수준까지 결론을 낼 수 있는지 이해하는 능력을 평가합니다.
답변 구조 — 가설 → 무작위 배정 → 지표 → 가드레일 → 결정
가설은 새 디자인이 마찰을 줄여 이후의 부정적 영향 없이 구매 완료를 늘린다는 것입니다. 무작위 배정 단위, 표본, 기간, 노출, 대상 조건, 할당 고정을 확인합니다. 세션 단위로 배정하면 같은 사용자에게 다른 버전이 보일 수 있습니다.
주요 지표는 결제 시작에서 구매 완료로의 전환율입니다. 결제 오류, 소요 시간, 객단가, 추가 구매를 보조 지표로, 환불, 차지백, 문의, 지연, 오류, 불만을 가드레일로 둡니다. 통계적 유의성뿐 아니라 실무적 크기도 봅니다. 의미 있는 개선, 건전한 가드레일, 신뢰할 수 있는 계측, 안정적인 효과가 모두 있을 때만 출시를 권합니다.
예상 추가 질문
전환율과 환불이 모두 늘면 어떻게 하겠습니까?
결과를 너무 일찍 확인하는 문제를 어떻게 막겠습니까?
신규 사용자에게만 효과가 있다면 어떻게 하겠습니까?
답변 구조 — 검정력 확인 → 방향 평가 → 비용 고려 → 결정
유의하지 않다는 것은 효과가 없다는 뜻과 같지 않습니다. 표본 크기와 기간이 의미 있는 차이를 탐지할 수 있었는지 확인합니다. 효과 크기와 구간도 봅니다. 이익과 손실을 모두 포함하는 넓은 구간이라면 결론을 낼 수 없고, 0 근처의 좁은 구간이라면 영향이 작다고 볼 수 있습니다.
유지보수 비용, 위험, 전략도 고려합니다. 비용이 높고 측정 가능한 이점이 없는 기능은 출시하지 않아야 합니다. 전략 가치가 높거나 비용이 낮다면 개선 후 다시 측정할 수 있습니다. 설계, 관측 결과, 확신도, 한계, 제안을 구분해 설명합니다.
예상 추가 질문
“효과 없음”과 “결론 불가”는 어떻게 다릅니까?
기술에 익숙하지 않은 사람에게 어떻게 설명하겠습니까?
어떤 경우에 실험을 다시 하겠습니까?
데이터 품질 및 분석적 판단
분석의 신뢰성은 원천 데이터보다 높을 수 없습니다. 잘못된 의사결정을 만들기 전에 문제를 발견하는 능력을 평가합니다.
답변 구조 — 정의 → 정보원 → 조건 → 세분성 → 시점 → 대조
먼저 매출 정의를 비교합니다. 총액인지 환불, 할인, 세금, 차지백 차감 후인지, 주문일·결제일·배송일·청구일 중 무엇을 기준으로 하는지 확인합니다. 다음으로 정보원, 필터, 세분성을 봅니다. 테스트, 취소, 내부 계정, 지역, 주문 항목 조인, 시간대, 갱신 빈도도 차이를 만들 수 있습니다.
신뢰할 수 있는 정보원에서 시작해 차이 요인을 하나씩 더하고 빼는 브리지를 만들어 일치시킵니다. 어느 쪽이 틀렸는지만 밝히지 않고 공통 정의, 책임자, 공식 정보원, 재발 방지책을 정합니다.
예상 추가 질문
공식 정보원을 어떻게 선택하겠습니까?
재무와 제품에 서로 다른 정의가 필요하면 어떻게 하겠습니까?
불일치를 어떻게 전달하겠습니까?
답변 구조 — 결측 측정 → 원인 파악 → 처리 선택 → 공개
먼저 필드, 비율, 세그먼트, 기간, 정보원, 플랫폼별로 결측을 정량화합니다. 결측은 무작위가 아닐 수 있습니다. 선택 입력, 계측 오류, 지연, 연동, 개인정보 보호, 대상 아님 중 무엇이 원인인지 조사합니다.
원인에 따라 행을 제외하거나, 근거 있게 대치하거나, 미상 카테고리를 만들거나, 다른 정보원으로 보완하거나, 분석 범위를 제한합니다. 0과 미상은 같지 않습니다. 결측이 확신도에 어떤 영향을 주고 합리적인 가정을 바꿔도 결론이 유지되는지 설명합니다.
예상 추가 질문
행을 제외해도 되는 경우는 언제입니까?
결측값 대치에는 어떤 위험이 있습니까?
계측 오류를 어떻게 찾겠습니까?
계산 예시
발표 전 품질 확인
새로운 온보딩이 활성화를 개선했다는 점을 보여 주려는 상황입니다.
1
대상 집단 확인
가입 기간, 플랫폼, 국가, 대상 조건을 확인합니다.
2
지표 확인
활성화 정의, 계측, 중복, 봇, 테스트, 지연 이벤트를 확인합니다.
3
비교 확인
비교 가능한 집단을 사용하거나 전후 비교라면 계절성과 유입 구성을 조정합니다.
4
결론 확인
주요 세그먼트에서도 주장이 성립하고 가드레일이 악화되지 않았는지 확인합니다.
결과
결과뿐 아니라 그 결과를 신뢰할 수 있는 이유도 설명하므로 분석의 설득력이 높아집니다.
행동 및 이해관계자 질문
모호함, 압박, 커뮤니케이션, 우선순위, 데이터가 기대한 답을 뒷받침하지 않은 상황에 대한 대응을 다룹니다.
답변 구조 — 의사결정 → 분석 → 발견 → 제안 → 영향
출시, 가격, 마케팅, 제품, 운영, 우선순위 결정에 분석이 영향을 준 경험을 고릅니다. 사용한 데이터와 지표, 중요한 세그먼트, 예상 밖의 발견을 도구 세부 사항에 묻히지 않게 설명합니다.
다음으로 제안과 성과를 보여 줍니다. 수익성이 낮은 유입 채널을 찾아 예산을 옮겼거나, 클릭은 늘지만 유지율을 해치는 기능을 중단한 사례 등이 있습니다. 한계, 불확실성, 이해관계자 합의 과정도 포함합니다.
예상 추가 질문
영향을 어떻게 측정했습니까?
누가 제안에 반대했습니까?
지금이라면 무엇을 바꾸겠습니까?
답변 구조 — 긴급성 확인 → 방향 제시 → 한계 설명 → 검증 계획
먼저 의사결정, 기한, 위험을 확인합니다. 되돌릴 수 있고 위험이 낮은 결정이라면 잠정적 방향으로 충분할 수 있지만 매출, 고객, 규제, 전략에 관련되면 품질 기준을 높입니다.
오늘 답할 수 있는 것과 없는 것을 구분하고 필요하면 확신도를 표시한 잠정 추정치를 제공합니다. 동시에 정리, 검증, 대조 절차와 신뢰할 수 있는 답변의 일정을 제시합니다. 빠른 오답이 사실로 굳어지는 것을 막으면서 이해관계자가 움직일 수 있게 합니다.
예상 추가 질문
비현실적인 기한에 어떻게 이의를 제기하겠습니까?
방향성만 있는 답변으로 충분한 경우는 언제입니까?
확신도를 어떻게 전달하겠습니까?
답변 구조 — 영향 → 긴급성 → 공수 → 의존성 → 조율
의사결정 영향, 긴급성, 공수, 의존성, 가역성으로 우선순위를 정합니다. 내일의 출시 결정에 필요한 분석은 선택적인 대시보드 개선보다 보통 우선합니다.
각 요청의 의사결정과 책임자를 확인하고 반복되는 수작업 보고는 자동화 후보로 둡니다. 요청이 충돌하면 무엇을 언제 제공할 수 있는지, 어떤 결정이 의존하는지, 왜 그 순서를 권하는지 설명합니다. 분석 시간은 요청 수가 아니라 의사결정 품질에 사용해야 합니다.
예상 추가 질문
요청을 어떻게 거절하겠습니까?
무엇을 자동화하겠습니까?
경영진의 요청을 어떻게 처리하겠습니까?
데이터 분석가 면접 준비 전략
SQL, 사업 사례, 대시보드 비평, 스프레드시트, 커뮤니케이션 연습을 결합합니다. 정확하고 명확하며 의사결정에 유용한 답변을 목표로 합니다.
4주 준비 계획
1
1주 차: SQL 기초. 조인, GROUP BY, HAVING, 날짜, null, CASE, 정확한 집계를 연습합니다.
2
2주 차: 고급 SQL. 윈도, 코호트, 유지율, 퍼널, 중복 제거, 순위, 디버깅을 연습합니다.
3
3주 차: 분석 사례. 지표 하락, 실험, 매출, 대시보드, 제안을 연습합니다.
4
4주 차: 커뮤니케이션과 모의 면접. 분석을 명확히 설명하고 가정을 방어하며 프로젝트를 소개합니다.