Hacker News

Side-stepping the Secretary Problem, unwittingly

모르고 비켜 간 비서 문제

저자는 채용에서 탈락자를 다시 지원할 수 있게 하고 학습 지원도 제공해, 잠재력 있는 지원자를 놓치지 않으려 했습니다. 24시간 내 응답, 비동기 심사, 짧은 과제 같은 운영 원칙과 채용 결과를 소개합니다.

AI 요약

저자는 채용 과정에서 지원자를 한 번 거절하면 다시 만날 수 없다는 ‘비서 문제(Secretary Problem)’의 제약을 우회한 경험을 전합니다. 2013년 말부터 2014년까지 인도 푸네에서 Clojure를 배우며 QA 업무를 할 사람을 찾았습니다. 프로그래밍과 테스팅을 함께 맡을 지원자가 드문 상황이라, 잠재력 있는 사람을 탈락 한 번으로 잃지 않는 방식을 고민했습니다.

다시 지원할 문을 열어 둔 채용

저자와 동료는 탈락자에게 일정한 냉각 기간을 둔 뒤 재지원할 수 있다고 알렸습니다. 채용하지 않은 지원자 가운데 관심을 보이는 사람에게는 학습 자료를 보내고, 매주 정해진 시간에 오피스 아워(office hours)를 열어 Clojure 학습을 도왔습니다. 탈락 통보를 한 뒤 다시 연락하겠다는 막연한 약속 대신, 지원자가 실제로 재도전할 길을 만들자는 취지였습니다.

약 300명의 지원자 가운데 다섯 명을 채용했습니다. 모두 약 한 달 만에 생산성을 보였고, 세 명은 Clojure를 익혔으며 두 명은 모바일 SDK 팀으로 옮겼습니다. 이후 QA 조직이 사라지는 사내 개편을 거치면서도 이들은 백엔드 개발과 프로덕트 매니지먼트 등으로 역할을 넓혔습니다. 근속 기간은 각각 4년에서 10년이었습니다. 오피스 아워를 경험한 지원자의 배우자가 채용되지 않았는데도, 그 경험을 좋게 평가한 덕분에 다른 엔지니어가 입사한 사례도 소개합니다.

빠르고 비동기적인 심사

채용 과정에서는 지원자에게 최대 24시간 안에 답하겠다고 약속하고, 답을 받지 못하면 먼저 연락해 달라고 안내했습니다. 누구도 잠수 상태로 두지 않았으며, 단계별 판단 근거를 지원자 추적 시스템(ATS)에 바로 기록했습니다. 전화나 대면 면접은 업무 흐름을 끊으므로 뒤쪽 단계에 배치했습니다. 전화 면접에는 질문과 평가 기준을 정한 진행안을 사용했고, 대화가 맞지 않으면 예의를 갖춰 일찍 마쳤습니다.

지원자에게 몇 시간씩 걸리는 코딩 과제는 내지 않았습니다. 과제는 해당 경력 수준에서 약 15분 안에 끝낼 분량으로 제한했습니다. 코드 제출 뒤 몇 분 안에 검토해 다음 단계로 진행할지 결정하고, 필요하면 전혀 다른 설계로 리팩터링해 달라고 요청했습니다. 코드 복사는 허용하되 숨기지 말라고 명확히 알렸으며, 복사 사실을 감추면 채용 뒤에도 해고 사유가 된다고 밝혔습니다.

초기 심사는 이메일로 진행했습니다. 과제와 질의응답, 리팩터링 요청까지 글로 주고받으며 지원자의 읽기와 쓰기 능력도 살폈습니다. 첫 이메일에는 Clojure 학습 의무, 직급, 보상 범위, 승진 전망, 온콜, 코드 리뷰 문화처럼 지원자가 미리 고려할 조건을 적었습니다. 다만 당시에는 보상 범위를 처음부터 공개할 수 없었다고 덧붙입니다.

두 면접관이 모두 찬성해야 다음 단계로 넘어가는 비동기 의사결정 규칙도 마련했습니다. 한 명만 찬성하면 탈락으로 처리했고, 두 사람 모두 24시간 안에 ATS에 의견을 남겼습니다. 최종 단계에는 ‘정말 채용하고 싶은’ 지원자만 보냈습니다. 문을 열어 두었기에 아쉬운 지원자에게 빠르게 거절을 전할 수 있었고, 이후 다시 도전할 기회도 남겼습니다.

일반적인 채용 방식에 대한 문제 제기

저자는 지원자 수와 채용 결과를 미리 알기 어렵고, 지원자들이 동일한 확률로 나타나지도 않으므로 전통적인 채용이 비서 문제와 정확히 같지는 않다고 인정합니다. 다만 한 번 거절하면 재지원이 사실상 막히는 관행은 지원자 풀을 잃게 만든다고 봅니다. 지원자를 빠르게 심사해 부적합한 경우와 명백한 오판을 걸러 내고, 재지원 정책으로 잠재력 있는 사람을 다시 만날 가능성을 남기는 방식입니다.

