사자, 마녀, 그리고 리크루터의 뻔뻔함
(hauleth.dev)- 구직자가 두 회사의 채용 과정을 겪으며 역할 불일치와 피드백 비대칭이 후보자 시간을 어떻게 소모하는지 비판함
- Hop.NS는 “Senior Elixir Developer” 포지션으로 1주 trial contract를 진행했지만, 실제 과제는 TypeScript 브라우저 확장 유지보수와 UI 기능 추가였음
- trial week 초반에는 Slack, GitHub, 설계 템플릿 접근 권한 확보에 시간이 소모됐고, 약 10~12시간이 지나서야 확장을 로컬에서 실행할 수 있었음
- PerhapsMaybe는 5시간 이상 기술 인터뷰를 진행한 뒤 개별 피드백을 거절했지만, 일주일 뒤 후보자 경험 설문을 보내 후보자에게만 피드백을 요구함
- 회사가 긴 시간과 성의를 요구한다면 역할 설명의 정확성, 개인화된 탈락 사유, 후보자 존중도 함께 제공해야 함
Hop.NS: Elixir 포지션에서 브라우저 확장 과제로 바뀐 trial week
- 구직자는 LinkedIn에서 예전 동료가 일하는 Hop.NS의 채용 공고를 보고 지원함
- 회사명과 일부 세부사항은 법적 문제를 피하기 위해 바뀐 이름임
- 과거에는 1주짜리 take-home project를 요구했고, 그 시간에 대해서는 보수를 지급했던 회사였음
- 공고는 Senior Elixir Developer였고, CTO와의 통화에서도 Elixir 개발자 역할, 팀, 프로세스가 논의됨
- CTO는 1주 trial contract 동안 “채용되면 맡게 될 작업”을 수행하게 된다고 안내함
- 계약 서류는 문제없이 진행됐고, 월요일 09:00에 trial week가 시작됨
Day 1: 접근 권한 문제와 실제 과제 공개
- 첫날 임시 회사 이메일 자격 증명은 받았지만, Slack workspace에는 접속할 수 없었고 관리자에게 문의하라는 메시지만 나옴
- 연락 수단이 없어 LinkedIn으로 회사 내부 지인에게 메시지를 보내 접근 권한 요청을 부탁함
- 40시간 계약 중 2~3시간이 Slack 접근 문제로 소모됨
- 이후 GitHub 접근 권한도 추가 요청과 대기 끝에 받을 수 있었고, 저장소를 clone할 수 있게 됨
- 감독자가 남미에 있어 과제 설명 통화는 18:00에 잡혔고, 그전까지 Elixir 코드베이스를 살펴보며 작은 수정 PR을 열었음
- 저녁 통화에서 trial week 과제는 TypeScript 브라우저 확장 유지보수와 새 기능·UI 디자인 추가로 밝혀짐
- 구직자는 해당 영역 경험이 적다고 확인했지만, 담당자는 그 과제가 맞다고 답함
- 담당자는 “백엔드 작업은 이미 모두 끝났으니 걱정할 필요 없다”고 말함
- 구직자는 자신이 원한 백엔드/Elixir 업무가 이미 끝났고, 원하지 않는 프런트엔드 성격의 작업을 해야 하는 상황으로 받아들임
Day 2: 실행 환경 구성과 역할 불일치 확인
- 둘째 날에는 브라우저 확장을 실행하고 이해하기 위해 Google Chrome 설치가 필요했음
- 구직자는 평소 Safari와 Firefox를 선호해 Chrome 사용을 피하고 있었음
- 로컬 빌드와 실행 방법을 파악하는 데 몇 시간이 걸렸고, 추가 자격 증명과 접근 권한을 얻기 위해 다른 사람들과 계속 연락해야 했음
- 추천해 준 지인과의 대화에서 trial week 과제가 후보자의 전문 영역과 완전히 다를 수 있는지 물음
- 지인은 후보자를 comfort zone 밖에 두는 경우는 있지만, 백엔드 개발자에게 순수 프런트엔드 작업이 주어지면 문제가 생긴 것이라고 답함
- 자신이라면 같은 상황에서 바로 중단했을 것이라고도 말함
- 구직자는 추천해 준 두 사람에 대한 존중 때문에 과정을 계속하기로 함
- 채용 전용 Slack 채널에서 “채용되면 이 프로젝트를 계속 맡는지, 아니면 다른 일을 하는지” 물었고, 답변은 “항상 그렇지는 않다”였음
- 설계 템플릿을 받기 위해 다시 담당자를 추적해야 했고, trial week 40시간 중 10~12시간이 지난 뒤에야 브라우저 확장을 로컬에서 실행할 수 있었음
Day 3: 과제 범위 확대와 trial 중단
- 셋째 날에는 작업 방식과 필요한 일을 어느 정도 이해했지만, 브라우저 확장 디버깅 지식은 여전히 부족했음
- trial week 중간인 셋째 날 정오쯤 회사는 과제 범위를 추가로 확장함
- 구직자는 과제가 채용 과정에서 안내받은 내용과 전혀 맞지 않는다고 긴 메시지로 항의함
- 직무 설명에는 TypeScript와 브라우저 확장에 대한 내용이 없었음
- 본인은 “backend-and-ops” 성향의 엔지니어라고 여러 차례 강조함
- 이 과제는 자신의 시간과 회사의 시간을 모두 낭비한다고 봄
- 바로 중단하지 않은 유일한 이유는 자신을 추천한 지인들에 대한 존중이었다고 밝힘
- CTO는 “문화에 잘 맞는지” 확인하려 했다고 답했고, 회사가 잘못한 것이 없다고 느낀다며 글을 공개하지 말아 달라고 요청함
- Hop.NS는 고통스러웠던 약 20시간의 작업에 대해서는 비용을 지급함
- 3~4주 뒤 CTO는 LinkedIn으로 Staff Software Engineer 포지션에 관심이 있는지 물었고, 구직자는 여전히 bait-and-switch 전술을 쓰는지 되물음
PerhapsMaybe: 긴 인터뷰 뒤 피드백은 없고 설문은 요구함
- PerhapsMaybe에는 Software Engineer with Elixir 포지션이 열려 있었고, 회사에 아는 지인들이 있어 지원함
- 한 지인이 해당 포지션의 hiring manager로 보이는 VP of Infrastructure 앞에 지원서를 올려 줬지만, 과정은 빠르지 않았음
- 지원 정보는 2026년 5월 27일에 보냄
- 채용팀의 첫 연락은 2026년 6월 11일로, 2주 이상 뒤였음
- LinkedIn에서 VP에게 초대를 보낸 뒤에야 채용 담당자가 연락함
- VP와의 1시간 통화는 순조로웠고, 역할에 대한 관심이 더 커짐
- 이후 기술 인터뷰 일정 조율이 이어졌고, 전체 인터뷰는 5시간 30분짜리로 예정됨
PerhapsMaybe 인터뷰 구성과 탈락 통보
- 인터뷰는 하루에 진행됐고, 각 세션 사이에 30분과 2시간의 휴식이 있었음
- 구성은 세 부분이었음
- Systems Design 1시간: 동기식 결제 게이트웨이를 사용하는 비동기 결제 시스템 설계
- Coding Interview 1시간: cross product와 키패드 위 체스 말 이동 같은 LeetCode 유사 과제
- Technical Deep Dive 1시간: 과거 프로젝트인 Ultravisor의 기술 세부사항 설명
- 구직자는 코딩 인터뷰의 두 번째 과제에서 big-O 복잡도 분석 실수를 했지만, 전반적으로 해법은 괜찮았다고 느꼈음
- Technical Deep Dive에서는 본인은 괜찮게 느꼈지만, 상대가 감명받지 않았거나 다른 것을 기대한 것 같다는 직감을 받음
- 인터뷰 후 이틀째가 끝날 무렵 채용 담당자에게 업데이트를 물었고, 탈락 통보를 받음
- 탈락 이메일에는 “지원자가 많아 개별 피드백을 제공하지 않는다”는 문장이 포함됨
후보자 경험 설문이 만든 피드백 비대칭
- 탈락 일주일 뒤 PerhapsMaybe Hiring Team은 Candidate Experience Survey 이메일을 보냄
- 이메일은 채용 프로세스가 효율적이고 후보자 경험이 좋은지 확인하려 한다며, 최근 인터뷰 경험에 대한 솔직한 피드백과 개선점을 요청함
- 구직자는 회사가 약 5시간의 녹화와 자동 회의 노트를 갖고 있을 가능성이 있다고 봄
- 본인은 회의 노트에 AI를 사용하는 것이 금지됐다고 밝힘
- 회사는 3~4문장의 개인화된 탈락 이유는 제공하지 않으면서, 후보자에게는 프로세스 개선 피드백을 요구한다고 비판함
- 구직자는 자신이 후보자가 아니라 채용 프로세스를 평가하는 계약자처럼 취급됐다고 보고, 계약자 요율로 청구서를 보내기 위한 billing details를 요청함
채용 시장에 대한 비판과 예외적인 긍정 사례
- 구직자는 현재 채용 시장이 망가져 있다고 표현함
- 일부 recruiter는 지원 과정에서 LLM 사용을 비난한다고 언급함
- 지원서에는 “왜 XYZ에서 일하고 싶은가”, “XYZ에서 일하는 것 중 무엇이 가장 흥미로운가” 같은 질문이 자주 포함된다고 비판함
- 구직자는 회사의 제품을 회사에 되팔듯 설명하는 것이 자신의 일이 아니라고 봄
- 자신은 관심 있는 일을 하고 그 대가로 돈을 받기를 원한다고 밝힘
- 회사 제품에 진정으로 흥분할 수 있는 사람은 창업자뿐이며, IPO 이후에는 주주도 가치 상승만 원한다고 표현함
- 예외적으로 Fresha 지원 과정에서는 Christine Wong이 긍정적 사례였음
- 탈락 사유는 “coding agents 경험 부족”이었음
- Christine Wong은 개인화된 피드백을 직접 전달하기 위해 통화를 잡자고 요청함
- 구직자는 후보자에게 존중을 보이는 실제 사람을 보는 일이 좋았고, 그 경험에 감사한다고 밝힘
댓글과 토론
Lobste.rs 의견들
-
후보자를 안전지대 밖으로 밀어내는 방식이라는 말은, 원하는 사람을 뽑기 위한 핑계를 만들고 다른 요소는 무시하겠다는 뜻처럼 들림
백엔드 개발자에게 순수 프런트엔드 일을 시킨 뒤 “문화 적합성”을 보겠다는 건, 물고기에게 나무를 못 오른다고 탓하는 꼴임
팀의 채용과 해고를 노동자들이, 적어도 자기 팀에 대해서라도 통제하지 못하는 한 이런 장난은 계속될 것 같음 -
이 글의 작성자에게 크게 공감되지는 않았음
기업 환경에서는 접근 권한을 받거나 다른 시간대의 사람과 이야기하는 데 하루가 걸리는 일이 그리 충격적이지 않고, 이런 상황에 어떻게 반응하는지는 문화 적합성을 보는 좋은 신호가 됨
가장 급한 일이 미리 정해둔 역할 범위 밖에 있는 것도 놀랍지 않으며, 자기 범위를 벗어나 일할 수 있는 후보자가 특정 범위에만 머무는 사람보다 회사에는 더 가치 있음
물론 전문 분야 밖의 일을 시키면 진행이 느리고 결과도 나빠질 수밖에 없지만, 회사는 outright 거절보다는 그쪽을 선호할 가능성이 큼
채용 담당자가 면접 일정을 잡는 데 몇 주가 걸리거나, LinkedIn으로 부사장에게 연락했더니 절차가 빨라지는 것도 기업 환경에서는 이상하지 않음. 언제 부사장에게 연락해야 하는지 아는 것도 일의 일부임
후보자에게 피드백은 주지 않으면서 채용 담당자가 피드백을 요청했다면, 그 점이 가장 기억에 남았다고 말하는 것 자체가 좋은 피드백이 될 수 있음
가장 거슬렸던 건 맨 위의 취소선 처리된 “bitch” 표현이었음. 동료나 예비 동료를 그런 식으로 부르는 건 절대 괜찮지 않음. 의견 충돌은 가능하지만, 성별을 겨냥한 인신공격은 안 됨- 나를 존중하지 않는 사람들에게는 공감하지 않음
채용 공고는 순수 백엔드 업무를 설명했고, 내가 거의 백엔드와 시스템 운영만 해 왔다고도 말했음
그런데 순수 백엔드 일을 제안해 놓고 갑자기 내가 전혀 모르는 과제를 주면서, 최대 32시간 안에 “시스템 나머지와 맞는 디자인”의 동작하는 해법을 기대한다면 내 경험과 지식에 대한 무례로밖에 보이지 않음
백엔드 개발자로 10년 넘게 일했고 그중 7년가량은 관측 가능성과 성능을 다뤘으며, 프런트엔드를 비교적 많이 한 건 8년 전 기존 Vua 애플리케이션에 기능을 추가한 정도였음
이런 과제로 내 경험과 지식을 평가하려 한다면, 나를 원하지 않는다고 판단할 수밖에 없음. 차라리 정중하게 그렇게 말하지 않고, 무의미한 일을 강요해 고생시키는 건 모욕에 가깝다고 봄
채용 일정이 몇 주 걸리는 것도 내겐 놀라웠음. 그 회사의 시니어/프린시펄/스태프급 엔지니어가 2주 전에 해당 부사장에게 나를 보증했고, 그 부사장이 이를 확인했다는 것도 알고 있었기 때문임
피드백은 제공했고, 채용 담당자에게 채용 프로세스 컨설팅 비용을 청구할 수 있도록 송장 정보도 요청했음
다행히 피드백을 얻는 다른 방법도 있음. EU에 있으므로 GDPR 덕분에 내 채용 절차에 관한 모든 메모와 세부 정보를 요청할 수 있음 - 의견 충돌은 당연하지만 어떤 형태의 욕설이나 이름 붙이기도 해서는 안 됨
기업식 화법은 인생의 모든 큰 질문에서 정반대편에 있는 두 사람도 회사 목표를 향해 훌륭하게 함께 나아갈 수 있게 하려고 존재함
나도 비슷하게 읽었음. 친구들 사이의 분풀이 글이라는 건 알지만, 면접 단계에서 이런 태도가 조금이라도 보였다면 아마 면접을 거절했을 것 같음 - 읽으면서 비슷한 반응이었고, 기업 환경의 현실에 대한 위 설명에도 동의함
자신의 전문 범위 밖에서 일하려는 태도는 고용주에게 가치 있을 뿐 아니라, 자기 영역 안에만 머물겠다고 고집하면 알 수 없었을 경력과 학습 기회를 열어 줄 수도 있음
중요한 건 그 경계가 어디인지 소통해 기대치와 일정을 적절히 잡는 것이고, 그걸 할 수 있는지 자체가 면접에서 강한 신호가 됨
다만 균형은 필요함. 이미 커리어 방향이 매우 분명하고, 요구받는 프로젝트가 그 방향으로 데려가지 않는다면 시간을 다른 곳에 쓰는 편이 나을 수 있음
하지만 나와 고용주의 목표가 충돌한다고 해서 개인적으로 모욕으로 받아들이거나, 다리를 불태우는 위험을 감수하지는 않을 것 같음 - 회사의 미끼와 바꿔치기는 괜찮지 않지만, 이 글은 회사들보다 글쓴이에 대해 더 많은 걸 보여줌
이 글만 보고는 채용하지 않을 것 같고, 유치하고 프로답지 않게 느껴짐
- 나를 존중하지 않는 사람들에게는 공감하지 않음
-
최근 꽤 흥미로운 일을 겪었음. 어떤 회사 채용 담당자가 연락해 와서 이야기해 볼 생각이 있냐고 물었고, 내가 그 회사 제품을 매일 쓰고 있어서 수락했음
통화가 시작되자 채용 담당자가 “그래서 무엇을 찾고 계신가요?”라고 물었는데, 나는 아무것도 찾고 있지 않았음. 그쪽에서 접근했으니 내가 회사를 설득하는 게 아니라 회사가 나를 설득하려는 줄 알았음
그래도 흔한 말일 뿐이라 생각하고, 회사가 뭘 하는지 등을 한 시간쯤 이야기했음. 마지막에는 세 번의 기술 면접을 거쳐 제안으로 이어질 수 있는 절차를 계속할 의향이 있냐고 물었고, 안정적인 직장이 있는 비교적 유리한 위치라 흥미로울 것 같아 수락했음
채용 담당자는 통화 뒤 이메일을 보내겠다고 했고, 인사를 나눴음
그런데 거의 일주일 동안 이메일이 오지 않았음. 결국 내가 혹시 잊었냐고 이메일을 보냈고, 며칠 뒤 이번에는 절차를 진행하지 않기로 했다는 답을 받았음
지원조차 하지 않았는데 탈락 통보를 받은 셈이라 묘하게 상처가 됨
그런데 끝이 아니었음. 몇 주 뒤 큰 프로그래밍 콘퍼런스에 참석 중이었는데, 그 채용 담당자가 자신들도 거기 있다며 저녁을 함께하고 혹시 면접 절차를 다시 시작할 생각이 있냐고 이메일을 보냄
그쪽이 비용을 낸다기에 저녁에는 갔고, 회사 엔지니어 몇 명과 즐겁게 이야기했음. 하지만 내가 절차를 멈춘 것도 아닌데 왜 재시작이 선택지가 되는지, 왜 그게 내 책임처럼 되는지 이상했음 -
이런 상호작용에 대비할 수 있도록 널리 읽히는 기업 IT 환경 안내서 같은 페이지가 필요하다고 느낌
그곳에서 벌어지는 일을 옹호하려는 건 아니지만, 많은 사람이 현실을 잘 모름
내부든 외부든 지연은 생김. 접근 권한을 얻는 과정에서 하루를 잃는 건 정상적이고 예상 가능한 일임
절차는 늦어지고, 개인의 성공과 실패가 아니라 전체 지표를 보는 프로세스 안의 작은 톱니바퀴가 됨
많은 곳은 피드백을 일괄적으로 주지 않는 정책을 둠. 잠재 손실은 소송이고, 잠재 이익은 없기 때문임
소통은 종종 나쁘고, 직무 테스트가 바뀌거나 누락되는 일도 생김
이런 안내서는 기대치를 맞춰 주고, 이런 일상을 감당하고 싶지 않은 사람을 걸러내는 역할도 할 수 있음- 지연이 생기는 건 맞지만, 내게는 과제를 끝내야 하는 고정된 시간이 있었음
그 안에 끝내려면 절차 밖의 사람들과 제3자 소통 채널을 써서 접근 권한을 받아내야 했음
일반 업무에서는 기다릴 수 있으니 지연이 정상적일 수 있지만, 채용 절차는 내 일상 업무에 영향을 주면 안 됨. 이건 큰 차이임
피드백을 주지 않는 정책도, EU에 있고 GDPR 적용을 받기 때문에 내 모든 세부 정보와 내부 메모를 요청할 수 있음
결국 그들이 얻는 건 전문성 없어 보인다는 인상과, 이 전체 절차가 정당한 채용이 아니라 채용 프로세스 컨설팅처럼 느껴지게 만드는 것뿐임
기대치를 맞추고 사람을 걸러내는 건 괜찮을 수 있지만, 내가 시간이 더 필요하다고 말하면 그들에게도 같은 기준이 적용될지 매우 의심스러움. 그래서 불공정한 우위가 생김
돌이켜보면 아무것도 하지 말고, 접근 권한을 달라고 재촉하지도 말고, 주말까지 그들의 기계가 돌아가기만 기다린 뒤 수당만 받았어야 했을지도 모름. 그랬으면 신경을 덜 썼을 것 같음
- 지연이 생기는 건 맞지만, 내게는 과제를 끝내야 하는 고정된 시간이 있었음