태그

전문성요약채용

최종 편집

Feb 27, 2024 3:28 PM

발행일

January 7, 2022

💡

김창준님이 주제별로 AC2 패치를 만들어서 진행 중이신데, 이 패치는 인터뷰 잘 하는 법에 대한 워크숍이었다. 총 3회에 걸쳐 진행된다(1월 6일, 13일, 20일). 내가 생각한 액기스 위주로 요약한다.

인터뷰의 제 1원칙

구체적 스토리

그럴듯한 거짓 정보를 말하기 어렵게 하라.

더 많은 정보를 말하게

단답형 질문 하지 마라. 상대가 짧게 말하고 끝나지 않게 해라.

신뢰 라뽀

대답을 끌어내는것뿐 아니라 저 사람이 편안하게 만들어야 함. 안그러면 스트레스 상황에서 말 잘 하는 사람을 뽑게 됨

떠올리게

기억 인출의 기회를 만들어서 표면적으로 답하지 않게

삼각측량

하나를 확인하기 위해 3가지 지점에서 측정. 확신이 안들면 다른 측면에서 질문
예를 들어 '적극성'은 하나의 사례에서 여러 측면을 보기 어려우니 사례를 두 개 듣는다. 이것도 삼각측량.

기술적인 측면에서의 적극성, 회사 시스템을 바꾸는 면에서의 적극성 등

direct하게 물어라. (내 의도가 뭔가)

괜히 간접적으로 물어보지 말고, 내가 알고 싶은 것을 정확히 좁혀서 들어가라

채용 인터뷰 @January 6, 2022

채용 in general (창준님 코멘트 복붙)

채용할 때 다음을 구사할 수 있으면 학계에서 밝혀진 효과적인 평가방법의 90%는 커버하신다고 보면 되겠습니다.

구조적 인터뷰 (역량 기반, behavioral)
Cognitive Task Analysis (어제 좀 다뤘고 다음주에 다룰 예정)
Situational Judgement Test
Work Sample Test

이 외에 타당도가 높은 거로 GMA (General Mental Ability) 테스트가 있으나(추가적인 validity 상승 있음) 여러분들이 뽑아야 될 분들은 이미 GMA가 일정 수준을 넘을 거라고 보기 때문에. 참고로 GMA는 일정 수준만 넘으면 업무 성과랑 상관관계는 확 떨어집니다. 또 최근 연구에서 integrity 테스트에서 추가적 타당도 상승이 있다고 하는 보고가 있으나 리스크가 높아서 저는 권하지 않습니다.

그 외 주의할 점

모든 대화에 의도를 담고, 의도를 해석해야 한다.

어떤 정보를 얻기 위한 질문인가? 이걸 염두에 두면 정보량은 확 늘고 인터뷰 시간은 줄어든다.
인터뷰이가 대답한 것에도 의도를 계속 구체적으로 물어봐야 한다.

‘직설적인 게 좋다’ → 직설적인 게 뭐냐?

인지 부하가 너무 많은 질문을 던지면 (과거의 무언가 중 가장 ~ 한 ~를 골라라) 사람들이 그냥 점프를 해버린다.

각종 bias가 수십가지 들어온다. 대표적으로 recency bias. 최근 일을 더 중요하게 생각함.

얼마나 많은 얘기를 듣는가, 랑 우리가 원하는 정보를 얼마나 많이 얻는가, 는 명백히 다르다.

답변이 평이하다면 질문의 난이도를 높여라. 전문가들이 도전적인 걸 물어봤을 때 갑자기 전문성을 쓰기 시작한다.

여러 명이 보면 인터뷰를 잘 하기 어렵다. 최대 인터뷰어 2명을 권한다.

인터뷰이가 긴장해서 라포형성 어려움. 난이도가 너무 높다.
대신, 평가를 잘 하기 위해서 녹취한다.
인터뷰에서 많이 들어가려는 이유는 대개 질문할 게 안 정해져있어서 그렇다. 구조화된 인터뷰 해라.

구조적 인터뷰 설계

왜 사람을 뽑으려고 하나? 무슨 문제를 해결하려고?

어떤 문제를 풀고자 하는지도 사람마다 생각하는 바가 다를 수 있어서 명확하게 해야 한다.

그 문제를 해결하는 데 어떤 역량이 중요한가?

숫자나 갯수, 연차 등은 별로 중요하지 않음. 경력 별로 없지만 정말 잘 하는 사람들이 있다. 짧은 시간 안에 확 치솟는 사람들. 그런 사람들을 어떻게 가려 뽑을 것인가.
이걸 토론하는 게 굉장히 중요함. 각자 생각하는 좋은 사람의 기준이 다른데, 토론을 통해 이게 드러날 것. 다른 점과 공통적인 점.

사실 이런 논의는 채용이 아니라, 직원 교육, 성과 평가 등을 위해 이미 했어야 하는 일들임.

의견이 갈리면 중요한 게 아닐 확률이 높음. 성과랑 직접적인 관계가 안 보이는 거. (충격을 줘서 일치시킬 수도 있긴 하겠지만..)
공통적인 게 드러났다면 이제 더 파고들어야 함.

개발자가 디버깅을 잘 하는 게 중요하다? 그럼 그건 대체 뭐냐? 기술 스펙 잘 이해하는 건가? 이렇게 파고들어야 함

그 역량을 확인하기 위해 어떤 질문을 할 것인가?

핵심 질문은 한 인터뷰에서 3-5개의 역량만 추려서 알아보도록 설계하는 게 좋다. 코어 질문을 다 하고 나서 시간이 남으면 상황에 맞는 질문을 해라.

미리 정해둔, 구조화된 질문을 해야 예측 능력이 올라가기 때문.
사람마다 다른 질문을 하면 잘 된다는 느낌이 있는데 통계적으로는 아니더라.

스크립트를 다 짜 둔 채로 인터뷰를 하라는 게 아니다. 전체 시나리오가 아니고, 순서도 없음.
이번 인터뷰 들어갔다가 나올 때 이거 다섯 개는 확인해야 한다, 가 있어야 한다는 것.

의사소통 능력? ok → 그러면 다음으로 넘어가는 식.

다만 코어 역량을 확인하기 위한 코어 질문은 질문 하나로 끝나지 않을 것. 이 때 여러 번의 branch 질문을 하면 된다.

그 질문이 그 역량을 확인하는 데 변별력이 있을까 테스트

변별력 테스트는 회사에 재직하는 사람과 해도 됨.
내가 해결하려는 문제를 잘 하는 사람에 대해, 저 사람은 뛰어나고, 저 사람은 평균적이다. 그래서 질문해보니 차이가 드러나는가.
더 값싸게 하는 방법은, 머릿속으로 멘탈 시뮬레이션. 내가 이 사람이라면 어떻게 답할까.

Work Sample Test