그는 대기업의 여러 단계 면접을 그대로 따라 하는 방식도 비판합니다. 제한된 인력으로 일하는 작은 회사가 시끄러운 지원자 풀과 긴 면접 절차를 감당하기는 어렵기 때문입니다. 채용 속도와 명확한 소통, 지원자 시간 보호를 함께 설계해야 한다고 설명합니다.

Hacker News 반응

  • @hungryhobbit — 글을 이해하기 어렵습니다. 자기 방식이 훌륭했다고 자화자찬하는 내용은 많은데, 다른 기술 회사와 실제로 어떻게 달랐는지는 거의 설명하지 않습니다. 글을 읽기는 했지만, 설명한 내용이 다른 회사와 같거나 거의 같아 보였습니다. ‘무료 수업’만 달랐는데, 그건 이야기의 중심이라기보다 각주처럼 보입니다.
    • @WCSTombs — “다른 기술 회사와 거의 같았다”는 말과 “무료 수업은 좋았다”는 말이 답인 것 같습니다. 제가 아는 한 그런 지원은 거의 찾아보기 어렵습니다. 그 점을 너무 가볍게 넘기고 계십니다.
    • @adityaathalye — 저는 그게 비서 문제를 완화하는 두 방법 가운데 하나라고 봅니다. 한쪽은 유입되는 지원서가 쌓이는 속도보다 더 빠르게 합격이나 불합격을 결정하는 처리량입니다. 다른 한쪽은 지원자 풀을 잃지 않는 일입니다. 재지원 문을 열어 두는 정책이 도움이 된다고 생각합니다. 명시적으로 재지원 기회를 안내하는 소프트웨어 회사가 한두 곳은 있습니다. 기억이 맞다면 Jane Street도 그렇습니다.
  • @quadrifoliate — 24시간 안에 답하고, 면접에서 부족했던 점을 알려 주고, 6개월 뒤 다시 도전하도록 오피스 아워까지 제공하는 일이 “다른 회사와 거의 같다”면 저는 15년 동안 엉뚱한 곳에서 면접을 본 셈입니다. 물론 저자가 과장하지 않았다는 전제입니다. 회사 일을 하면서 면접관이 오피스 아워까지 맡으면 지칠 것 같습니다.
    • @adityaathalye — 동료와 저도 당시에는 같은 걱정을 했습니다. 하지만 엄격한 제약을 정하고 나니 그 안에서 운영할 시스템을 빠르게 만들었습니다. 특히 오피스 아워는 신청자가 많지 않을 거라고 예상했지만, 실제로 가능한지는 확신하지 못했습니다. 해 보니 지치는 일이 아니었습니다. 그게 글 제목의 ‘모르고’에 해당합니다. 기존 채용 절차에 제약만 덧붙이고 면접관에게 절차를 조정할 권한을 주지 않으면 지치고 엉망이 될 거라고 봅니다.
  • @jawilson2 — SLA와 ATS는 무엇인가요?
    • @randochatter — 서비스 수준 협약(Service Level Agreement)과 지원자 추적 시스템(Applicant Tracking System)입니다.
  • @robto — 이 방식은 마음에 듭니다. 저도 비슷한 방식으로 소프트웨어 개발을 시작했습니다. 지원한 회사에서 탈락했지만 6개월 뒤 다시 지원하라는 안내를 받았습니다. 그동안 배우고 성장해 경계선에 있던 지원자에서 적합한 지원자가 됐습니다. 경력 전환의 기대 이익이 컸고, 다시 문이 열릴 수 있다는 사실이 계속 노력하도록 동기를 줬습니다.
  • @madrox — 현대 채용은 실제 비서 문제와 다릅니다. 비서 문제는 미래 표본에 관한 정보가 없고 재시도 횟수도 정해진 상황에서 언제 멈출지 묻습니다. 요즘 채용은 그런 방식으로 진행되지 않습니다. 저자는 비서 문제를 비켜 간 게 아니라고 생각합니다. 최적 정지 문제를 공부해 본 사람으로서 그 부분이 거슬립니다.
    • @adityaathalye — 채용 담당자로서는 채용하고 가르칠 만한 사람이 어디에 있는지 모른다는 점, 그리고 전통적인 채용 과정에서는 한 번 탈락하면 다시 기회가 없다는 점 때문에 채용을 최적 정지 문제로 해석했습니다. 재지원 정책으로 재시도 횟수를 무한대로 늘리고, 지원서를 빠르게 처리해 부적합한 지원자를 거르며 일부 오판 가능성을 감수하는 방식입니다. 정확한 과학이라고 주장하는 것은 아닙니다. 제가 틀릴 수도 있습니다.
  • @anon48293 — 비서 문제의 해답은 37%입니다. 그런데 왜 최고인 사람이 꼭 필요하겠습니까? 저는 일을 할 줄 알고 함께 일하기 좋은 사람이 필요합니다.

원문: EvalApply / 번역·요약: Trawling