베를린PM이직기#3. 2차PM면접-답변 편
한국에서만 일한 9년 차 PM의 베를린 이직 도전과 성공기
베를린PM이직기#3. 2차 PM면접-질문 편에 이어서 답변 편을 써본다.
1. SAR-L 구조에 따라 답변하기
일반적인 behavorial questions들에 대해 답할 때 가장 중요한 건 STAR 방법에 따라 구조적으로 명확하게 답변하는 것이라고 생각한다.
STAR란 답변을 할 때 사용하면 좋을 유명한 메서드인데, 아래와 같다.
출처:https://www.caseinterview.com/star-method/S - Situation:어떤 상황이었는지. 어떤 문제가 있었는지.
T - Task: 그 상황에서 어떤 것을 했어야 했는지
A - Action: 내가 그래서 무슨 액션을 취했는지
R - Result: 그래서 결과가 어떻게 되었는지
하지만, 나는 이를 SAR-L로 변형해서 사용했다.
S - Situation: 어떤 상황이었는지. 어떤 문제가 있었는지.
A - Action: 내가 그래서 무슨 액션을 취했는지
R - Result: 그래서 결과가 어떻게 되었는지
L - Learning: 그것으로부터 무엇을 배웠는지, 그 후에 어떻게 이를 해결할 것인지.
그 이유는 실제로 답변을 하다 보니 S와 T부분이 너무 길어지는 게 좋지 않았고, 빠르게 내가 한 액션 부분으로 넘어가는 것이 효과적이었기 때문이다.(SAR-L 답변 시트 참고)
예시 질문과 답변을 한번 보겠다.
Question
팀의 디자이너와 충돌이 있다면 어떻게 할 것입니까? 혹은 그러한 경험이 있다면 어떻게 해결했습니까?
Answer
S: 디자이너 중에 계속 약속한 deadline을 어기는 디자이너가 있었습니다. 여러 번 이 상황이 발생했고 이 부분이 나아지지 않아서, 갈등이 생겼습니다.
A: 저는 Open Conversation을 지향합니다. 그래서 디자이너와 티타임을 하면서 약속한 마감 날을 넘기는 이유에 대해 듣고 싶다고 이야기했습니다. 알고 보니, 디자이너는 제 요구사항이 너무 구체적이어서, 그대로 따라서 하기 싫었고 그 요구 사항 이 외에 다르게 이를 해결할 수 있는 방법이 있는지를 연구하고 싶었다고 했습니다. 좀 더 문제에 대해 함께 고민하고 싶은데, 요구사항과 함께 오는 부분에서 불만이 있다는 것을 알게 되었습니다.
그래서 저는 그녀가 더 적극적으로 문제 해결 방안을 모색할 수 있도록 Solution 모색 단계에 함께 하기로 해했고, 문제 해결 방안을 탐색할 수 있는 공간을 제공하면서 요구 사항을 전달하기로 했습니다.
R: 그렇게 하자 그 디자이너는 훨씬 동기부여를 받을 수 있었고 더 이상 마감 기한을 넘기지 않게 되었습니다.
L: 저는 이를 통해 대화를 통해 문제의 원인을 알고 서로가 만족할 수 있는 방법을 찾는 것이 중요함을 깨달았고, 적극적이고 오너쉽이 있는 팀 멤버에게 좀 더 앞 단계를 함께 하자고 제안해서 더 동기부여를 할 수 있다는 것을 알게 되었습니다.
특히 나는 Action과 Learning부분이 중요하다고 생각한다. 어떤 생각으로 그 액션을 취했고, 무엇을 배웠는지를 명확히 전달한다면 좋은 답변이 될 것이라고 생각한다. Situation부분은 최대한 한 두줄로 줄이는 게 좋다고 생각한다.
나만의 '스토리 박스'를 미리 만들어 두자
스토리 박스는 말 그대로 내가 답변할 때 쓸 이야깃거리, 예시들을 상황에 맞게 정리해서 모아둔 공간이라고 보면 될 것 같다.
미리 질문 영역들, 그에 대한 대표 예시 질문들을 모아놓고 이에 대해 SAR-L를 간단하게 써둔다. 그리고 계속해서 연습하면 응용해서 그 스토리를 사용할 수 있게 된다.
나는 이를 하기에 Notion을 너무 잘 이용했다.
나는 노션에 아래와 같이 1. 내가 만든 product에 대한 경험, 2.PM skill을 증명할 수 있는 경험, 3. 리더십/팀워크를 증명할 수 있는 경험, 4.Risk 매니징을 했던 경험, 5. 클라이언트나 이해 관계자들을 매니징 한 경험으로 나누어서 대표 질문들을 리스팅 하고, 이를 클릭하면 답변을 볼 수 있게 미리 준비해 두었다.
노션에 만들어둔 Story box 섹션2. Case Study Questions의 답변 방법
다음으로는 공포의(?) Case study 질문들에 대한 답변 방법이다.
이는 처음엔 정말 막막한데, 자꾸자꾸 연습하고 답변하다 보면 어느 정도 그 구조에 익숙해지면서 그나마 공포감은 줄어드는 것 같다.
Case Study에도 유형이 있다.
1. 제품 개선에 대한 케이스 스터디 질문
예로 페이스북에서 Music 서비스를 하고 싶다. 네가 페이스북 Music service PM이라면 이를 어떻게 만들어야 할까? 스포티파이를 더욱 개선하고 싶다. 네가 스포티파이의 PM이라면 어떻게 할 것인가?
등의 질문들을 한다.
이러한 제품 개선에 대한 질문의 답변은 아래 링크들을 참고하도록 하자...
1) PM Deigo의 유튜브: How to answer Product Case Questions
2) Exponent의 유튜브: 페이스북 Movie feature를 만든다면?
3) 케이스 스터디 질문을 받았을 때 답변 Structure (PM Deigo 사이트에서 발췌)
2. 제품 지표에 대한 케이스 스터디 질문
예로 인스타그램의 최근 3주간 리텐션이 10% 하락했다면 너는 이 문제의 원인을 어떻게 파악할 것인지? 인스타그램의 North Star / Success Metric (핵심 지표)는 무엇으로 잡겠는지? 등의 질문을 한다.
답변은 아래 링크들을 참고하도록 하자.
1) Product Management Exercises의 유튜브: 구글 캘린더의 North Star Metric은 뭘까?
2) Exponent의 유튜브: Root Cause Analysis
3) Data Interview Pro의 유튜브: Facebook Metric Interview Question and Answer
3. Estimation 인터뷰
비행기에 탁구공은 몇 개가 들어갈까? 뉴욕에 있는 창문을 모두 몇 개일까? 등의 황당한 추측형 질문이 가끔 들어올 수 있다. 난 실제로 받아본 적은 없는데... 미국의 구글이나 페이스북에 같은 회사에서는 간혹 던지는 것 같아 보인다.
어떻게 이 문제를 break down 해서 해결해 나가는지 과정을 중요하게 본다. 실제 답변의 정확도는 그렇게 중요하지 않다고 한다.
예시와 답변 샘플: 샌프란시스코의 레스토랑 개수는 몇 개 일지 추측해보라
그 외에 여러 가지 Mock Interview 질문과 사용자들의 예시 답변을 보기 위해 이 사이트들이 유용하다.
이 역시 답변의 구조를 미리 나는 Notion에 유형별로 정리해 두었다. 그런데 실제로 쓸 일은 1번밖에 없었다는...
어쨌든 PM Case Study의 질문을 받았을 때 당황하지 않도록 준비해서 나쁠 건 없어 보인다.
그리고 가장 중요한 포인트는 '무조건 Clarifying Questions를 하라는 것이다' 질문이 너무 광범위하거나 할 때 몇 가지 제약사항을 미리 파악하기 위해, 그리고 답변을 좀 더 정확하게 하기 위해 바로 답변을 준비하지 말고, 답 변전에 되도록 몇 가지의 Clarifying question은 하도록 하자.
위 포스팅한 비디오에서 보면 항상 면접자들을 답변을 하기 전에 이러한 질문을 하는 것을 볼 수 있다.
예를 들면, Facebook Music 서비스를 만들어보라고 했을 때
- 기존 Facebook의 한 카테고리로 생각하는 것인지 다른 플랫폼으로 분리해서 만드는 것을 생각하는 것인지?
- 전 세계 타깃으로 생각하는 것인지? 아님 그것을 내가 정하길 원하는지?
- Music 서비스라는 것이 이미 시중의 음악을 Streaming 할 수 있도록 제공하는 서비스를 생각하는 것인지, 사람들이 직접 Music을 만들어 올리고 공유하는 서비스인지, 아님 이것을 내가 정의하길 원하는지?
등을 먼저 물어보고서, 답변을 구조화하면 좋을 것이다.
작가 링크트리: https://linktr.ee/nomadyun
유투브: '노마드 윤실장'을 검색해 주세요 :)
