37signals, 퍼즐 기반 프로그래머 채용을 거부하고 지원자를 직접 시험해보는 방식을 택하다

2013년 2월, 37signals는 회사 블로그에 "우리가 퍼즐과 속임수로 프로그래머를 채용하지 않는 이유"를 게시했고, 그 글은 같은 날 Hacker News에 올랐다. 논의는 상식 퀴즈식 채용의 실패 사례들로 시작되었다. 한 Microsoft 면접자는 《How Would You Move Mount Fuji?》로 준비했는데 C의 strcmp()를 기억만으로 작성하라는 요구를 받았고, Amazon 면접은 Big-O 암송과 "우주의 모든 별을 세어보라"에 치우쳤으며, 면접관들은 종종 그 답이 무엇을 증명하는지 묻지도 않은 채 "프로그래밍 면접 질문"을 검색하기만 했다.

37signals의 반격은 그 장르 자체를 거부하는 것이었다. 퍼즐과 속임수에 기반한 채용은 하지 않는다. 댓글 작성자들은 그 대안을 "직접 시험해보기(trying them out for size)"라고 표현했다. 즉 인위적인 두뇌 퍼즐이 아니라 실제 업무 앞에 지원자를 세우는 것이다. 실무자들은 구체적인 방법으로 같은 방향을 밀어붙였다. ITA Software는 대면 퀴즈가 누군가 오프라인에서 작성한 코드를 읽는 것보다 훨씬 덜 유용하다는 것을 발견했고, 한 채용 담당자는 하루 동안의 페어링을 중심으로 면접을 구성해 세 가지를 물었다. 그 일을 할 수 있는가, 팀에 맞는가, 그리고 상황이 바뀔 때 적응할 수 있는가?

두 가지 선별 방식은 서로 다른 것을 시험한다. 상식 퀴즈와 두뇌 퍼즐은 예상 질문과 준비서라는 온갖 속설이 존재할 만큼 코칭이 가능하며, 인위적인 압박 속에서의 암기력과 침착함을 선별한다. 댓글 작성자들은 통찰형 사고를 하는 사람이 한 시간의 절차적 질문에는 실패하면서도 더 긴 실제 과제에서는 잘 해낼 수 있다는 점, 그리고 공황 발작 중인 지원자가 FizzBuzz에 실패해도 훌륭한 프로그래머일 수 있다는 점을 지적했다. 관찰된 업무는 상식 퀴즈가 답할 수 없는 질문에 답한다. 그 사람이 낯선 코드베이스를 어떻게 읽고, 실수를 어떻게 발견하며, 코드를 어떻게 작성하고, 낯선 사람들과 어떻게 협업하는가.

퍼즐 관문을 버려라. 지원자를 직접 시험해보고 암기가 아니라 실제 업무가 채용을 결정하게 하라

퍼즐 선별은 코칭이 가능하다. 예상 질문과 준비서라는 속설 덕분에 지원자는 예행연습을 할 수 있으므로, 그 시험은 직무 능력이 아니라 준비와 기억력을 측정한다.

지원자를 직접 시험해보는 것은 실제 직무를 관찰한다. 실제 코드베이스를 읽고, 실수를 발견하고, 코드를 작성하고, 협업하는 것 — 두뇌 퍼즐은 만들어낼 수 없는 증거다.

인위적인 압박은 결과를 왜곡한다. 통찰형 사고를 하는 지원자와 불안이 큰 지원자는 한 시간짜리 퍼즐에는 실패해도 더 긴 시간에 걸친 실제 업무에서는 잘 해낼 수 있다.

공개적인 입장은 회사가 무엇을 중시하는지 보여주며, 442개의 댓글이 달린 논쟁을 열어 그 아이디어를 공개적으로 압박 검증하게 했다.

채용 선별이 직무보다 준비를 더 많이 측정한다면, 증거를 바꿔라. 지원자를 실제 업무에 투입해 시험해보고 성과가 결정하게 하라

이 글은 Hacker News에서 648점과 442개의 댓글을 기록하며 37signals를 반(反)퍼즐 진영의 기준점으로 만들었다. 옹호자들은 어려운 두뇌 퍼즐이 압박 속에서의 문제 해결 능력을 드러낸다고 말했고, 반대자들은 하루 동안의 페어링, 값싼 부정적 필터로서의 FizzBuzz, 그리고 오프라인 코드를 읽는 ITA의 관행으로 맞섰다. 시험 방식은 좋지만 인재 유인책으로 여전히 퍼즐이 필요한 덜 알려진 고용주에게는 비현실적이라는 평가를 받았다. 논의에는 측정된 채용 결과가 나타나지 않는다. 그 효과는 규범적이었다. "직접 시험해보기"가 상식 퀴즈 면접의 주요 대안이 되었다.