굉장히 좋은 방법이지만 시간이 많이 든다. 너무 쉬운 걸 주면 의미가 별로 없을 것이고.
워크 샘플 테스트를 인터뷰 자리에서 즉시 해보게 하는 건, 인터뷰 때 긴장하면 좋은 결과를 못 준다는 것. 실무랑 다르니까.
예전에 기획자 뽑을 때, 컨설팅 회사가 입찰 제안을 할 때 썼던 제안 요청서 문서가 있었음. 이걸로 워크샘플 테스트.
기획자가 들어와서, 정부 공고에 입찰되면 좋겠다고 생각했기 때문에. 당신이 지금 당장 이걸 훑어서 핵심 정보를 뽑아서 어떻게 10분만에 제안서를 구성하겠는가? 로 테스트하니 굉장히 도움되었다.

이런 건 화술 필요 없음.

이거 뒤에 인터뷰까지 들어가면 좋음. 이거 이렇게 구성하셨는데 과거 비슷한 경험?

Situational Judgement Test

이녀석의 예측력은 구조화된 질문, WST보다 떨어짐. 하지만 보완적으로 쓰기는 좋음.
써야 한다면 굉장히 디테일하게.
예를 들어, 윗사람이 당신에게 말도 안되는 일정으로 일을 시킨다면 어떻게 하겠냐.
대답하면, 실제로 말한대로 해보게 한다. 시뮬레이션하면서.

팀장을 설득한다면 어떻게 해보시겠어요? 적어보기.
거기에 할 수 있는 응답을 미리 만들어둔 다음, 오더링 해봐라 라고 할 수도 있고.
구체적 디테일이 없는 답변 나오고 땡 하면 안됨.

즉 미래 상황 질문은 액션 레벨로 들어가서, 무슨 키를 누르냐 무슨 파일을 열겠냐 이 정도로 가야 예측력이 높아짐.

몇 가지 아하가 있었던 QnA

Q. 질문자의 의도를 드러내는 경우가 좋을때도 있고, 그렇지 않은 경우가 좋은때도 있는거 같은데, 무엇이 더 좋을까요?

크게 상관없으나, 드러내는게 더 낫다고 생각. 구체적인 경험으로 답하게 만들면 거짓말을 하기 어렵게 된다. 그러니 의도를 드러내되 경험을 잘 이끌어내길.

Q. 우리가 원하는 수준의 사람들이 지원하는 수가 너무 적어요

(창준님 페북 포스트 참조) 머니볼 전략 써라.
결국 우리가 원하는 것 대비 회사가 가진 매력이 적다는 것. 또는, 너무 좁게 문제를 정의했을 수도 있다.

예를 들어 애자일 코치 경력 10년 써놨는데, 그런 사람이 손에 꼽을 수 있음.

Q. 상대방에게 정말로 어떤 정보가 없는 것인지 혹은 단지 상대방이 말을 안 하는/못 하는 것인지를 어떻게 잘 구분할 수 있을까요? 라포가 부족해서도 있겠지만..

그렇기 때문에, 썰을 푸는 것보다는 경험을 물어봐야 함. 과거 경험을 얘기하는 건 일반적으로 언어 능력과 비교적 큰 관계가 없음.
그리고 워크샘플이나 SJT를 하면 됨. 말로 안하고 직접 해보게.

Q. 개발자에게 코딩 테스트로 워크샘플 하는 거 괜찮을지? 압박 느낄텐데.

코딩 테스트는 간접적 질문이다. 알고리즘 물어보는데 그게 실무랑 다름.
실제로 할 일을 시켜보는 게 다이렉트 테스트. 신입 직원이 실제로 3개월 안에 수정해야 할 이슈 같은 게 있을텐데, 그런거 중에 3개월 있었으면 10분 안에 풀 수 있는 문제를 뽑아서 그 문제 풀어보라고 시킴. 우리 코드 하나도 모를테니 물어보면서 하게 하고.
긴장하는 부분은, '내가 이 사람을 시험한다'는 느낌이 적게 들게 해야 함. 학생 때 시험 때 긴장하는 느낌을 탈피하게 한다. 물어보세요, 도와드릴게요
또는, take-home 프로젝트도 좋음.

전문가 인터뷰 @January 13, 2022

일반적인 거 몇 개

인터뷰가 잘 됐는지 여부를 평가하기

‘흥미로운 정보를 많이 얻었다’ 가 아니다. 얻은 파인딩을 실행으로 옮겼더니 더 잘하게 됐다, 여야 한다.
'재밌는 거 많이 얻었다'에 좌우되지 말라. 교육 직후 만족도와 학습의 상관성이 없는 것과 유사하다.
배워보고 싶다, 같은 게 아니라, 배워서 어떻게 할 것인지까지 명확하게 목적을 설정해야 한다.
정보를 얻는 것조차도 모두 목적이 있다. 지식만 얻으려고 하면 지적허영에 그칠 수 있다. 물론 그것도 나쁘지 않고 삶을 즐길 수 있는 방법이기는 하지만, 목적지향적으로 했을때 학습을 많이 하더라.
내가 지식을 얻어서 활용적인 면에서 피드백 사이클이 전체를 꿰뚫게 되니까, 인터뷰가 잘 됐다는 피드백을 스스로 얻게 된 것이다.

전문가의 성과에 중요한 핵심이 뭔지 찾아내는 것이 중요하다.

“초보자들이 실수 많이 하는 것”, “내가 그때 이걸 잘못했으면 결과가 안 좋았을 것”

→ 둘 다 cue에 불과하다. 실수를 자주 해도 성과에 영향이 미미하면 다룰 필요가 없다.

어떤 요소가 중요한가 아닌가 알려면, 다른건 똑같고 그 요소만 다른 걸 찾아보면 된다. (쌍둥이 연구)
그다음은 트레이드오프. A는 이런데 B는 저런 것. 무엇이 더 나은가?
뭔가를 안했는데 잘 됐다고 느껴진 게 거의 없다면? 그러면 중요한 요소다.

전문성 및 전문가 인터뷰 관련 주요 참고자료

전문가 인터뷰의 전체 순서는 ACTA(Applied Cognitive Task Analysis)를 참고하라.

ACTA PDF
미해군 연구자료

Applied_cognitive_task_analysis.pdf358.0KB

Collaborative Development of Expertise PDF
Deliberate Performance

Deliberate_Performance_Accelerating_Expertise_in_N.pdf222.8KB

전문성 연구에 대한 책 두 권

전문성 가속화에 대한 책

https://www.amazon.com/gp/product/184872652X/

전문가 인터뷰에서 쓸 수 있는 테크닉

Task Diagram

초반에 하면 좋다. 함께 맵을 그리는 것. 클래스101에도 나왔던 거다.
예를 들어 미세먼지 전문가라고 하면, “창준님이 집에서 미세먼지 수준을 관리하기 위해 하는 행동들을 3-5개 정도 그려주시겠어요?” 라고 하는 것.

이건 행동의 종류가 될 수도 있고 순서가 될 수도 있다.

예를 들어 전자음악 만드는 순서가 뭐냐고 하면 모티브 → 리듬 → ... 이렇게 될 것.

