코딩 인터뷰
너무 오래된 주제, 그래서 식상할 수도 있는 주제, 그 주제에 대해 작성하고자 한다.
인터뷰 프로세스에서 코딩 인터뷰는 실효성이 없다.
개인적인 의견으로는 어떤 경우에는 맞으며 어떤 경우는 틀리다. 코딩 인터뷰를 통해 확인하고자 하는 것은 모두 다를지더라도 대부분 확인하고자 하는 부분은 문제 해결 능력일 것이다. 그다음에 코드의 유지보수성과 같은 것들을 확인할 것이다. 아무튼 코딩 인터뷰를 인터뷰 프로세스에 포함했다는 것은 특정 역량이 적절한지를 확인하고자 하는 목적이 있는 것이다. 그런데 그 목적과 무관하게 사용하는 게 많다. 그래서 실효성을 느낄 수 없다. 대부분이 다음과 같은 상황일 것이다.
그 상황은 인터뷰 프로세스에서 알고리즘을 이용하여 문제를 해결하는 코딩 인터뷰가 포함되어 있었고, 이를 통과하여 입사 후 업무를 수행했으나 수년이 지나도록 알고리즘 문제 해결 능력을 요구하는 수준의 경험을 하지 않는 상황이다. 이런 회사의 실 업무는 요구 사항의 이해 능력, 커뮤니케이션 스킬과 협업 능력, 그리고 기술적으로는 코드의 유지보수성이나 시스템 디자인 쪽의 능력을 대부분 요구하는 게 많을 것이다. 이런 상황이라면 면접자는 ‘굳이 그런 코딩 인터뷰가 필요했을까’라는 생각을 해볼 만하다. 반대 상황도 있다. 면접자가 코딩 인터뷰에 매우 탁월한 성적을 거둔 사람이더라도 앞서 말한 부분의 역량이 낮을 수 있다. 코딩 인터뷰에 오해를 가지고 있거나 환상을 가진 면접관이라면 이런 면접자와의 면접 후 코딩 인터뷰에 대한 신뢰감이 점차 낮아질 것이다.
그렇다면 코딩 인터뷰 말고 다른 인터뷰 유형을 이용한다면 상황이 나아질까? 말 그대로 코딩 인터뷰 무용론을 주장하는 사람들처럼 코딩 인터뷰가 없다면 더 좋아질까? 개인적인 생각으로는 ‘아니다’라고 말하고 싶다. 이유는 모든 상황에 어울리는 완벽한 인터뷰는 없기 때문이다.
코딩 인터뷰가 아닌 다른 인터뷰 유형을 봐보자. 먼저 첫 번째, 실무 면접을 바로 보는 경우이다. 코딩 인터뷰 없이 바로 실무 면접을 본다고 할 경우 다음과 같은 문제점에 봉착할 수도 있다. 형편없는 면접자와 30분 또는 1시간 같은 정해진 시간을 사용해야 하는 상황이 더 많이 발생하게 된다. 면접관으로 누가 들어가는가에 다르겠지만 대부분 실력이 있는 사람들이 면접관으로 참석하게 될 것이다. 더욱이 대부분 이렇게 실력이 있는 사람들은 시간당 비용이 더 비싸다. 그런 사람들이 형편없는 면접자와 시간을 사용해야 하는 경우 이게 과연 효율적인지를 봐야 할 것이다. 또 다른 상황으로는 일명 ‘말만 좋은’ 사람이다. 이런 사람들과 인터뷰할 때는 대화를 하는데 막힘이 없으며 여러 가지 상황 또한 잘 주도한다. 그런데 코드를 작성하는 능력은 형편이 없다. 모든 것을 ‘말’로만 한다. 이런 사람들과 협업하다 보면 작성한 코드를 볼 때마다 짜증이 날 것이다.
두 번째, 과제 제출은 어떨까? 과제 제출은 코딩 인터뷰와 실무 면접 그사이에 위치한 인터뷰 유형이라고 생각한다. 면접자는 과제를 수행할 때 코딩 인터뷰보다 시간을 더 사용하고 되고, 과제 검토자도 코딩 인터뷰보다는 시간을 더 사용하게 된다. 다만 과제가 실무와 비슷할 테니까 검증 절차가 코딩 인터뷰 보다는 실무에 더 근접하게 동작할 것이라는 기대하게 해준다. 다만, 이는 코딩 인터뷰 문제 품질에 비해 과제 품질에 따라 해당 인터뷰 절차의 품질이 너무 달라진다. 특히 다양한 해결책을 요구하는 과제가 아닐 경우 접수되는 과제들의 형태는 대부분 동일하다. 이런 경우 오히려 코딩 인터뷰보다 더 많은 (1차 과정) 합격자가 발생하게 된다. 변별력이 더 없어진다고 할까나.
즉, 그 어느 것도 모든 회사에 대해 완벽하게 적용할 수 있는 인터뷰 유형은 없다. 회사마다 업무를 수행하는 방식이 다르다. 그에 따라 원하는 인재상이 있다. 회사는 그런 인재상을 가진 사람들이 통과할 수 있도록 인터뷰 프로세스를 수립해야 한다. 해당 인재상이 코딩 인터뷰를 통해 검증할 수 있다면 당연히 인터뷰 프로세스에 포함해야 하고, 그렇지 않다면 제외해야 한다. 회사 입장으로 실무 면접이 중요하고 거기에 큰 노력을 쏟는 게 당연하다면 그 방식을 취해야 하는 게 맞다. 과제가 중요하다면 당연히 과제를 프로세스에 포함해야 한다. 여기서 놓치지 않아야 할 중요한 한 가지는 특정 인터뷰 유형을 포함했을 때 그 목적에 맞게 해당 과정의 품질을 높여야 한다는 것이다. 코딩 인터뷰대로, 과제대로, 그리고 실무 면접대로 그 유형에 합당한 품질로 인터뷰를 진행해야 한다. 이는 “다른 회사들도 다 하니 우리도 하자”, “굴지의 IT기업인 구글이 알고리즘을 이용한 코딩 인터뷰를 통해 채용하고 있으니 우리도 하자”라는 식으로 인터뷰 프로세스를 수립하면 안 된다.
자, 그럼 내가 만약 인터뷰 프로세스를 수립하는 사람이고 코딩 인터뷰를 사용한다면 어떻게 할까? 먼저 어떤 목적으로 코딩 인터뷰를 사용하는지 확인해야 한다. 일반적으로 인식하고 있는 알고리즘적인 문제 해결 능력을 중요시한다면 그런 문제 유형으로 코딩 인터뷰를 준비하거나, 코드를 작성할 수 있는 능력이 없는 사람을 거르기 위한 용도라면 간단한 퍼즐 위주의 문제를 준비하거나, 적당한 실력과 함께 코드의 구조화 같은 작성 능력을 보고 싶다면 적정 수준 그리고 코드 구조를 볼 수 있는 코딩 인터뷰를 준비하면 된다. 즉, 목적에 맞게 사용하라는 것이다. 이 원칙은 다른 면접도 동일하다. 바로 대면 면접 볼 때나 과제를 제출할 때도 그 목적에 맞추어 운용한다면 앞서 말했단 단점들은 어느 정도 해소할 수가 있다. 목적에 잘 부합한다면 그 목적에 해당하는 면접자들이 입사하게 된다.
면접자 또는 면접관들은 이 인터뷰 프로세스에 대해서도 이해해야 한다. “왜 이 회사가 이 절차를 넣었을까?”라는 관점으로 접근하고 사고할 경우 면접자는 “이 회사의 업무는 이런 능력을 요구하겠구나”라는 것을 예측해 볼 수 있다. 면접관은 이 면접자가 어떤 이유로 통과했는지, 그렇기 때문에 어떤 부분의 능력은 검증이 안 되었는지도 미리 확인할 수 있다. 즉, 본인이 면접관이라면 대면 면접 전 단계, 여기서는 코딩 인터뷰가 그 전 단계라면 그 단계를 통과한 면접자가 자신이 생각하는 모든 역량을 코딩 인터뷰를 통해 검증되었다고 오해해서는 안 된다는 얘기다. 만약 그런 것이라면 대면 면접을 볼 필요 없다. 코딩 인터뷰로만 채용하면 될 것이다.
정리가 잘 안된 매끄럽지 않은 글이라 생각하여 다음과 같이 정리해봤다.
- 코딩 인터뷰는 무용하지 않다.
- 코딩 인터뷰가 무용한 경우는 이를 잘못된 방향으로 사용한 회사에 문제가 있다. 이 경우는 코딩 인터뷰뿐만 아니라 다른 인터뷰 유형에서도 동일하다.
- 인터뷰 프로세스의 모든 절차는 회사의 목적과 인재상에 맞게 운용해야 한다.
- 면접자들과 면접관들은 인터뷰 프로세스가 어떤 목적에 의해 구축되었는지 이해할 필요가 있다.
사족으로… 개인적으로는 코딩 인터뷰를 위해서 알고리즘 문제 해결 능력을 키우기보다는 개인의 사고 능력 향상을 위해 알고리즘 문제 해결 능력을 키우는 것이 좋다. 인터뷰에 포함되어 있으니까 공부하기보다는 본인의 사고 능력을 개선하기 위해서 꾸준히 학습하는 것이 시스템적인 문제를 해결할 때도 도움이 된다는 것이다. 물론 매일 학습할 필요는 없다. 본인의 망각 주기에 따라 학습하면 된다. 1일에 한 번, 1주일에 한 번, 1개월에 한 번, 3개월에 한 번 등 본인의 학습 스타일에 맞추어 꾸준히 학습한다면 본인의 역량에 실보다는 득이 있는 결과물이 나타날 것이다.