코딩 면접에 대해서

지금까지 개발자를 많이 뽑아왔고 스스로도 면접에 참여한 경험이 많다. 내가 사람을 뽑을 때 생각하는 기준을 적어본다. 사실 이 내용은 현재 대부분의 회사에서 하는 것과는 상반되는 부분이다. 그리고 이렇게 면접이 바뀔 가능성은 별로 없어 보인다. 코딩 테스트 잘해서 뽑았는데, 시키면 할 줄 아는 게 별로 없는 경우가 너무 많지만 현재의 트랜드는 코딩 테스트이다.

 

현실은 좋은 회사라고 평판이 높은 회사일 수록 코딩테스트를 더 많이, 더 어렵게 보고 있다. 그리고 스타트업들도 이런 식으로 코딩테스트를 준비하는 업체가 많고 실제로 도입하고 있다. 문제는 코딩테스트 이외에 어떤 질문을 해야할지에 대해서는 거의 고민하지 않는다는 느낌이었다. 코딩테스트 아닌 질문의 대부분은 지엽적인 특정 언어의 기능과 새로운 기술을 들어봤는지 정도이다. 예를 들면 C++의 functor가 무엇인가? js의 클로저가 무엇인가? python의 generator가 뭔가 이런 식이다. 좀 더 어렵게 들어가면 TLS구조 같은 것이나 mTLS의 signature, encryption같은 구성요소 같은 것들이다. 물론 의미가 있을 수 있지만 면접의미는 그 사람의 지식 수준을 포괄적으로 파악하는 일이라 이런 식의 지엽적인 질문은 도움이 되지 않는 것 같다.

 

나 스스로 부터 코딩 테스트를 대학교를 방금 졸업한 사람보다 잘할 자신이 없다. 아니 부트 캠프 졸업하고 취업 준비로 6개월에서 1년 간 코딩 테스트 준비를 한 사람은 분명 나보다 훨신 코딩 테스트를 잘 통과할 것이다. 경험상 코딩테스트의 지식은 오래가지 않는다. 알고리즘을 좋아하거나 이 분야에 타고난 사람들이 있겠지만 그런 사람을 제외한 나같은 일반인은 시간이 지나면 예전에 지식이 조금 씩 사라져버린다. 특히 나같이 주력언어가 없는 사람들은 종종 문법조차도 생각이 잘 나지 않는다. 필요할 때 언어를 골라서 필요할 때 참조하는 식이기 때문이다.

코딩테스트는 테크닉적인 부분이 많다. 실제 모르는 문제를 풀기 까지 쉬우면 금방이지만 감을 못잡으면 1시간 이상도 걸린다. 그래서 대부분의 코딩테스트는 기억에 의존하는 경우가 많다. 6개월 동안 풀어본적이 있는 문제는 그 나마 수월하게 처리할 수 있다.

 

아래는 내가 가진 면접에 대한 기본적인 생각이다.

 

1. 코딩 테스트 의미는 프로그래밍 언어를 다룰 수 있는지에 대한 것으로 충분하다. 나의 경우는 극단적이지만 면접 시에 코딩 테스트 자체를 하지 않는다. 그럼에 경험 상 더 나은 사람을 더 적절한 연봉으로 다른 면접관에 비해 선발했다고 자부한다.

  1-1 코딩 테스트를 잘한다는 것은 그것에 대해서 익숙하다는 것이다.

  1-2 특정 알고리즘으로 특정문제의 패턴을 인식해서 더 빨리 푼다는 의미이다.

  1-3 그런 특정분야에서는 의미가 있지만 일반적인 환경에서는 별 의미가 없다.

  1-4 일반적인 개발환경에서는 컨텍스를 이해할 시간은 충분히 주어진다. 대부분의 제약사항이나 요구사항은 이미 다 숙지된 상태이다. 따라서 코딩테스트에서 내용을 이해하는 데 얼마나 시간이 주어지는지는 의미가 없다. 

    1-4-1 내용을 정확하게 이해한 상태에서만 평가를 시작하는 것이 합리적이다.

    1-4-2 만약 내용 파악에 대해서도 평가하는 것은 개발 이외의 부분을 평가하는 것으로 보면 된다. 그리고 이게 의미가 있는지도 모르겠다.

  1-5 요즘 주요 회사들이 코딩 테스트 과정에서 풀이 과정을 크게 말하는 것을 요구한다. 아마존이 대표적이다. 쿠팡도 비슷한 형식으로 따라가고 있다. 문제는 코딩 테스트로 문제해결 과정을 본다고 하는데 대부분의 코딩테스트는 문제해결과정이 없다. 그냥 해결책 하나의 방법만 알면 종료이다. 코딩 테스트를 하면서 말하는 내용의 대부분은 풀이 과정이 아니라 어떻게 코드를 쓸 건지 이야기 하는 것에 불과하다. 결국 이것도 위에 말한 것 처럼 풀이법을 아는 것이 전부라 별로 도움이 안된다고 생각한다.

 