다음, “네 개 중에서 창준님이 느끼기에 잘하는 사람과 못하는 사람의 차이가 큰게 뭐냐”고 묻는다.

여기서 ‘측정’이라고 하면 더 파고드는 것이다.

이렇게 전체 그림을 함께 그리는 게 엄청 도움이 된다. 근데 인터뷰 못하는 사람은 하나만 가지고 계속 얘기한다. 내가 캐지 못한 게 얼마나 있는지 알지도 못하고.
(질문하신거에서 재구성) 그런데 전문가가 이렇게 그린 맵이 틀릴 수도 있다. 그건 얘기하면서 수정해나가면 된다.

처음에는 자기 머릿속에서 그냥 나온 pet theory일 수 있다. 전문가들도 그런 걸 갖고 있다.
근데, 보시면 내가 그냥 썰을 풀게 한 게 아니다. 철학이 아니라 팩트에 가까워지게 질문한 것. “행동들을” 이라고 했다.

대기업 HR 팀장이면 자기 철학이 엄청 있을텐데, 그냥 질문하는 게 아니라, "사람 뽑을 때 하는 서로 다른 행동들이 있을텐데..." 이런 식으로 하면 pet theory로 안 가는 경향이 있다.

그럼에도 불구하고 현실과 안 맞을 수 있는데, 그래서 삼각측량 하면 된다. 첫 세션에서 말씀드렸던 거.

실제 사례 가지고 물어봐서, “어? 그러고보니 가동단계 아예 안하시네요. 가동단계를 했던 거 생각나세요?” 하면서 수정되는 거.
그리고 얘기 안했던 X가 자꾸 나오면, 이건 뭐에 해당하냐? 고 물어보면서 추가되기도 하고.

즉 처음의 다이어그램도 임시적인 정보를 얻은 거고, 점점 확신이 붙는 것이다.

Knowledge Audit

다음은 전문가의 전문성을 탐침할 수 있는 질문들의 집합을 뽑은 것이다. 이걸로 분야 상관 없이 전문가라면 대부분 갖고 있는 것, 전문성의 집약체를 뽑아낼 수 있다.

ACTA 논문이 출처라고 볼 수 있겠구나.
https://commoncog.com/an-easier-method-for-extracting-tacit-knowledge/
최신 버전은 여기에 있다. https://www.amazon.com/How-Professionals-Make-Decisions-Expertise-ebook/dp/B00SC7Y85Q/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=

오리지널 버전에서 탐침 몇 개는 단순히 CTA를 위해 배우기에는 과한 개념이라는 판단이 들어 삭제했고, 몇 개는 중복된 정보를 뽑아내길래 삭제했다.
이렇게 체계화하는 게 언제나 도움이 되진 않는다. 모든 탐침을 인터뷰 하나에서 다 쓰는 걸 권하지 않는다. 어떤 탐침은 해당 도메인에 관계가 없을 수도 있다. 그리고 탐침 이후의 follow-up 질문은 언제나 엄청나게 달라져야 한다.
탐침 내에 사용하는 단어 하나하나가 중요하다. “tricks of the trade”라는 단어는 탈법적으로 느껴지기도 하고, “Rules of thumb”은 너무 일반적인 얘기만 하게 만든다. 경험적 기술을 얘기하도록 만드려고 “Job smarts”를 선택했다. 마찬가지로 “noticing”은 단순한 인지적 스킬을 얘기하는 대신, 전문가가 초보자는 놓치기 쉬운 걸 알아차리는 것에 집중하게 해주었다.
그러나 CTA에 익숙해질수록 다른 단어로 뻗어나갈 수 있다. KA는 이정확한 단어들이 쓰이는 게 필수적인 연구에 쓰라고 만든 툴이 아니다. 그보다는 정보 수집을 위한 툴이고, 더 중요한 건 라포를 유지하고, 객관성보다는 호기심을 끌어내는 데 있다.

전문가가 아는 것들

인지 스킬(perceptual skills/noticing) → 낌새를 느끼기.

어떤 상황이 스프링 달린 것처럼 튀어나와 보이는 경험이 있었나? (매트릭스에서 레드 드레스 입은 사람이 확 눈에 들어오는 것처럼) 또는, 다른 사람은 몰랐는데 당신은 무언가가 벌어지고 있다는 걸 알아차린 적 있었나? 예시를 들어줄 수 있는가?
Have you had experiences where part of a situation just popped out at you; where you noticed things going on that others didn't catch? What is an example?

멘탈 모델/큰 그림

이 작업의 큰 그림에서 무엇이 중요한지 예시를 들어줄 수 있나? 알아야만 하고, 계속 추적해야 하는 주요한 요소는 무엇인가?
Can you give me an example of what is important about the Big Picture for this task? What are the major elements you have to know and keep track of?

sense of typicality and associations - 어떤 게 전형이고 비전형인지 감이 있는지, 그 사이의 연결을 보는가. → 카테고라이징하기.
routines/job smarts - 반복 작업을 수월하게 하려고 쓰는 자신만의 요령이나, 자신만의 도구가 있는가.

“When you do this task, are there ways of working smart or accomplishing more with less — that you have found especially useful?”

(선언적 지식) 책을 보고 논문을 봐야지만 알 수 있는 지식들. 시험에 자주 나오는 것들. 근데 이 중에도 중요한 게 있을 수 있다.

전문가가 할 수 있는 것들

머릿속에서 과거나 미래에 대한 시뮬레이션을 돌리기(진단, 설명, 기대 형성 등을 위해).

프로그래머가 디버깅할 때 멘탈 시뮬레이션하는 것도 포함.
“Is there a time when you walked into the middle of a situation and knew exactly how things got there and where they were headed?”

이상 징후 발견 및 문제/이상 탐지(spot anomalies and detect problems/anomalies)

”Can you describe an instance when you spotted a deviation from the norm, or knew something was amiss?”

가진 지식을 도구로 활용할 기회를 찾거나, 즉흥적으로 행동하거나, 대안을 찾아서 수행하거나(find leverage points/opportunities/improvising, perform workarounds)

”Can you think of an example when you have improvised in this task or noticed an opportunity to do something better?”

불확실성을 관리(manage uncertainty)
계획하고, 계획을 수정(plan, replan)
복잡한 상황을 평가(assess complex situations)
집중을 관리(manage attention)
본인의 강점과 한계를 고려하고 셀프 모니터링(take their strengths and limitations into account/self-monitoring)

“Can you think of a time when you realised that you would need to change the way you were performing in order to get the job done?”

이런 항목들을 보고 질문을 만들면 된다. 물론 분야마다 뭐가 중요한지 조금 다를 수 있는데, 내가 인터뷰할 분야의 전문가 세 명쯤 만나서 인터뷰해보면 각이 나온다.

Critical Incident Method

쉽게 말하면 타임라인 그리기. 이걸 하면 썰을 푸는 쪽으로 더 갈 수도 있어서 조심할 것. 예시를 들어달라고 한다. 위에서 했던 것들(Task diagram, Knowledge audit)을 상호 검증하는 데 CIM 쓸 수도 있다.

