개발자 면접 코딩 테스트 과연 옳은 일인가?

개발자를 채용하는 과정에 있어서 능력을 측정하는 방법은 여러가지가 있는 것 같다.
구글의 화이트보드 pseudo code 테스트라던가 일부 회사들의 코딩 테스트에 대한 이야기는 뭐 검색만 조금 해봐도 유명한 방법 중에 하나일 것이다.

그런데 난 여기서 조금 문제가 있다고 본다. 그 이유는

경력의 경우 대체로 경력이 많을 수록 더 많은 언어와 더 많은 프레임워크 더 많은 개발 도구를 경험했을 터인데 그런 사람들에게 고작 테스트 한다는게 소트 알고리즘 아나 모르나 칠판에 써가면서 혹은 종이에 펜으로 써가면서 그걸 지켜보고 있는게 과연 옳은가? 이다.

물론 언어가 중요하지 않고 문제 해결 능력만을 본다고 했을 때 좋은 테스트 방법이라고 생각하는 사람이 있을 수는 있다.
하지만 요즘 같은 시대에 소트 알고리즘을 만들어서 쓰는 사람이 과연 얼마나 되는지 묻고 싶다. 알고리즘이야 검색만 하면 다 나오고, 심지어 알고리즘 코드를 만들지 않고 인터페이스 구현 (IComapre 같은) 후 알고리즘 함수 호출 한번으로 해주는 방법도 있는데 굳이 그런걸 평가하는건 옳은 건 아닌 것 같다. (오히려 C++의 STL이라던지, C#의 Sort 하기 위한 인터페이스 구현 방법 등을 물어 보는게 나은 거 같다)

여기에 수긍이 가는 좋은 글이 있어 링크를 걸어 본다.
Putting Developers to the Test

요지는 개발자들이 개발을 하는데 화이트보드에 써서 개발하지 않고 최적화된 개발툴과 거기에 맞는 OS, Framework, 개발 언어를 적절하게 선택해서 빠른 시간에 개발할 수 있는 능력을 테스트 하는게 맞다고 하는 글이다. 마치 화이트보드 코드 테스트는 잘못된 거라고 비웃듯(?) 써 놓은 글이다.

나도 면접 때 종이에 버블 소트 알고리즘에 대해 구현해 보라고 했던 적이 있었는데, 적잖이 당황했었다. 버블 소트 알고리즘을 알고 구현하는 과정이 옳은가? 에 대한 걸 평가하는 거라면 뭐라 할 말은 없지만, 버블 소트 알고리즘을 코드로 구현 가능한가?에 대한 평가라면 잘못된 평가라고 본다.

그때는 내가 당황에서 역공격을 하지 못했는데, 만약 지금 다시 그런 식으로 면접보는 곳이 있다고 했을때는 난 확실히 역공격을 하고 싶다.
"면접관님은 혹시 알고리즘 짜실 때 화이트보드에 직접 짜시는지요? 그러면 퀵 소트 알고리즘 부터 화이트보드에 보여주시면, 제가 버블 소트 알고리즘 테스트에 응해보도록 하겠습니다. 아! 만약 못하시겠으면 PC를 주세요. 어차피 저희들 다 PC에 앉아서 개발하잖아요?" 라고 말이다.

정말 면접자에게 필요한 코딩 테스트는 알고리즘 코딩 따위가 아니라

• 면접자가 실제 진행했던 프로젝트의 개발 환경 (OS, Development tools, Framework, Language)에 대해 물어보고 왜 그런 환경으로 개발을 하는지에 대한 이해도 측정 질문
• 이슈 관리 시스템(redmine, trac 등등), 버전 관리 시스템(svn, git 등등), 빌드 관리 시스템(jenkins, maven 등등) 등 개발에 필요한 시스템 구축에 대한 이해가 되어 있는지(이런 시스템의 필요성 정도만, 허접한 회사가 아닌 이상 사용은 해봤을테니), 그리고 이런 시스템을 사용하면서 느꼈던 에피소드 등을 유도하는 질문 (항상 빌드를 깨뜨리는 친구가 있었는데 벌금을 물게 했다던지 하는 그 사람만의 이야기)
• 사용했던 라이브러리가 있었다면 그걸 설치해 보라고 하고 어떤 기능을 만들기 위해 썼는지에 대해 보여주는 정도 그리고 여러웠던 점이 무엇이었는지 - 실제로 면접자가 이 라이브러리에 대한 이해도가 어느정도 인지를 측정하는 것으로 본인이 필요에 의해서 쓴 라이브러리라면 코딩이 절로 나올 수 있다.

이런 것들이 되야 하지 않을까 싶다.

그래서 PC를 주고 코딩을 시키는게 아니라 저런걸 찾고 설명해 줄 수 있는 능력?

어차피 시키는 일만 열심히 했던 개발자였고 본인 능력 안키웠으면 저런거 설치해 본 적도 없을 테고, 왜 필요한지도 모를 것이기 때문에 설명을 할 수 없을 것이다.

설마 설명을 했다 한들 본인의 에피소드 얘기를 들어보면 시키는 대로 했는지 본인이 해결하려 했는지 정도는 파악되지 않을까?

회사에서 바로 써먹어야 하는 경력자는 알고리즘을 코딩할 수 있냐 없냐로 측정하는 개발자가 아닌, 개발 환경에 대한 이해를 정확히 하고 본인이 경험했던 이야기를 끄집어 내서 이런 시스템이 왜 필요한지, 문제가 뭐였는지, 어떻게 해결했는지에 대한 진솔한 얘기를 할 수 있는 개발자여야 할 것 같다.

만약 위의 것들을 할 수 있는 개발자라면 당장 내일 출근하라고 해서 개발 환경 세팅하라고 하면 별 다른 문제 없을 할 수 있을 것이다. 게다가 어차피 회사에서 시킬 일은 그 사람이 알고 있던 개발 지식과는 무관할 수 있다. 지원하려는 회사에서 만들어야 하는 시스템의 도메인 지식은 (정말 똑같은 사업을 하는 회사가 아니라면) 새로 배워야 할 가능성이 매우 높기 때문에 어차피 그럴 꺼면 툴 깔고 개발 환경이 뭔지 아는 개발자 데려오는게 시간 낭비를 덜 하는 방법일 것이다.