2. 더 중요한 것은 '왜'이다. 사실 '왜'를 알기 까지가 더 많은 경험과 코딩의 과정을 필요로 한다.

  2-0 개인적으로는 코딩 문제를 하나 더 풀기 위해서 학습하는 시간보다는 이런 배경을 공부하고 전반적인 기술을 익히는 것이 실제 과업에서는 더 필요로 하는 스킬이다. 그리고 다양한 경험과 다양한 실무지식의 습득은 엄청난 시간을 필요로 한다.

  2-1 어떤 언어를 선택한 이유, 특정 플랫폼, 특정 데이터베이스, 그리고 캐시 서버나 메시징 구조 같은 것들을 정확하게 비교하고  선택할 수 있는 이유가 더 중요하다. 이런 지식이 없으면 그냥 시키는 대로 코딩만 하는 사람만 뽑게 된다. 최소한 관심이 있는 사람을 뽑아야 한다.

  2-2 이런 것들에 대해 설명하려면 기반적인 지식이 필수적이다. 시대에 트랜드에 따른다고 무작정 Redis를 사용하고 Rust같은 언어를 배우는 것으로 충분하지 않다. 모든 것이 왜이다. 예를 들어 데이터 모델의 중요성에 대한 질문만 해봐도 많은 부분에서 스킬을 판단할 수 있다. 데이터모델에 따라서 프로그래밍 언어나 데이터 구조, 데이터베이스 타입이 모두 결정되고 실제 구현도 당연히 영향을 받게 된다. 일반적으로 데이터 모델은 관계형, NoSQL, Network 모델 정도로 구분할 수 있는데 이런 모델의 장단점을 질문하고 이런 질문에 따라서 어떤 언어를 사용하고 어떤 언어의 특징이 각 모델에 유리한지 이런 식의 질문이 사실 기술을 파악하는데 더 적합하다. 이런 부분이 어렵다면 특정한 서비스를 들어 어떤 프레임워크를 사용하는 것이 좋은지 이야기 하는 것도 괜찮은 질문이다. 이런 질문은 확장이 될 수 있고 더 나아가서 깊은 토론을 통해 후보자의 지식의 깊이를 알 수 있다.

 

3. 사실 이것보다 더 중요한 것은 인성과 협업의 자세이다.

  3-1 아무리 잘하는 사람을 뽑으면 뭐하냐. 실제 업무에서 비협조적이고 자기 고집만 강한 사람이 너무 많다.

  3-2 그래서 개인적으로 일정한 기술 수준을 만족하면 그 사람의 개인적인 면을 더 자세히 본다.

  3-3 성격좋은 인사를 뽑는다는 의미가 아니라 최소한 협업과 토론에 지장이 있는 사람은 걸러내야 한다는 의미다. 

  3-4 기본적인 사람에 대한 존중과 매너가 없으면 아무리 기술이 좋아도 장기로 보면 최악의 선택이 될 뿐이다.