단계를 나열한 뒤에, 골라서 CIM 들어가고.

예를 들어 디버깅을 하는 타임라인을 그린다고 해보면, 시작은 ‘버그에 대해 들었다’, 끝은 ‘버그 픽스 후, 테스트하고, 커밋했다’

여기서 의도적으로 시작 전과 끝 뒤에 공간을 둔다. 시작이 시작이 아니고 끝이 끝이 아니다. 이게 상징이다.
그다음 이런 식으로 구간을 3-5개로 나누게 한다. 그러면 분명히 구간에서 구간으로 넘어갈 때 중요한 일이 있다.

중요한 일 = 의사결정(decision making) 또는 상황판단(situational awareness)
어 이거 뭔가 잘못됐는데? 같은 게 상황판단이다. 이 때 누가 무슨 말을 했다, 같은 것도 포함되고.
인지적 분석을 하는 것. 이 때 열심히 삼각측량하면 된다.

전문가가 전문성을 획득한 과정(커리어 그래프)도 똑같이 해볼 수 있다. 기타치는 실력에 대한 커리어 그래프를 그린다고 해보자. 시간에 따른 실력 그래프.

19살에 시작했고, 대학 가고, 군대 가고, 취미활동 하고..
여기서 중요한 사건이나 의사결정이 있었나 물어본다. “제가 Bpm 을 못맞추더라고요 충격적인 사건이 있었죠”
어떤 사건을 통해 이 사람의 실력이 빠르게 올라갔는가를 탐색하는 것.

Critical Decision Method 할 때 쓰기 좋은 질문들

Cues : What were you seeing, hearing, smelling ...?
Knowledge, Source : What information did you use in making this decision, and how was it obtained?
Analogues : Were you reminded of any previous experience?
Goals : What were your specific goals at this time?
Options : What other courses of action were considered by or available to you?
Basis : How was this option selected/other options rejected? What rule was being followed?
Experience : What specific training or experience was necessary or helpful in making this decision?
Aiding : If the decision was not the best, what training, knowledge, or information could have helped?
Tools : When making this decision, were there any tools that helped that specific decision?
Time Pressure : How much time pressure was involved in making this decision?
Situation Assessment : Imagine that you were asked to describe the situation to someone superior to(in terms of expertise, for example) you at this point, how would you summarize the situation?
Hypothesis : If a key feature of the situation had been different, what difference would it have made in your decision?

아하가 있었던 QA

Q. 채점표(루브릭)을 이용해 전문가를 평가하는 방법?

루브릭을 제공하는 장단점이 있음.
장점은 채점자들간에 일관성이 높아짐.

그러려면 루브릭에도 기준이 있어야 함. 이 사람이 이런 행동을 하면 때에는 5점 주고.. 등.
이런 게 없으면, 그냥 사람이 첫인상이 좋아 보이면 다 좋게 평가하고 이런 후광효과에 빠지게 된다.
안좋은 루브릭의 예는 “회사에서 성과평가에서 기대성과 넘었다” 같은 걸 별 설명 없이 5점 스케일로 평가하라고 하는 거.

단점은 융통성이 떨어질 수 있다. 예를 들어 분명 탁월한 사람으로 느껴지는데, 점수는 안좋게 나오는 경우가 있을 수 있다.
장점은 가져가면서 단점은 줄이는 방법을 예를 들어 알려드리겠다.

아이의 피아노 선생님을 찾는데, 나는 학생과의 상호성을 중요하게 봤다.

이유는, 우선 강의식으로 하면 아들이 쉽게 잠들어서. 그리고 교육적 연구 결과를 참고했다.

과거에 내가 만났던 상호성이 높았던 피아노 선생님을 떠올려봤다. 내가 아 이사람 대단하다 싶었던, 감탄했던 그 시점의 기억을 꺼냈다. 그때 내가 어떤 포인트들을 관찰했는가.
아이에게 선택권을 준다

아이들을 위한 피아노책에서 태현이는 어떤 책이 좋아?
아니었던 사람은 → 자 이거 부터 쳐보자.

아이의 상태를 묻는다.

선생님이 이거 했는데 태현이 기분이 어때? 하고 물어봄. - 어려워서 기분이 별로에요 - 같이 이야기할 수 있는 기회를 줌.

이런 식으로 다섯 가지 정도 행동기준을 만들고, 이걸로 채점표를 O, △, X 로 만든다.
그리고 선생님의 시범수업을 보면서 해당 행동이 나오면 O 준다. 나왔는지 안나왔는지 애매하면 세모 주는 식.
그리고, 종합적으로 5점 스케일로 평가한다. 5(탁월)~3점(평균)~1점(별로)
이렇게 하면, 대개 동그라미가 하나도 안나왔는데 5점을 주는 사람은 없더라. (있으면 내 기준이 부족한 것)

전체적 점수를 줄 때 앞의 기준에 프레이밍이 될 수밖에 없다.
어쨌든 앞의 기준들이 메이저하긴 하지만, 딱딱하게 적용되지는 않는다.

이런 기준이 있으면, 이제 채점자들끼리 근거를 가지고 논의할 수 있음. 이 점수는 왜 그런가?

더 자세히 알고 싶으면 다음 키워드를 더 찾아보시길.

Q. 내가 설계한 구조대로 인터뷰가 진행되고 있지 않아서 끊고 싶은데, 라뽀가 떨어질까봐 못하는 상황에서 어떻게 할까?

일단, 끊는 게 좋다 나쁘다는 별로 없다. 안 끊고 쭉 듣는 것도 한가지 방법이다. 자기 삶의 방향에 따라 다르다.
끊고 싶다고 할 때, 상대를 덜 기분나쁘게, 자연스럽게 끊는 방법은 있다.
상대의 호흡을 따라가면서 상대가 쉴때 치고 들어가는 거다. 한 문장이 끝났다는 느낌이 들었을 때 비집고 들어간다.
그걸 처음부터 끊지 말고 처음에는 호응해주는 방식으로. 아~~ 이런식으로 호응하다가. 재밌네요 이런말을 하면서 내가 끼어드는 빈도를 조금씩 늘림.
그러다가, “아 그러면~” 하고 치고들어가서 바톤을 가져오는 거다.
“이게 그렇게 하면 이렇게 되는 거겠네요” 하면서, 이 사람이 했던 말을 정리할 수도 있고. 내가 요약한 다음, “그런 의미에서...” 하고 내가 원하는 방향으로 이야기하기.
“그런데” 가 아니다. 내가 요약해주고, “그런 의미에서” 하면서 다음 주제가 연결되는 느낌을 주는 것이다.
그리고 이걸 하면서 신뢰를 더 구축할 수도 있다. 솔직하게 털어놓기. “당신이랑 몇번 해보니까 이런 패턴이 있더라. 그런데 나는 이런 걸 원한다.” 하면 상대도 솔직해지면서 신뢰가 깊어질 수 있다.

