데이터 과학자를 위한 행동 인터뷰 질문 대응 방법: STAR 방식은 유효한가?

STAR for behavioral interview questions

STAR 방법론 — 상황(Situation), 과제(Task), 행동(Action), 결과(Result) — 은 흔히 행동 인터뷰 질문에 답하는 프레임워크로 권장됩니다.

하지만 이 방법에는 여러 문제점이 있습니다.

첫째, 인터뷰 질문에 답하기 위한 '필수 사용' 방법론은 본능적으로 거부감이 듭니다. 흥미롭게도 개인의 특성과 개성을 중요시한다는 채용 담당자들이 이러한 획일적인 방법을 추천합니다.

다른 모든 사람과 똑같은 방식으로 개성을 표현한다? 그건 말이 되지 않습니다.

Answer Behavioural Questions as a Data Scientist

또 다른 문제는 STAR 방법론이 데이터 과학과 같은 기술적인 역할에 적합하지 않다는 점입니다. STAR는 행동 질문에 답하기 위한 것이지만, 데이터 과학에서는 기술적 측면이 '행동'에도 영향을 미칩니다. 완전히 잘못된 머신러닝 모델을 선택하면서 침착함을 유지했다는 것을 보여주는 것은 의미가 없습니다. 차분하게 재앙적인 실수를 하는 사람을 기업이 원하지는 않을 것입니다.

