이력서에 적힌 경력 사항과 자기소개 글만으로 지원자를 평가하거나 면접을 진행하기에는 부족한 점이 많다. 특히 석박사 학위조차도 없는 경력이 전무한 지원자나 회사 경력이 1~2년으로 짧아 수행한 프로젝트 실적이 별로 없는 경우는 제대로 판단할 수 없을뿐더러 때론 적당한 질문 거리를 찾지 못해서 면접이 매끄럽지 못한 경우가 종종 있다. 경력이 전무한 경우 인턴/수습이라는 안전장치를 마련하기도 하지만 면접보다는 조금 나을 뿐 2~3개월 동안 수행한 인턴 과제만으로 온전히 평가하기는 여전히 힘들거니와 -- 다소 부족한 경우 -- 한 번 같이 일한 친구를 과감히 탈락시키는 것도 때론 힘들다. 업무와 거리가 먼 신변잡기를 묻는 것도 공식 인터뷰에서 적절치 않다. 물론 내 기준으로 합격선을 통과한 경우 다소 가벼운 질문을 던지기도 하지만, 선을 넘는 질문은 할 수 없다.
그래서 다양한 형태의 과제를 제시해서 어떻게 문제를 정의하고 해결하는지 관찰하고 관련된 질문을 하는 경우가 흔하다. 대외 활동을 거의 안 해서 다른 곳에선 어떤 면접 과제를 제시하는지 잘 모르지만, 내가 참여한 인터뷰에서는 보통 3가지 형태로 정리할 수 있다. 일반 개발자가 아닌 데이터 과학자 (데이터 엔지니어, 머신러닝 엔지니어 등 포함)를 채용하는 인터뷰 과제임을 염두에 두기 바란다.
첫 번째는 문제 상황과 예시 데이터를 제공하고 어떻게 해결할지 묻는다. 인터뷰 일주일 정도 전에 미리 질문지를 주고 발표자료 등을 준비하도록 하는 경우도 있고, 인터뷰 시간에 즉석으로 묻는 경우도 있다. 두 번째는 공개/비공개 데이터를 제공하고 분석하게 하거나 특정 알고리즘을 직접 구현하게 한다. 첫 번째 과제는 문제 정의 등의 아이데이션과 리서치에 좀 더 초점을 맞췄다면, 두 번째 과제는 연구와 구현 스킬, 그리고 데이터 분석 프랙티스에 초점을 맞췄다. 분석 및 구현 과제는 나중에 다시 자세히 적기로 하고, 세 번째 형태의 과제는 업무에 필요한 논문을 선정해서 그걸 리뷰하는 발표를 시키는 거다.
논문 과제가 좋은 여러 이유가 있다. 첫째, 논문을 읽으면서 지원한 팀에서 어떤 일을 하고 있는지 또는 어떤 분야에 관심이 있는지를 지원자 스스로 파악할 수 있다. 둘째 면접관은 논문 리뷰를 통해서 지원자의 연구 능력을 점검할 수 있다. 논문은 제대로 이해했는지, 관련된 레퍼런스는 읽어봤는지, 뒤에서 다시 적겠지만 논문에서 제시한 방법론을 직접 구현하거나 관련 오픈소스를 실행해봤는지 등의 연구 능력뿐만 아니라, 발표 자료 준비를 포함해서 발표는 잘하는지 등을 파악할 수 있디. 세 번째는 자연스럽게 다양한 질문을 할 수 있다. 내게 생소한 경력이거나 경력이 전무한 경우 적절한 질문을 생각하는 것도 곤혹이다. 뜬금없이 'regularation이 뭐예요?'라고 질문하는 것보다 '논문에서 L1을 사용했는데 이게 뭐고 L2와의 장단점은 뭔가요?'라고 묻는 게 더 자연스럽다. 뿐만 아니라 내가 직접 읽으면서 이해한 것, 이해하기 어려웠거나 궁금했던 점을 그대로 질문하면 되기 때문에 질문 자체가 좀 있어 보이게 된다. Flex. 그래서 면접관이 허섭스레기는 아니구나라는 인식을 줄 수도 있다.ㅎㅎ
특정 논문 하나를 지정해서 준비시키는 경우도 있지만, 보통은 2~3편 중에서 한 편을 직접 골라서 준비하라고 한다. 후자라면 논문을 잘 선택해야 한다. 거두절미하고 가장 쉬운, 가장 자신있는 논문을 선택하는 게 좋다. 어려운 논문을 선택했다고 가산점을 주진 않는다. 물론 어려운데 잘하거나 팀에서 당장 필요한 부분을 긁어줄 역량을 보여준다면 바로 합격하는 희박한 가능성이 없진 않지만, 면접에서 꾼 (전문가)이 아니라면 굳이 그런 도박을 하지 않았으면 한다. 면접관의 질문을 사전에 차단하는 건 좋은 전략이다. 면접관들은 어차피 꼬투리를 잡으려는 사람들이라서 -- 물론 좋은 인재를 영입하는 게 가장 큰 목적이지만 -- 발표 내용을 이해하든 못 하든 어떻게라도 질문을 만들어서 묻는다. 괜히 어려운 질문을 받아서 제대로 답변을 못하는 것보다 쉬운 질문만 나올 수밖에 없도록 만드는 것도 능력이다. 왜 이 논문을 선택했냐? 고 항상 묻는데, 괜히 있어 보이려고 '새로운 걸 공부해보고 싶어서 선택했다'라고 말하고 발표가 엉망이면...? 이건 실제 상황이다.
가능하면 논문이 제시한 방법론을 직접 구현해보거나 관련된 오픈 소스를 구해서 테스트 데이터에 적용해보고 그 결과를 함께 보여주는 것이 그냥 논문의 그림과 테이블만 캡쳐해서 지루하게 설명하는 것보단 낫다. '가능하면'이지 MUST는 아니다. 프로그래밍에 자신이 있다면 좋은 전략이다. 또 가능하면 논문에 적힌 이상을 보여주는 것도 좋다. 논문 저자가 다 적어놓은 장점이나 결론 등을 단순히 카피해서 발표 자료에 붙여 넣기보다는 논문에 적혀있지 않지만 다른 방법론과 비교해서 논평을 한다거나 그 방법론이 보완해야 할 점 등을 -- 틀릴 수도 있지만 -- 함께 보여주는 것도 좋다. 가능하면 참고 논문을 최소 2~3편을 추가로 읽는 것도 좋다. 실무에서 주어진 문제를 정해진 방법으로 해결하는 경우도 간혹 있지만 대부분은 새롭게 문제를 정의/재정의하고 적절한 데이터와 알고리즘을 찾아서 해결하는 경우가 더 흔하다. 이럴 때 필요한 것이 앞서 말한 레퍼런스를 찾아보고 다양한 방법론과 장단점을 비교하는 연구 역량인데, 논문 리뷰 발표를 통해서 그런 역량을 보여주는 것이 좋다. 논문의 내용보다 올바른 연구 역량, 프랙티스를 보여주는 게 더 맞다. 생소한 분야의 논문 한 편을 읽고 모두 이해한다면 당신은 천재, 꼭 합격시켜야 할 인재다.
리뷰 발표는 Q&A를 포함해서 보통 10분에서 30분 내외로 진행된다. 질문이 많아서 더 길어질 수는 있지만 내용 발표 자체는 5~10분 내로 끝내는 게 보통이다. 장황하지 않고 핵심만 집는 발표가 돼야 한다. 긴 발표자료가 지원자의 능력을 보여주는 것이 아니다. 모두에게서 스티브 잡스의 발표를 기대하진 않지만 우린 이미 미니멀리즘에 충분히 익숙해졌다. 발표자료를 만들 때 KISS (Keep It Short & Simple) 원칙만은 지켜줬으면 한다.
... 결론이 없지만 일단 오늘은 여기까지. '낮은 확률로 성공하는 하는 방법이 아닌 높은 확률로 실패하지 않는 방법'에 관한 개인 생각이니, 이 글에 휘둘리지 말고 각자의 장점을 가장 잘 돋보이게 하는 자긴만의 방식으로 준비해서 좋은 결과를 얻기를 바란다.