Q. 클래스101 수업에서 질문 자꾸 하는 것보다 대화로 끌고가는 게 좋지 않냐고 하셨는데, 어떨 때는 오히려 질문이 좋지 않을까 하는 생각이 들었다.

예스 노 다 된다.
많은 사람들이 반영하라고 하면 초점 없이 흐리게 반영한다.
예를 들어 환자와 의사.

환자가 술을 끊어야 하고 의사와 주 1회 보면서 치료하는데. 이번주에 만남
환자 첫마디가, “선생님 저 무너졌습니다” 하는거지.
근데 의사가 이 환자가 무너졌다는 게 뭘 했다는건지 궁금한데, 질문을 안하고 반영해서 그걸 말하게 하고 싶다.
어떻게 반영할까.

질문자: “아이고 무너지셨구나.”

그게 흐리멍텅한 반영이다. 내 의도는 저 사람이 구체적으로 뭘 했는지 알고 싶은 건데.
반영으로 하기 어려우니, 그냥 “어제 뭐 먹었는데요?” 이렇게 질문하게 된다.
이게 한번은 괜찮은데, 자꾸 질문하면 안 좋다.
그래서 나라면 이렇게 한다. “아 어제 저녁에 뭔가(something) 마셨나보네요, 선생님이.”
그러면 환자가: 네 꼬냑 세잔 먹었습니다. ㅠㅠ 이러면서 설명하게 된다.
아유 속상하시겠네, 하면 환자는 정보 보다는 마음을 얘기하게 된다.

그래서 결론. 질문을 하지 말라는 건 아니다. 질문해도 된다. 너무 질문만 하지 않으면 ok다.

질문을 적게 하려는 이유는 두 가지. 하나는 관계를 망칠 수 있어서. 그리고 상대가 기억을 떠올리는 데 방해가 될 수 있어서.

그런데 반영이 안 맞을 것 같아서 질문한다, 고 할 때 대부분 흐리멍텅한 반영이라서 그런 거라고 생각해야 한다.
반영하면서 상대방이 생각할 수 있는 시간을 주면 된다.

Q. 전문가처럼 훈련하기 위한 행동과 전문가의 행동은 다르다는 이야기가 있었는데요. 전문가 인터뷰하는 테크닉을 보니 이렇게 훈련하면 전문성이 길러지겠다 싶은데 어떻게 생각하세요?

destination 은 아는데 path 를 모르는 상태다.
다른 개발자를 봤을 때 프로그래밍 전문성이 있는지 판단할 수 있는 기준이 생긴 것. 내가 그런 수준이 되고 싶다, 하면 path 는 모른다.
그러면 어떻게 만들어가는게 좋은가? 이것도 인터뷰해볼 수 있다. 자신만의 생산성 향상 도구를 만드는 과정을 들을 수도 있고.
하지만 대부분 destination을 모르는 게 문제고, 보통 이걸 들으면 감이 오긴 한다.
path 찾는 건 Critical Incident Method 보시면 더 힌트가 될 것이다.

Q. 각 잡고 전문가 만나서 판이 깔려있으면 같이 기법 써서 할 수 있을 것 같은데, 그냥 지인이고 캐주얼하게 만났는데 종이 꺼내서 그려주고 하는 게.. 되면 좋겠는데 그런 상황을 어떻게 만들지? 가 떠오르지 않는다.

상황에 맞게 해야죠.
예를 들면 지인이랑 만났어요 만났는데 전문성을 가지고 있는 걸 알게 되었고, 그 자리에서 약속을 받는 거죠. 내가 저녁살테니까 인터뷰 한번 해보고 싶다. 이것도 방법이고
그렇게 시간 만들기는 좀 그렇다하면 대화중에 이런 것들을 응용해서 써먹어야하는거죠.
전문성을 예로 들면, 좀 다르지만 제가 다른 사람의 전문성을 잘 활용하게 도와줬던 경험이 있어요.

엘지 에어컨 A/S 기사를 불렀음. 에어컨 틀어놓으니 30분도 안되어서 마루바닥에 물이 흥건해지는거에요. 막 썩는 모양으로 물자국 남고.
기사가 와서는 호스 높이가 너무 낮았다 하고 해결을 하고 갔는데, 그 이후에 틀었더니 또 물이 흥건해지는거죠. 그래서 컴플레인해서 다른 기사가 왔습니다.
다른 기사가 와서는 왜 이게 새는지 모르겠다는 거에요. 이상하네 이상하네.
호스 문제가 아닌데도 물이 새는 경우는 어떤 경우일까요? 하고 물어보니까 생각하더군요.
이 사람의 예외적인 경험을 찾게 해준 거죠. 태스크 다이어그램을 써본 것도 아닌데.
배수관이 하수관이랑 연결이 되어야하는데 그거가 문제가 있을 수도 있다는 거에요.
→ 그게 어디있는데요? → 집마다 다릅니다. -> 기사님 보통 아파트들은 어디에 있나요?
그러니까 기사님이 두리번 거리기 시작했고, 하수구가 연결되는 지점을 찾음.
연결지점에서 화분 돌멩이들이 막아서 문제가 발생했음.
전문가가 더 전문성을 잘 발휘하게 도와준 것임.

Q. 첫 질문이나 아이스브레이킹 잘 하는 방법?

반갑습니다. 자기소개 부탁드릴게요. → 이건 이 사람을 딱딱하게 만들고 싶을 때 하는 질문입니다.

이 사람이 파워가 너무 높아. 사장님인데, 파워가 높을 때. 일부러 사장님이라고도 안하고, 누구누구씨 자기소개 해주실까요? 하면서 파워를 낮추기. 사람을 긴장시키고 싶을 때 쓸 수 있고.

다른 방법은 현재 상태에서 힌트를 얻는 거예요.

최근에 했던 사례를 들자면, 미국에서 채광좋은 곳에서 인터뷰를 했는데, 풍광이 정말 좋네요. 기분이 좀 어떠세요 로 시작. 그 사람과 연관이 있는 것으로.

(Q. 일반적인 질문보다는 그 사람에게 연관된 질문을 미리 준비해서 가면 좋을까요?)
준비보다는 그 상황에서 만들어내는 훈련을 많이 해봐야할 거 같아요.
예를 들어 시간이 오후 여섯시반이라면 식사도 못하고 배고프시겠다, 이런 식. 이사람 상태와 연관있는 거에서 시작하면 좋아요.
아니면 이 사람이 증권 애널리스트고 점심시간에 인터뷰를 한다면, ‘증권하시는 분들은 장 중에 밥도 제대로 못드신다던데..’ 이런 식으로 얘기하면
상대 : 예에 제가 위장약을 항상 달고 삽니다
→ 아이고, 이렇게 대화를 풀다가, 여기서 인터뷰로 넘어간다.
이 때 아주 자연스럽게 가는게 중요해요. 인터뷰 모드가 아니라.
“그래서 말인데, ... 가 하시고 있는 일과 어떻게 연관이 되는지 궁금해요” 같은 식.
이게 좀 어색해도, “그런 맥락에서” 이런 말만 붙여도 알아서 excuse를 만들어내고, 연결이 된다는 느낌을 받게 된다.

