대부분의 기술 채용이 왜 비효율적이고 무례하며 신호력이 낮은지 짚고, 차별화·업무 관련성·장기성·시간 효율·존중·취향을 기준으로 기존 방식들을 평가한 뒤, 코드 리뷰와 작업 샘플 라이브 토론을 결합한 더 나은 대안을 제안합니다.
친구들을 위한 노트: 이 글은 회사와 엔지니어링 매니저를 대상으로 합니다. 여러분이 채용이 엉망이고 회사들이 여러분의 시간을 낭비한다는 걸 저는 잘 압니다. 이 글은 왜 그러면 안 되는지에 대한 비즈니스적 근거입니다.
대부분의 회사는 채용을 못합니다. 모두의 시간을 낭비하죠(저는 한 번은 무려 9차 면접 파이프라인을 겪었습니다!). 가장 유행하는 프로그래머만 쫓고, LLM과 프로그래머를 구분하지도 못합니다. 요컨대, 머니볼을 하지 않습니다.
지원자에게도 상황은 나쁩니다. 제가 아는 최고 수준의 프로그래머들(러스트 컴파일러를 유지보수하는 사람들을 떠올리세요) 중 일부는 스트레스 상황에서 면접을 못 본다는 이유로 일자리를 얻지 못합니다. 하스켈 4년, 러스트 2년 경력자에게 리크루터가 "비기술적"이라고 라벨을 붙인 일도 있었죠. 그리고 당연하게도, 회사들은 합격 여부를 몇 주, 몇 달씩 연락을 끊고(ghost) 사람들을 방치합니다.
이 글은 왜 채용이 어려운지, 기존 접근법이 어떻게 실패하는지, 그리고 더 나은 접근이 어떤 모습일 수 있는지를 탐구합니다. 제 목표는 물론 제 친구들이 채용되는 것입니다. 여기 아이디어가 마음에 든다면 저에게 연락하세요.
제가 선호하는 접근을 이야기하기 전에, 몇 가지(가능하면 논란이 적은) 원칙부터 세워 봅시다.
면접은 다음을 만족해야 합니다.
구분할 것. 시니어 프로그래머와 ChatGPT를 쓰는 마케터를 구분할 수 있어야 합니다.
업무와 관련 있을 것. 실제 직무를 반영해야 합니다. * 코딩도 포함됩니다. 하지만 아키텍처 설계, PR 리뷰, 문서화 등등도 포함됩니다. 훌륭한 시니어 소프트웨어 엔지니어는 모두 제너럴리스트입니다.
장기적으로 생각할 것. 다음 분기만이 아니라 앞으로 수년간 좋은 직원을 선발해야 합니다. * 사람은 대체 가능하지 않습니다. * 프로젝트에 잘 맞는 직원을 잃는 비용은 매우 큽니다. * 직원을 잃는 것 자체의 비용도 큽니다. * 회사는 결정화 지식(crystallized knowledge)에는 과도하게 가중치를 두고, 유동 지능(fluid intelligence)은 과소평가하곤 합니다. 기술 스택이 딱 맞는 사람을 찾겠다고 한 달을 더 쓰는 것은, 사실 한 달이면 온보딩이 가능한 상황에서, 일종의 고급 자해 행위입니다.
시간 효율적일 것. 면접에 드는 시간을 가능한 한 줄여야 합니다. * 엔지니어 시간은 비쌉니다.
존중할 것. 지원자와 그들의 시간을 존중해야 합니다. * 지원자를 존중하지 않으면, 자신을 존중하지 않는 사람들만 남게 되고 최고의 지원자들은 떠납니다. * "자존감 낮은 사람을 뽑아서 적게 주고 쓰고 싶다"—당장 제 사이트에서 꺼지시고 다시는 오지 마세요.
또 하나, 더 논쟁의 여지가 있는 6번째 기준이 있습니다. 이를 **취향(taste)**이라 부르겠습니다. 취향이 나쁜 엔지니어는 팀의 다른 사람들에게 커다란 뒷수습을 남기는 대가로, 무언가를 매우 빠르게 배송할 수 있습니다. 이를 측정하기는 매우 어렵지만 동시에 매우 중요합니다. 반대로, 팀을 성장시키는 일에 시간을 쓰는 사람은 팀의 생산성에 승수 효과를 냅니다 (참조: "Being Glue").
이제 흔한 면접 방식들이 어떤지 보겠습니다.
구분, 업무 관련성, 존중, 취향에서 실패합니다. 장기적 가치에 대한 신호도 거의 주지 못합니다. 라이브 코딩은 시니어 프로그래머와 ChatGPT를 쓰는 마케터를 구분하지 못하고, 대부분의 문제는 일상 업무와 거의 관련이 없습니다. 훌륭한 소프트웨어 엔지니어는 제너럴리스트이고, 라이브 코딩은 제너럴리스트를 선별하지 못합니다.
라이브 코딩을 보완하려고 여러 라운드를 더해 위 책임들 각각을 테스트할 수 있습니다. 하지만 그러면 시간 효율성이 사라집니다. 모든 것이 엔지니어 시간을 많이 잡아먹죠. 그 비용을 감수하고 밀어붙이는 것은 부의 과시이며, 이 시점에서 당신은 더 이상 머니볼을 하는 게 아닙니다.
게다가 경력이 많은 사람일수록 이런 경험을 모욕적으로 느끼는 경향이 있어, 최고의 지원자들을 걸러내는 꼴이 됩니다. 한 친구는 이렇게 말했습니다. "제 GitHub에는 18년치 작업이 있어요. 그걸 보고도 제가 유능한 프로그래머인지 판단할 수 없다면 저랑은 맞지 않는 곳이에요."
자주 간과되는 점으로, 취향도 잃게 됩니다. 압박 속에서 급히 짜낸 코드는 그 사람의 평소 일하는 방식을 반영하지 않으며, 당신의 엔지니어들이 그들과 함께 일하기 좋아할지를 판단할 수 있게 해주지도 않습니다.
구분과 존중에서 실패하고, 업무 관련성도 부분적으로 실패합니다. 과제형 면접은 ChatGPT로 속이기 매우 쉽고, 라이브 면접의 다른 문제들을 대부분 공유합니다. 다만 "스트레스 상황에서 면접을 못 본다"는 요소는 제거되죠. 하지만 지원자와의 근본적인 시간 비대칭을 만들어, 다시 한 번 최고의 사람들을 멀어지게 합니다.
이 방식은 훨씬 낫습니다. 아키텍처 면접은1 ChatGPT로 속이기 어렵습니다. 다만 업무 관련성에서 실패합니다(지원자의 코드를 실제로 보지 못합니다). 겉보기에는 취향에 대한 통찰을 주는 듯하지만, 실제로는 종종 "지원자가 문제 도메인을 얼마나 잘 아는가"를 측정할 뿐, "지원자가 설계 문제를 어떻게 사고하는가"를 보지 못하기 때문에 여기에 과도하게 가중치를 주지 않도록 주의해야 합니다.
외부 채용에서는 많이 보지 못했지만, 회사 내부 전배에서는 매우 흔합니다. 아키텍처 면접과 비슷한 트레이드오프를 갖지만, 보통 기술을 평가하려 하지 않고 주로 성향과 "핏"만 봅니다(즉, 구분에서 실패하고 업무 관련성도 부분 실패). 후보가 매우 강력한 추천을 받았고 자리에 경쟁이 별로 없는 환경, 혹은 정식 평가 없이도 그들의 역량을 높이 평가할 충분한 이유가 있을 때는 의미가 있다고 봅니다.
이건 흥미롭습니다. 저는 Oxide Computer Company에서만 봤습니다. 정말 꽤 마음에 듭니다. 프로세스는 다음과 같습니다.
이 방식은 거의 모든 기준을 매우 훌륭하게 충족합니다(존중 포함—이만큼의 글을 읽어 내려면 Oxide 엔지니어들의 시간도 엄청 듭니다. 즉, 시간이 대칭적입니다).
다만 시간 효율성에서 실패합니다. 제가 이 과정을 직접 겪지는 않았지만, 질문 라인업과 Oxide에 채용되는 사람들에 대한 제 이해로 볼 때, 서면 작업만 해도 지원 1건에 최소 5~15시간은 걸릴 것 같습니다. Oxide의 성격과 목표, 그리고 거기에 몰리는 지원자 수를 고려하면 이 트레이드오프를 받아들일 것 같고(실제로는, 이 정도 투입을 싫어하는 사람을 걸러내는 효과도 가치 있게 여길 겁니다), 대부분의 회사는 Oxide가 아니며 이만한 시간을 양쪽 모두에서 감당하기 어렵습니다.
Oxide 프로세스에서 시간을 과하게 희생하지 않고 아이디어만 가져오자면, "코드는 미리 작성하고 면접에서 함께 논의한다"를 유지하겠습니다. 이렇게 하면 과제형 면접의 장점—시간 압박 없음, 덜 스트레스 받는 환경—을 유지하면서, 회사와 지원자가 대칭적인 시간을 들이게 되어 뛰어난 엔지니어들이 공고를 대번에 무시할 가능성을 줄입니다. 그리고 코드를 함께 논의하면 감으로 대충 코딩해버린 사람을 걸러낼 수 있고(무엇을 했는지 설명을 못 합니다!), 나머지 사람들에게는 자신의 생각을 설명할 기회를 주어 업무 관련성과 취향을 모두 평가하는 데 도움이 됩니다.
지원자가 보여줄 만한 오픈 소스 작업물이 없다면 여전히 어느 정도 시간 비대칭이 남지만, 5~15시간에 비하면 훨씬 적고, 회사도 자사 엔지니어 시간을 반드시 투입해야 하므로 "벽 너머로 일만 던지는" 행태를 줄일 유인이 생겨 지원자를 존중하는 태도를 보이게 됩니다.
이것도 저는 단 한 번만 본 방식입니다. 면접관이 미리 평범한(그리 좋지 않은) 코드를 작성해오고, 지원자에게 어떻게 개선할지 묻는 형식입니다. 저는 이 포맷에서 결과가 좋았기에 편향이 있을 수 있지만, 정말 마음에 듭니다. 우리의 모든 기준을 만점에 가깝게 충족합니다.
제가 채용 매니저라면, 코드 리뷰 면접과 라이브로 논의하는 작업 샘플을 조합하되, 코드 리뷰에 우선권을 두고 작업 샘플은 완벽할 필요가 없다고 미리 안내하겠습니다.
프로그래밍은 근본적으로 협업입니다. 지원자가 리뷰(타인의 작업)와 저작(본인의 작업) 양쪽에서 협업하는 모습을 보면, 그들의 업무 방식에 대해 많은 것을 알 수 있고, 지원자에게도 당신이 SAT 점수 같은 단일 지표 이상의 것을 중시한다는 신호가 됩니다.
또한 지원자와 그들의 미래 매니저가 최소 한 번은 반드시 면담하도록 권합니다(이미 널리 행해지는 관행 같아 기쁩니다—야호!). "사람들은 일을 그만두는 게 아니라 상사를 그만둔다": 미리 만나보면 모두가 나중의 고통을 줄일 수 있습니다.
읽어주셔서 감사합니다! 이 글이 여러분의 채용 프로세스를 바꾸도록 영감을 주거나, 최소한 제가 틀렸다고 댓글로 알려줄 계기가 되길 바랍니다 ^^. 비공개로 의견을 주고 싶다면 이메일로 연락하실 수 있습니다.