데이터 과학은 다음 세 가지 요소를 중심으로 합니다:

  • 복잡성: 문제가 복잡하지 않다면, 당신이 해결할 필요가 없었을 것입니다!
  • 사고방식: 답이 명확했다면, 스프레드시트로 해결하고 넘어갔을 것입니다!
  • 지표: 측정할 수 없다면, 어떻게 결정을 내리고 나중에 성과를 주장할 수 있을까요?
  • 따라서 인터뷰 답변에서는 다음과 같은 내용을 다루어야 합니다:

    • 복잡한 문제, 데이터, 모델 제한 사항의 모호함을 어떻게 헤쳐나갔는가?
    • 왜 그 분석 방법과 도구를 적용했는가? 왜, 어떻게 모델을 선택했는가?
  • 어떤 지표를 추적했으며, 모델이 어떤 영향을 미쳤는가?
  • 이러한 내용 없이는 프로젝트 매니저, 영업 담당자, 심지어 HR 담당자도. 같은 답변을 할 수 있습니다.

    STAR 방식은 기술적 차별화에 도움이 되지 않습니다. 문제 해결보다 스토리텔링을 장려하고, 사고 과정을 숨기며 영향에 대한 언급을 생략합니다. 게다가 로봇 같은 획일적인 답변을 조장합니다.

    그럼 STAR 없이 행동 질문에 답하는 몇 가지 팁을 드리겠습니다.

    행동 질문 답변 팁 – 데이터 과학자 방식

    데이터 과학자로서 인터뷰 질문에 답하기 위한 방법들입니다.

    Tips for Answering Data Science Behavioral Questions

    이제 실제 인터뷰 질문에 위 팁을 적용하는 방법을 보여드리겠습니다.

    인터뷰 질문 예시

    몇 가지 전형적인 행동 인터뷰 질문 예시를 제시하겠습니다. 먼저 STAR 접근법으로 답변한 뒤, 더 나은 답변을 제안하겠습니다. 더 나은 답변이란 "여기 데이터 과학자가 있다!"라고 외치는 답변을 의미합니다.

    예시 #1

    Q: 실수를 했던 경험에 대해 말해보세요.

    STAR 답변:

    상황: 이전 직장에서 고객 이탈 모델에 대한 촉박한 마감일이 있었습니다.

    과제: 이해관계자 회의 전에 모델 성능 지표를 제출해야 했습니다.

    행동: 빠르게 파이프라인을 구축했지만 데이터 누출 열을 제거하는 것을 잊었습니다.

    결과: 모델이 좋아 보였지만 프로덕션 환경에서 실패했습니다. 항상 누출을 확인해야 한다는 교훈을 얻었습니다.

    더 나은 답변:

    고객 이탈 모델링 프로젝트에서 92% 정확도를 달성한 scikit-learn 모델을 훈련시켰습니다. 우리의 과거 평균이 최대 80%였던 것을 고려하면 이례적으로 높은 수치였습니다. 뭔가 이상했지만, 겉으로 보기에는 문제가 없어 보였습니다.

    pandasprofiling과 커스텀 날짜 시간 검사를 사용하여 파이프라인을 감사했습니다. 그때 문제를 발견했습니다: customerlastsupportcall 기능에 고객 이탈 이벤트 이후의 타임스탬프가 포함되어 있었습니다. 모델이 예측 시점에서 가질 수 없는 정보에 접근했던 것이죠. 이는 전형적인 데이터 누출입니다.

    실수는 제 잘못이었습니다. 시간적 논리를 검증하지 않고 결과를 서둘러 발표했던 것입니다. 이를 인식한 후, pandas를 사용하여 이탈 전 데이터만 필터링하도록 피처 파이프라인을 재구축하고, 이벤트 순서를 존중하고 미래 편향을 피하기 위해 TimeSeriesSplit로 교차 검증 프로세스를 다시 작성했습니다. 새로운 모델은 79%로 떨어졌는데, 이는 과거 성능에 훨씬 더 가깝고 훨씬 더 신뢰할 수 있는 수치입니다.

    이후 pytest와 Great Expectations를 사용한 자동화된 검증 확인을 추가하여 미래 지향적 특성을 조기에 플래그 지정했고, 팀의 참고자료로 내부 위키에 해당 사건을 문서화했습니다.

    데이터 과학에서 의심스러울 정도로 좋은 결과는 거의 승리가 아닌 경고 신호임을 배웠습니다. 데이터를 조사하고, 지표에 의문을 제기하며, 모델이 그것이 정보를 제공하기 위한 실제 조건을 반영하는지 확인하는 것이 우리의 일입니다.

    예시 #2

    Q: 이해관계자와 갈등이 있었던 경험에 대해 말해보세요.

    STAR 답변:

    상황: 마케팅 담당자와 캠페인 기여도 분석 작업을 하고 있었습니다.

    과제: 그녀는 특정 채널이 모든 전환을 주도하고 있다는 것을 증명하고 싶어했습니다.

    행동: 데이터가 그 결론을 뒷받침하지 않는다는 것을 보여주었습니다.

    결과: 결국 멀티 터치 기여 모델을 사용하기로 합의했습니다.

    더 나은 답변:

    네 개의 유료 채널에 걸친 전환 기여도를 분석하고 있었는데, 상황이 복잡해졌습니다. 마케팅 리드는 디스플레이가 전환의 60%를 담당한다고 주장했는데, 이는 전적으로 일화적 피드백과 직관에 기반한 것이었습니다.

    BigQuery에서 데이터를 가져왔고, 기존의 라스트 터치 모델은 디스플레이에 단지 15%의 전환만 기여했습니다. 이로 인해 마찰이 생겼습니다. 한쪽은 모델을 신뢰했고, 다른 쪽은 그들의 직감을 신뢰했습니다.

    기여도는 거의 명확하지 않습니다. 저는 그 주장을 무시하지 않았습니다. 라스트 터치 모델이 초기 퍼널 영향을 과소평가한다는 것을 인식했습니다. 그래서 전체 사용자 여정 데이터를 추출하고 판다스로 정리한 후 대안을 제안했습니다: 시간 감소 가중치를 적용한 로지스틱 회귀 모델이었습니다. 이 아이디어는 각 채널의 한계 기여도를 포착하는 것이었는데, 최근의 접점에 약간 더 높은 가중치를 부여했습니다.

    scikit-learn을 사용하여 모델을 훈련시켰고, 전환까지 시간에 따라 지수 감소를 특성에 적용했습니다. 모델의 예측 확률에 따라 기여도를 재할당했을 때, 디스플레이의 점유율은 15%에서 25%로 상승했습니다. 60%는 아니지만, 부분적 영향을 반영하는 의미 있는 개선이었습니다.

    이것은 대화의 방향을 바꾸는 데 도움이 되었습니다. 마케팅 팀은 본능에 너무 의존하지 않으면서도 충분한 검증을 받아 의견이 존중받고 있다고 느꼈습니다. 또한 Streamlit 대시보드를 구축했는데, 이는 매주 업데이트되고 이해관계자들이 감소 가정을 조정하여 실시간으로 기여도 변화를 볼 수 있게 했습니다.

    이 경험을 통해 기여 분석은 하나의 "올바른" 숫자를 얻는 것이 아니라, 더 나은, 더 방어 가능한 결정을 지원하는 방식으로 불확실성을 정량화하는 것임을 재확인했습니다.

    예시 #3

    Q: 비즈니스 결정에 영향을 미친 경험에 대해 말해보세요.

    STAR 답변:

    상황: 우리 팀은 사용자 이탈을 이해하고 싶었습니다.

    과제: 나는 퍼널 데이터를 분석하라는 요청을 받았습니다.

    행동: 2단계에서 이탈을 보여주는 대시보드를 만들었습니다.

    결과: 제품 팀이 이를 사용하여 온보딩 플로우를 개선했습니다.

    더 나은 답변:

    온보딩 퍼널에서 높은 이탈률을 조사해달라는 요청을 받았을 때, 데이터는 모호했습니다. 가입과 첫 번째 액션 사이에 62%의 이탈률이 있었지만, 집계 뷰에서는 무엇이 이를 유발하는지 설명하지 못했습니다.

    SQL과 pandas를 사용하여 플랫폼과 획득 소스별로 분할하여 코호트 수준 퍼널 분석을 실행했습니다. 그때 신호가 나타났습니다: 안드로이드 사용자가 iOS 사용자보다 첫 단계에서 40% 더 자주 실패하고 있었습니다.

    기록된 버그나 계측의 적신호가 없었기 때문에 더 깊이 파고들었습니다. 세션 리플레이와 화면 해상도 데이터를 가져왔고, 그때 근본 원인이 떠올랐습니다: CTA 버튼이 작은 안드로이드 화면에서는 화면 아래 부분에 렌더링되고 있었습니다. 스크롤하지 않으면 보이지 않았는데, 이는 제품 팀이 주로 iOS 기기에서 테스트하고 있어서 놓친 부분이었습니다.

    내부 실험 플랫폼을 사용하여 안드로이드용 CTA를 재배치하는 A/B 테스트를 제안했습니다. 테스트 그룹은 활성화에서 18% 증가, 30일 유지율에서 6% 증가를 보였습니다.

    그러나 더 큰 성과는 프로세스 관련이었습니다: Metabase 대시보드를 구축하여 기기 코호트별 온보딩 유지율을 추적했습니다. 이 대시보드는 현재 세 개의 제품 팀에 걸쳐 주간 PM 검토 주기의 일부가 되어 플랫폼별 마찰을 더 일찍 포착하는 데 도움을 주고 있습니다.

    이는 단순히 UI 문제를 해결하는 것이 아니라, 데이터를 사용하여 측정 가능하고, 반복 가능하며, 실행 가능한 것을 만드는 것이었습니다.

    결론

    STAR 접근법은 일부 행동 인터뷰 질문에 답하는 데 도움이 될 수 있습니다. 그러나 이 접근법은 데이터 과학 인터뷰에 특별히 적합하지 않습니다.

    행동 질문에 답할 때도 데이터 과학자이며 그것도 좋은 데이터 과학자임을 보여줘야 합니다. 제가 제시한 예시와 팁을 따르고, 여러분의 개성과 경험에 맞게 약간 조정하면 인터뷰에서 좋은 성과를 거둘 수 있을 것입니다.