Q. 무언가가 잘 됐는지 안 됐는지 판단하는 본인만의 방법이 있는지 물어보는 게 좋은가?

→ 핵심이다.
근데 pet theory일까봐 두렵다.
→ 너무 자세히 안 들으면 된다. 왜 그런가? 까지 들으면 썰이 나오기 시작한다. 그러지 말고 최근에 봤던 사례 보여달라, 같은 식으로 삼각측량.
→ CTA는 인터뷰하는 사람이 theory를 만들어야 한다.

UX 인터뷰 @January 20, 2022

UX 인터뷰에서 흔히 빠지는 함정

질문 많이 하기

사람들을 표면에서 답하게 만든다. 질문을 하면 깊이있는 생각을 못하게 됨.
사람들한테 999에서 7씩 빼는거를 시켜요. 그러면서 색깔이랑 straw effect 다른 작업 시키면 인지부하가 커져서 막 틀려요. 그러면 사람들은 지름길을 선택해요. 그냥 쉽게 떠오르는거 얘기해버려서 통찰이 별로 없어.
대안은, 질문 하나 했으면 다음번은 질문 말고 다른거 하도록 노력하면 돼요. 질문 하고 답변 들으면 바로 다음 질문 넘어가고 이러면, 예외(상대가 압박해도 할말 다하는 사람) 빼고는 정말 물은 것만 대답합니다.
예를 들어 “수임료 받는거 알고 계셨나요? →몰랐습니다.” 하면 이사람이 했던 말을 내가 소화했다는 시그널을 주는게 좋아요. “아 그래서 부담이 많이 되셨겠어요” 식으로 말하면 좋죠. 그러면 “사실은요” 하면서 말이 더 나올 수 있죠.

이러면 어떨 것 같으세요? (X원이면 사시겠어요?)

이런 것들도 흔히 빠지는 함정이에요. “로그인 화면을 이렇게 바꾸면 사시겠어요?” 이런 것들이 정말 함정이죠. 왜냐하면 그 답을 믿을 가치가 별로 없어요. 행동하고 일치하지 않기 때문에.
그런데도 불구하고 우리는 그 답에 호도될 확률이 굉장히 높아요. 과거에 이렇게 했는가를 물어보는게 더 좋아요. “만원에 쓰실 거에요?” 묻지 말고, “유료로 구독했던 서비스가 얼마짜린가요” 를 묻는게 좋아요.
UX인터뷰에 특히 중요한건 뭐냐면, 해석을 우리가 해야 돼요. 인터뷰이가 이게 좋은지 나쁜지 그사람꺼를 우리가 사용하면 안 되고, 결과적으로 해석은 우리가 해야 돼요.

(CTA에서도 인터뷰이의 theory를 그대로 믿지 말고 인터뷰어가 theory를 만들라고 하셨음)

“이사람이 이걸 좋아하겠구나/아니구나” 를 우리가 해야 하지 그사람이 하면 안돼요. 인터뷰 했는데 “싫다던데요” 이러면서 믿으면 안돼요. 우리가 추정해야 해요. 만들어내거나, 자기가 생각하기에 그럴싸한거를 많이 하거든요. 그거를 final answer라고 생각하시면 안 되는 거죠.
따라서 인터뷰를 깊이 있게 들어가야 해요. 그러면 어떤 일이 벌어지냐면, 우리가 가추법 (abduction)을 하는 거거든요. 셜록 홈즈가 쓰는, “당신은 신발 밑창에 진흙이 많이 묻어있고 아마 남부지방에서 온 군인일 것이다” 이런건데요.
어떤 suprise를 봤을 때 이유를 설명하는게 가추법이에요. 만약 인터뷰를 depth있게 해놨으면 우리가 전문가라면 가추법으로 얘기하는게 일치해요. “이사람 분명히 무남독녀야” 같은 소리 안하고 큰 문제가 안 됩니다.

왜 X를 하셨어요?(Yes/No 질문)

이것도 closed question이라서 안좋아요. 강압적인 이분법적인 말을 하게 돼요. 정보를 많이 말 안해주게 돼요.

둘 중에 어느 게 더 좋으세요?

이것도 안 좋아요. 실제로 서비스에 그게 있을 때 어떤 행동을 할지는 모르는 거예요. 더 좋다고 한거를 더 많이 쓸지 적게 쓸지 몰라요.

뭘 개선하면 좋을까요?

되게 조심해야 하고 우리가 거기에 꽂혀서 호도될 확률이 되게 높아요.

일반적으로 어떻게 하세요?

이렇게 물으면 이사람이 자기 기억에서 얘기를 하지 않고 그냥 자기의 해석에서 얘기를 해요.
예를 들면 메모하는 습관에 대해서 메모하는 서비스 UX리서치를 했는데, one-sided mirror에 들어가서 했는데 와서 막 얘기하다가 “메모 얼마나 하세요” “안합니다” “아 그러시구나, 수고하셨습니다”.
근데 그때 제가 “어 흥미롭네요. 제가 궁금해지네요. 퇴근하고 6시라고 치고, 오늘 하루를 재구성해보고 싶네요. 종이를 꺼내서, 오늘 아침에 출근 하셨겠죠. 사무실 들어오실때… 사무실이 어떤 문이죠? 어느 손으로 미는 거 같으세요?”
그러면 눈이 위를 보면서 “어 기억이 떠오르세요?” “걸어갑니다” “어 앉아보세요. “
시제를 현재로 바꿨죠. “가방은 어디 놓죠? 본인은 뭘 하고 있나요?”
“제가 책상 밑에 박스에서 이면지를 하나 올립니다. 제가 테이프로 붙입니다” 해서 봤더니 매일 아침마다 이면지를 하나 붙여요. 거기다가 모든 메모를 다 하는거야.
“어 메모 많이 하시네요. 어 그러네요.” 이러는거야. 첨에는 분명히 메모를 안 한다고 그랬는데, 보니까 하루종일 메모하는 사람인데 인터뷰할 때는 그걸 메모로 인지하고 있지 않았던 거죠. 물속에 사는 물고기 같은거지.

창준님 블로그 글

내가 어떤 프로젝트를 진행해서 산출물이 나왔다. 거기에 대해 동료들로부터 피드백을 받고 싶다. 나는 통상 어떤 질문을 하는가?

1) UI 관련해 새로운 아이디어들 있으세요?

2) UI 플로우면에서 어떤 것 같나요?

3) IT기술을 잘모르는 사람이 실수를 적게 하려면 현재 UI를 어떻게 바꿔야 할까요?

4) UI 설계하는 방법들로 어떤 것을 알고 계세요?

1번은 새 아이디어를 브레인스토밍을 하게 하는 것이고, 2번은 평가/비판을 하게 하는 것, 3번은 이미 있는 걸 개선하게 하는 것, 4번은 일반적 정보/의견을 공유하도록 하는 것이다.

이런 피드백을 구하는 질문들의 효과에 대해 진행한 연구가 있다.

