‘개발자 채용 시 기술실력 검증 어떻게 해야 하나’ 라는 주제로 김창준님 강연에 다녀왔다.
좋은 기회를 마련해주신 김창준님께 먼저 감사드린다.
전체적인 요약은 다른 분들이 이미 잘 정리해주셨기에, 이 포스팅에서는 강연 내용을 듣고 채용에 대해 필자가 생각해왔던 부분을 정리해보고자 한다.
어떤 사람을 뽑을 것인가?
필자도 평소에 ‘어떤 사람을 뽑아야하는가’에 대한 고민이 많이 있었는데, 그 이전에 ‘왜 사람을 뽑는가?’ 와 관련이 있을 것 같다. 대부분의 회사가 개발자를 뽑는 이유는 ‘할일은 많은데 개발자가 부족해서’ 이다. 하지만 아이러니하게도 개발자를 뽑으면 그에 맞춰서 할일도 늘어나기 때문에 똑같은 상황이 반복된다.
예전에 다니던 직장에서는 ‘사람이 부족해다고 뽑진 않겠다. 하지만 좋은 사람이면 무조건 뽑겠다’ 고 선언을 한적이 있었다. 지금 생각해보면 ‘좋은 사람에 대한 정의가 좀 더 명확했으면 어땠을까’ 하는 생각도 들지만 그 당시에는 꽤 마음에 와닿는 내용이었다.
어제 강연에서 ‘회사 내에서 좋은 평가를 받는 개발자들의 특징이나 습관을 추려서 채점표를 만들면 좋다’ 는 이야기가 있었는데 이런 방식을 통해서 회사에서 생각하는 좋은 사람의 정의가 가능할 것 같다. 그리고 추가적으로 드는 생각은 새로 채용하는 사람은 조직의 부족한 부분을 채워줄 수 있는 사람이어야 한다는 점이다. 이런 부분이 없으면 그냥 무난하게 같이 일하기 좋은 사람을 뽑게 될 확률이 높다.
예를 들어 우리는 코드 품질이 너무 낮아서 이런 부분을 잘 관리하고 보완하고 싶다고 한다면 다른 부분에서는 약간 부족하더라도 리팩토링이나 테스트 코드에 장점이 있는 사람을 채용하겠다는 기준을 가지고 사람을 채용하는거다. 물론 채용만 해서 끝나는 일은 아니고 그 사람이 자신의 장점을 잘 발휘할 수록 환경을 조성해주는 것도 필요하겠다.
어떻게 검증할 것인가?
X로 테스트 하면 X를 잘하는 사람이 뽑힌다
이전 직장에서 필자는 리더로서 기존 서비스의 레거시 코드에 대한 고민이 많이 있었다. 그래서 레거시 코드를 잘 해석하고 리팩토링도 할 수 있는 사람을 뽑고 싶었다. 창준님 강연에서 X로 테스트 하면 X를 잘하는 사람이 뽑힌다는 내용이 있었는데 지금 생각해보면 나름 그러한 부분이 반영된 테스트를 만들었던 것 같다.
기술 인터뷰 방식
- 과거에 사용되었던 어떤 기능을 가지고 있는 레거시 코드를 프린트 해서 보여준다.
- 이 코드를 보고 3가지를 설명해달라고 했다
- ** 이 코드가 어떤 기능을 하는 코드인지 간단하게 요약해달라 **
- ** 이 코드를 테스트 한다면 어떤 부분을 어떻게 테스트 할 것인가? **
- ** 이 코드를 개선한다면 어떤 부분을 어떻게 개선할 것인가? **
보완이 필요한 부분
개인적으로 이 방식은 나름 노력대비 괜찮다고 생각했는데 어제 강연을 듣고 부족했다고 생각이 들은 부분은 다음과 같다.
** 객관적이고 명시적인 채점 기준이 없었다 **
- 사내의 개발자들을 대상으로 테스트해보고 채점표를 만들었으면 좋았을 것 같다.
** 말로만 듣다보니 모호하게 느껴지는 부분이 많았다 **
- 실제로 테스트를 해보고 리팩토링을 할 수 있는 환경을 제공해주었으면 좋았을 것 같다. 단 시간은 더 필요로 하게 될 것 같다.
** 스트레스를 많이 받을 수 있다 **
- 면접관 앞에서 짧은 시간안에 코드를 파악하고 설명해야했기 때문에 사람에 따라 압박감때문에 설명을 잘 못했을 수 있다. 좀 더 편안한 환경을 제공할 수 있으면 좋을 것 같다.
가급적 실제 상황에 가까운 환경을 제공하자
강연을 들으면서 개인적으로 한가지 슬펐던 것은 인터뷰를 할 때의 기법 중에 하나가 미래에 어떻게 할 것인지가 아니라 과거에 어떻게 했는가를 물어보라고 하는 부분이었는데, 필자는 사실 “과거에 힘든 프로젝트는 뭐였나요?” 라던지 “최근에 프로젝트 한 것 중에 가장 도전적인건 어떤거였나요?” 라는 질문에 대답을 잘 못하는 경우가 많다.
필자는 과거의 사건들을 추상적인 개념으로 기억하는 경우가 많아서 디테일하게 무엇을 했는지 기억이 나지 않을 때가 많다. 또는 면접장소에서 압박감으로 인해 내가 원격으로 진행한 코딩 테스트에 대해서 왜 이렇게 했는지에 대해서 설명을 못한적도 있다. (집에 가는 길에 화장실에서 기억났다…)
CTA같은 기법을 통해서 나의 전문성을 상대가 끌어내주면 좋겠지만 그런 면접관이 얼마나 있겠나 싶다. 그래서인지 가끔 필자는 인터뷰가 자신이 없을 때가 있다. 나 같은 사람은 질문보다는 실제 과제를 주고 하도록 하는게 더 효과적인 것 같다.
어떻게 좋은 인재를 유치할 것인가?
작거나 유명하지 않은 회사는 저런 고민할 필요가 없는 것 같아요.
제대로 된 지원자가 없으니깐요.
창천향로님의 포스팅에 붙은 어느 댓글의 내용이다. 필자도 비슷한 이유로 고민한 경험이 있다. 사실 이 부분은 회사의 규모와 상관없이 인재 영입에 대해 얼마나 중요성을 인식하고 노력하는가에 가까운 것 같다. 아무나 대충 뽑아도 상관없다고 생각하는 회사라면 빨리 그 회사를 나오는 것이 현명한 판단이지 않을까 싶다.
반대로 직장을 구하는 입장에서 어떤 것을 보고 회사를 지원하는가를 생각해보면 조금은 힌트가 있지 않을까 싶다. 기술 기반 회사란 무엇일까?에서 이야기 한 것처럼 좋은 개발자라면 자신이 보다 성장할 수 있는 환경을 찾으려고 노력할 것이다. 필자가 인터뷰할 때 가장 많이 들은 이직 사유가 ‘성장을 위해서’ 이다.
최근에 직장을 구하는 과정에서 가장 먼저 살핀 것중에 하나는 ‘회사에서 운영하는 개발 블로그가 있는가’였다. Job Description 도 중요한 부분이다. 그 회사에서 무엇을 중요하는지, 어떤 기술을 쓰는지, 가면 내가 어떤 것을 배울 수 있고 성장할 수 있을지에 대해 알 수 있다. 종종 외부에 공개된 대표 인터뷰나 기사 등을 살피기도 한다. 최종적으로는 인터뷰에 가서 그 회사에 대한 여러가지를 물어보고 이야기를 나누면서 회사를 파악하게 되었다. 보여주기 식의 홍보는 당연히 안되겠지만 회사 입장에서는 회사의 장점을 적극적으로 알리고 개발자들이 매력을 느낄 수 있도록 노력을 기울여야한다.
혹자는 회사에서의 최고의 복지는 좋은 동료와 함께 일하는 것이라고 한다. 반대로 직장을 옮기게 되는 가장 큰 이유 중에 하나도 사람 때문이다. 이게 우리가 인사권을 가지고 있지 않더라도 채용에 관심을 가져야만 하는 이유이다.
앞으로 일하게 될 직장에서도 이러한 부분에 대해 동료들과 함께 고민하고 발전시킬 수 있는 계기가 되었으면 좋겠다.