프로그래머를 채용할 때는, 회사의 핏과 맞는지를 확인하는 것과 별개로, 개발자 그룹의 일원으로서의 핏을 확인하는 과정이 필요하다. 왜냐면 우리는 각 프로그래머의 수준을 수직선상에 세울 수 있을 뿐만 아니라 (=기술면접), 어떻게 문제에 접근하는지에 대한 방법론을 수평선상에 세울수도 있기 때문이다 (=핏면접).

이러한 기술자를 위한 핏면접은 몇십개의 항목이 달린 체크리스트로 판단할 수 없으며, 그저 좋다, 우리엑 영감을 불어넣는다, 배울점이 있다, 도움이 될 것 같다 같은 추상적인 감상에 의존할 수 밖에 없다. 프로그래밍적 가치관을 '관찰'하는 모습으로 봐도 무방할 것이다.

어떻게 확인하는가?

프로그래밍 문제를 내는 인터뷰를 진행한다.

• 비교적 단순한 프로그래밍 문제를 제시한다. 알고리즘 문제는 안되고, 간단한 검색이 필요한 수준으로.
• 지원자의 화면을 공유하도록 요구한다.
• 지원자가 평소 쓰던 툴 (ide, browser, keyboard & mouse, utils, devices) 을 쓰도록 지시한다.
• 굳이 대화가 필요없음을 상기시킨다. 지원자가 면접관을 의식하지 않도록 최대한 도울 것.

예를 들면,

"fizz buzz 코드를 당신이 익숙한 언어로 구현하시오. 단 적절한 수준의 테스트코드도 같이. 여유가 된다면, 특정 파일에 출력하도록 구현하시오."

이 문제를 제시하고 지원자를 관찰함으로서 아래와 같은 Programming Taste를 확인할 수 있다:

• 어떤 ide를 쓰는가? 그 툴이 얼마나 익숙한가? 그 툴의 잡기능을 얼마나 많이 알고 있나? 그 툴을 얼마나 커스터마이징 해두었는가?
• 얼마나 빠르게 코딩하는가? 자주 망설이는가? 막힘없이 써 내려가는가? 그 언어에 능통해보이는가, 아니면 auto complete 없이는 두 줄 이상 작성하지 못하는가? 어느 부분부터 코딩하는가?
• 자기가 의식적/무의식적으로 반복하는 행위를 줄이기 위해 얼마나 자동화를 활용하였는가? 마우스를 얼마나 많이 쓰는가?
• 검색할 때는 스택오버플로우를 보는가, 아니면 공식 문서를 보는가? 얼마나 빠르게 원하는 답에 도달하는가?

이 많은 정보를 단순한 질문 하나로 얻을 수 있다는 건 사실 꽤 놀라울 정도다. 솔직히 말하자면, 지금까지 만나본 회사들이 이런 방법을 왜 안쓰는지 모르겠다.

영감을 준 자료들

아래 두 책이 이 글의 사상적 뿌리에 해당한다:

• 해커와 화가 : 수준의 차이 (better / worse) 도 존재하고, 그와 별개로 취향의 차이 (a / b) 도 존재함을 상기시켜 줌
• 코딩 호러의 이펙티브 프로그래밍 : (물론 오래 전 얘기(라고 믿고싶)지만) fizzbuzz 테스트조차 통과하지 못하는 개발자가 많다는 것을 알려줌

그리고 회사에서, 아마 H모씨인 것 같은데, 지원자의 환경 (IDE를 포함한 일체의 세팅)을 최대한 보려고 하는 방식의 테스트에 대한 논의를 한 적이 있다. 그것도 글에 상당히 반영되어있다.