Cook, A., Hammer, J., Elsayed-Ali, S., & Dow, S. (2019, May). How Guiding Questions Facilitate Feedback Exchange in Project-Based Learning. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (pp. 1-12).

게임 설계 수업에서 실험을 했는데, 대학원생들이 가장 적게 물었던 질문은 위에서 3번 개선 질문이었다. 하지만 이 질문에 대한 동료 피드백을 받은 후, 이들이(강사 포함) 가장 도움이 되었다고 느낀 질문은 3번 개선 질문이었다. 왜 그랬을까? 개선 질문은 피드백을 주는 사람 입장에서 답을 생각해내기가 쉽고(따라서 피드백의 양이 제일 많았음), 받는 사람 입장에서는 행동화하기 쉬워서 좋다. 근데, 이렇게 가장 도움되는 질문을 가장 적게 한다.

전에도 썼지만 코칭을 더 효과적으로 받는 사람들이 있다. 이 사람들은 코칭을 이렇게 받는다. 나는 뭐뭐를 하고 있는데 이게 잘 안된다. 나는 이렇게 하고 싶다. 뭘 바꾸면 좋을까?

그래서 나는 코칭을 할 때에 되도록 피코치가 나에게 이런 요구를 하도록 격려한다. 즉 이들이 "저는 이거를 하고 싶어서 어제 이렇게 했는데 뭘 바꿔야 할까요?"라는 질문을 나에게 하는 순간 코칭이 제 트랙 위에 있다고 느끼게 된다.

—

근데 나는 이 연구가 놓치고 있는 게 있다고 본다. 3번이 효과적인 이유가 뭘까. 나는 5번이 있었다면 어땠을까 싶다.

5) IT기술을 잘모르는 사람이 XX 같은 실수를 자주 하더라구요. 그래서 고민이에요. 그런 사람들도 게임 플레이가 스무드하게 해줄 수 있으면 좋겠어요. 하다가 관두지 않게요. 어떤 방법이 생각이 나세요?

즉, 내 생각에 3번이 효과적이었던 이유는 pain point와 그걸 느낀 snapshot, 그리고 원하는 방향의 ideal state가 희미하게라도 드러난다는 거라고 봤다. 5번에서는 그걸 더 명료하게 드러나게 했고, 단, 구체적 솔루션을 좁히지는 않았다. 즉, UI를 바꾸는 거만으로 제한하지 않았다는 거다.

pain point와 그걸 느낀 snapshot을 주게 되면 전문가는 자기 안의 전문성을 더 동원하게 된다. 근데 그게 감춰지면 전문가는 진짜배기 전문성을 잘 안쓴다. 이걸 잘 이해하면 chatgpt도 더 잘 쓸 수 있다.

CUD (Connect Understand Discover)

connect: 신뢰 쌓기. 상대와 내가 연결되야 함. 심적으로 편안하게 느끼게 해주고 공감.
unserstand: 이해하기
discover: 뭔가 생각 못했던 발견이 있어야 함

MI: 동기면담(Motivational Interviewing) TOM: Theory of Mind CI: Cognitive Interview CL: Clean Language

MI의 핵심은 반영. 반영 잘 하면 연결이 빠르다.
TOM의 핵심은 상대가 무슨 생각하고 있는지 추측. 하다보면 수렴하게 됨.

유저가 어떤 기능을 안 쓴다고 했을 때, “불편하셨겠어요” 면 반영이고, “만든 사람들이 신경을 못 써서 화가 나셨겠어요”이러면 추측.

CI의 핵심은 아래 따로 정리해둠
CL의 핵심은 메타포. 잘 쓰면 이 사람의 무의식을 보게 된다.

우리가 쓰는 말에서 굉장히 많은 부분이 메타포다.
유저가 “서비스가 너무 뜨거워요” 이렇게 말하면 “그러면 차가운 건 어떤 건가요” 이렇게 의미를 끄집어낸다.

UX 인터뷰의 목표

대개 UX 인터뷰 목적은 아래 4개를 알아내는 것으로 잡으면 좋다.

사람들이 어떤 job to be done을 (JTBD) 원하는가

그 제품이나 서비스를 쓰면서 뭘 해결하고 싶은지 찾기.
지하철에서 신문을 보는 거는 지하철의 지루함을 해결하고 싶은거죠. 그러면 그 제품의 카테고리를 벗어나는 생각을 할 수 있어요.

사람들이 어떤 프로세스를 거치는가
사람들이 어떤 어려움을 겪는가
그 어려움을 극복하기 위해 어떤 꼼수(임시해결책)를 쓰고 있는가

카페에 자기 윗도리를 걸쳐놓는데 그거는 자기 소유를 보여주는 JTBD죠. 이런게 임시 해결책이거든
작업할 때 입으로 나사 물고있고 그런거. 주머니에 넣어도 되는데 입에 물고 하는거. 이런 것들이 굉장히 좋은 정보가 되거든요. 서비스의 개선에 대해서.
창준님 블로그 - 소프트웨어 제작자를 위한 관찰 훈련

https://www.ideo.com/post/thoughtless-acts

UX 인터뷰의 타겟

목적을 잡았으면 타겟을 잡는다. 예를 들어 우리 앱에서 전화를 걸 때 초성 검색을 잘 안 쓴다는 걸 알게 됐다. 이 이유를 알고 싶다. 그러면 누구로 타겟을 잡아야 할까?

흔히 ‘안쓰는 사람’이나 ‘쓰는 사람’ 둘 중 하나만 보려고 하는데, 실은 둘 다 해야 한다.

쓰는 사람들은 어떨 때 쓰는가. JTBD는 뭔가. 이사람들이 초성검색을 알게 된 맥락은 뭔가.
안 쓰는 사람들에게는 쓰는 사람들의 JTBD를 가져와서 묻는다. 그걸 해결하기 위해 어떻게 하는가.

사람 선택은 우선 게릴라 전략.

필요한 사람들의 특성을 쓴다. 컴퓨터 전문가, 아토피 환자 등.
내가 아는 사람들 중 이와 관련된 사람들을 그룹화한다. 그리고 그 안에서 연락해서 약속 잡는다.
이렇게 한번 하고 나면 정보가 확 늘어나니까 그 다음 다시 타겟 잡는다.

창준님이 제안한 인터뷰 스킬 훈련법

프로젝트 배경 설정 (고객, 혹은 컨택 인물과 질답)
각 팀별로 인터뷰 계획 짜기 (대상 프로파일 뽑기 포함)
인터뷰 실시 (이 때 다른 사람들은 인터뷰어 혹은 인터뷰이 중 한 사람을 전사transcribe)
전사한 내용 중 인터뷰이의 답변을 보고 각 항목에 대해 개인별로 점수를 줌. (-1: 시간 낭비했다, 0: 별 거 없다, 1: 애매하다, 2: 정보가치가 있다, 3: 핵심적 인사이트가 있다)
같은 팀 내에서 인터뷰이의 답변별로 점수 평균냄.
점수가 가장 높은 답변들 몇 개에 대해서, 그 답변을 유도한 인터뷰어의 말(꼭 질문이 아닐 수도 있음)을 찾음.
팀별로 뽑은 그런 효과적 인터뷰어의 말들을 모아 보고 여기에 뽑히지 않은 것들과의 차이점을 대조하고, 효과적인 말들의 유사성을 추출.
여기에서 얻은 교훈을 토대로 다음번 인터뷰 훈련 때에 새롭게 어떻게 해볼 건지 이야기 나눔

이거를 버디랑 같이 매주 훈련하면 엄청나게 실력이 느는 걸 느낄 수 있을 겁니다. 3번하고 전사하기까지는 모이기 전에 따로 해오면 시간을 줄일 수 있겠죠.

전문가 인터뷰 연습 후기, 느낀 점

홍영기님의 OKR 피드백 전문성 인터뷰 (@January 14, 2022 )

제가 지금까지는 선형적인 (소위 말하는 스크립트 기반의) 인터뷰만 해왔는데 그건 정리하기가 엄청 쉬웠거든요.
근데 인터뷰 패치에서 배운 걸 써먹어보니 다면적, 다층적, 입체적인 느낌이 드는 인터뷰를 해서, 영기님의 뇌속을 여기저기 넓게 파고든 느낌은 드는데 이걸 다시 선형적인 글로 정리하려니 구조화가 잘 안 되고 어렵네요.
분명 인터뷰 안에서 얻은 통찰의 양과 질은 더 많았던 것 같은데 이걸 제 걸로 흡수하는 건 역시 다른 문제다, 라는 느낌이 들었습니다.
구글 잼보드로 펼쳐져있는걸 다시 글로 정리해서 합치려니 부자연스러움이 느껴지더군요. → 다른 글로 정리해봄

오은석님의 디파이 투자 전문성 인터뷰 (@January 15, 2022 )

의도적인 훈련이 정말 많이 필요하겠다고 느꼈어요. 배웠던 테크닉을 충실히 따라감으로써 얻는 게 분명 있는데, 다짜고짜 테크닉을 그대로 쓰는 건 당연히 말이 안되고 내 안에 녹여서 컨텍스트 안에서 그 테크닉이 나오게 해야겠는데 잘 안되더라고요. 예상대로 흘러가는 게 거의 없었습니다.
안전한 공간에서 좀 더 연습을 해보고, 실제로 야생으로도 나가보고 해야겠다는 생각.

KCD 프론트엔드 팀원들의 개발 역량 그래프 CIM으로 그려보기 (@January 18, 2022)

일단 miro 보드라는 툴은, 구글 잼보드와 비교했을 때 이렇게 같이 그림 그리는 데는 훨씬 좋다고 느꼈어요. 공간 무제한이고, 인터페이스 직관적이고.
짧고 가볍게 한 것이기도 해서, 각자가 개발 역량을 뭐라고 정의하는지는 언급하지 않고 시작했는데요. 본인이 역량이 크게 향상됐다고 느끼는 포인트에 대해 들으면서 그 사람의 관점이나 동기가 많이 드러나더군요. 자연스럽게 이직 얘기도 나오니 회사에서 뭘 중요하게 생각하는지도 튀어나오고, 공부 어떻게 했는지도 나오고. 서로에 대해 더 깊이 이해하는 시간이 되었습니다. 이건 아주 만족스러웠습니다.
경력 시작점과 그래프 시작점 사이에 공간을 두고, 개발을 본격적으로 시작하기 전에 어떤 일이 있었는지 물어보니 동기에 대해 더 알 수 있었던 게 흥미로웠고요. 반면 현재 이후의 그래프를 그려보게 하니 다들 어려워했습니다. 질문 구성을 잘 해야겠다고 느꼈어요(지금부터는 어떤 식으로 역량을 향상시키려고 하는가, 로 물어볼 걸 그랬나)
그리고 끝점을 잡은 뒤에 3-5개 구간으로 나눠달라고 했는데 쉽게 나누는 사람이 없었고, 커리어 시작부터 시간 순으로 회상해나가면서 그리는 건 잘 하더라고요. 또 실력을 기준으로 그린 것을 보고 이 때 무슨 일이 있었는지 내가 물어본 게 아니라, 본인이 당시 어떤 사건과 감정이 있었는지를 설명하면서 그림을 그리게 되던데.. 기억을 떠올리는 데에는 효과적이었을듯한데, 이러니까 썰 풀듯이 얘기가 많이 나오게 돼서 진짜로 “크리티컬”한 순간을 발견하게 하려면 좀 다르게 접근해야 했을까 하는 생각도 들었어요.

@May 7, 2023 Cognitive Interviewing

https://en.wikipedia.org/wiki/Cognitive_interview

Retrieval rules

Mental Reinstatement of Environmental and Personal Contexts

기억하려고 하는 그 사건에만 초점을 맞추지 말라.
예를 들어 음악을 기억해내려면

몇시쯤이었고
어디에 있었고
날씨는 어땠고
온도는 어땠고
등등 등등..

이렇게 그때의 환경을 조성해준다. 그러면 기억의 양과 정확도가 올라간다.

In-depth Reporting

기억나는 거 다, 뭐든지 얘기하게 하기. 상관없어 보여도.
차 안의 재질은 뭐였죠?

Describing the TBR Event in Several Orders

꼭 시간순으로 하지 않는다.
그 직전엔 뭘 하고 있었죠? 그 음악에서 기억나는 부분이 어떤 부분이죠? 그 직전에는 뭐가 기억나세요?

Reporting the TBR Event from Different Perspectives
Supplementary Techniques

CI를 할 때 초보자들이 자주 하는 중요한 실수?

안 한다.
인터뷰어가 생각한게 있고, 거기에 유도시키는 것. (보시긴 보신거죠? 본거 맞죠?) → 기억이 왜곡된다.

진짜 같다, 아니다를 감지하는 게 중요한 전문성이다.

기억 회상 모드에 빠지면 본인이 잘 보여야 한다는 사실을 까먹게 된다. 기억 회상이 인지적 자원을 다 쓰기 때문에 거짓말을 하기 어렵다.

그런데 질문에 뭘 심어버리면, 본인이 기억을 왜곡한다는 사실(거짓말한다)을 모른 채 해버릴 수 있다.

@May 17, 2023 ‘면접 모드’를 벗어나게 만드는 방법

연습문제
과거 유사상황을 회상하게 한 후
즉흥연기 가능한 NPC를 사용
특히 이들이 reactive하지 않고 proactive하게
전혀 다른 룰의 게임이라고 설명(예컨대 이 사람이 익숙한 TV쇼 언급)
명시적으로 기대하는 것 설명
좌석 배치
인포멀
SJT, WST 후 과거 유사경험 CDM하며 비교
2개 문제 이상하고 1문제 끝나면 피드백후 2회차에 개선 정도 평가
앵커링을 통한 암시 (subliminal)
시간에 따른 상황전개 (predesigned scenario)

[AC2 Patch] Interview