Kagi Search의 과제형 면접에서 탈락한 경험

(bloggeroo.dev)

4P by GN⁺ 7일전 | ★ favorite | 댓글 1개

소프트웨어 개발자 면접에서 제출받는 "take-home assignment"의 비효율성과 지원자 시간 낭비 문제를 강조함
Kagi Search 지원 과정에서 과도하게 광범위하고 모호한 과제 요구사항을 경험함
제안한 구체적 실행계획에 대해 매니저의 명확한 피드백 부재 및 비효율적 소통 경험함
심혈을 기울여 개발한 프로젝트 제출 후, 명확한 사유 없는 탈락과 기준 변경 등 불합리함을 느꼈음
보다 나은 채용 프로세스에 대한 대안(예: 실시간 코드 리뷰)과, 과제형 면접 과도 요구에 대한 문제의식 공유함

서문

Take-home assignment란 소프트웨어 개발자 면접에서 지원자에게 문제를 출제하고, 이를 코드로 구현해 제출하게 하는 평가 방식임
본 포스트는 평판이 좋은 회사라고 생각했던 Kagi Search에 지원하여 실제로 받은 과제와 경험을 통해, 이 방식의 비합리성과 지원자 시간 낭비 문제를 지적하고자 함

카기 서치에 입사지원

Kagi Search의 백엔드 개발자 포지션에 이력서를 제출했음
해당 역할의 요구사항은 다음과 같음
- 백엔드 시스템 구축 경험
- Go 언어 활용 능력
- 대규모 백엔드 시스템 확장, 유지 경험
- SRE 등 팀원과의 협업 능력
- Docker 등 컨테이너 기술 이해

면접 과제 안내 및 요구사항

서류 통과 후 take-home assignment 안내 메일을 받았음
과제 주제: "최소한의 터미널 영감 이메일 클라이언트 구현"
- 터미널 또는 웹앱 형태 중 선택
- 기본 이메일 보기/보내기 기능
- 가짜 또는 실제 이메일 백엔드(IMAP/POP 등) 자유 선택
- plaintext 메시지 처리만 필수, rich text 불필요
- 프로젝트 제출: 깃허브 저장소, 배포본 제공, 설치 안내 문서 포함
명확한 가이드 부족 및 프로젝트 규모가 상당히 큼
평판 때문이라도 과제 수행을 결정하게 됨

매니저와의 커뮤니케이션

명확한 과제 범위 및 추가 기능 관련 문의 시, “무엇을 추가할지는 지원자 자유”라는 모호한 답변만 받음
과제에 시간과 노력을 투자하기 전, 구체적인 실행계획(Proposl) 을 공유하고 이에 대한 회신을 요청했으나 특별한 피드백 없이 진행

과제 제안 및 계획

실행 계획:
- Go 기반 웹앱
- AWS ECS Fargate 통한 배포 및 SSL 적용
- 이메일 발신자 서비스(Postmark) 연동
- 로그인/인증 기능 추가
- 이메일 송수신 및 UI 표시
기술 선정 근거:
- 백엔드 역할과 관련된 다양한 기술 활용
- Infra-as-Code 도구 활용 통한 실질적 시스템 구축
- 단순한 API 연동을 넘어 실제 서비스에 가까운 기능 구현
주요 구현 요소:
- Pocketbase(backend/DB), TEMPL(템플릿), Pulumi(IaC), Postmark(이메일 서비스)
- 페이징, 로그인 등 구현
- Stretch Goal: 데이터 백업과 복구 등 안정성
결론: 미리 사전에 충분한 설명과 근거를 제시했으며, 이에 대한 명확한 검토와 회신을 기대했음

매니저의 회신 및 소통 문제

구체적 검토 없이 “흥미로운 제안”이라는 짧은 답변만 받음
제안의 적합성이나 개선 요구 등 피드백 전무
지원자 입장에서는 시간 투자 및 노력에 대한 존중 부재로 느껴짐

프로젝트 과제 수행

주어진 요구와 제안 사항을 모두 구현했고 일주일 풀타임을 투입함
프로젝트 데모 영상 및 깃허브 레포지토리, 상세한 문서까지 제출하였음

탈락 통보와 그에 대한 피드백

자동화된 탈락 이메일 수신 후, 피드백 요청 시 받은 답변:
- “더 강력한 지원자 제출물이 있었음”, “채용 경쟁이 치열함”
문제점
1. 단순한 솔루션 선호라면 애초에 안내 가능
2. 제안이 부족했다면 그 시점에 피드백 가능
3. 탈락 이후에도 공고는 여전히 게재 중, 단순 경쟁 아닌 과도한 시간 소모 요구라고 판단됨
4. 프로젝트 제출 후 요구사항 더욱 강화, 제출 솔루션이 기준을 높인 셈

결론 및 문제의식

이 같은 방식은 많은 구직자에게 불합리, 실질적 생계 위협까지 동반
과도한 무급 과제 요구에 대해 거절하거나 문제를 제기할 필요성 강조
프로젝트성 과제를 대체할 실시간 코드 리뷰 등 더 나은 채용 프로세스 가능
- 실제 개발 문제 해결 능력을 비동기/동기 코드 리뷰 등으로 들여다 볼 수 있음
- Leetcode 스타일 문제 풀이와 현업 요구간 괴리 지적
구직자 소진과 부당한 평가 문화 개선을 촉구함

더 나은 채용 절차를 위한 제안

실시간 코드 리뷰 방식 등 개발자 역량을 더 의미 있게 평가하는 대안 제시
타이머 기반 알고리듬 퍼즐 풀기 중심보다는, 실제 역량 및 문제해결능력 중심으로 변화 필요성을 역설함

▲

GN⁺ 7일전 [-]

Hacker News 의견

솔직한 채용자 입장에서 의견을 남김. 개인적으로 takehome 과제를 싫어함. 이런 과제는 모두의 시간을 낭비하게 만듦. 채용의 마지막 단계라면 이해 가능하나, 지원자 거르기 용도로 쓰는 건 비효율적임.
1. 너무 많은 질문이 오감. 모호함 속에서 판단력을 사용해 해결하는 것이 과제의 일부임. 주어진 조건대로라면 하루이틀 투자해 간단한 로컬 프로젝트 수준이면 충분했을 것임.
2. 제안서 작성과 공유가 너무 과도했음. 지원자는 철저함을 보여주고 싶어한 것 같지만, 실상 회사 입장에서는 비효율적이고 시간이 낭비된다고 생각할 수 있음.
3. 완성된 결과물은 기능적이긴 했으나 인프라와 마감에 너무 공 들였음. 불합격 시엔 결국 시간 낭비가 되었음.
4. 터미널 영감을 받은 이메일 클라이언트라는 요구사항이 있었던 것 같은데, 결과물에서 그 방향성을 못 찾았음.
  지원자의 능력과 일에 대한 열정을 인정함. 조금 다른 시선으로 의견 주고 싶었음.
- 블로그 작성자의 태도가 조금 거슬린다는 느낌을 받음. 글만 봐도 함께 일하기 어렵고, 자율적으로 결정을 내리기 힘들며, 명쾌한 가이드라인을 필요로 하는 인상임. 대기업에는 맞지만 스타트업과는 안 맞음.
  "터미널 영감의 이메일 클라이언트 개발해 고객들 알파 테스트"가 초기 스타트업 엔지니어에게는 타당한 요청임. 사양이 더 있더라도 많은 부분이 엔지니어 판단에 달려있음. 지원자는 확실성을 너무 원함.
  Kagi가 과제 완료 후 어떤 피드백을 줄 건지 미리 궁금해 하는 건 좋은 신호가 아님. 확정적인 답변을 줄 수 없는 상황임. 아마도 그들은 수백, 수천 건의 지원서를 평가 중일 것임.
- 작가는 일 잘했지만, 암묵적으로 "너무 노력하지 말 것"이란 조건에서 실패했음.
  만약 요구사항 명확화가 필요 없었다면, 차라리 "1~10 사이 숫자 맞추기"를 시켜 잘못 고른 이들을 탈락시키는 셈임.
  과제에 공 들이고 좋은 마감을 한다고 탈락시키는 사례엔 동의 못함.
  이런 모호한 과제는 사실상 "컬쳐 핏" 선별의 또 다른 방법일 뿐임.
- 내 생각에 지원자는 자신의 아이디어를 검증하는 접근이 요즘 엔지니어링 방식과 닮아 있음. 건강한 팀은 기능 설계서를 영어로 설명해 승인받고 진행함.
  "코드 먼저, 피드백은 나중" 문화는 커리어상 가장 해로운 경험이었음. 이 지원자는 현대적인 소프트웨어 관행을 따랐음. (나는 1000명 넘는 엔지니어를 둔 회사의 채용 담당자임)
- 채용자 입장에서 마음에 드는 takehome 과제는 30분 내 완성 가능, 평가 기준 명확, 다양한 접근과 트레이드오프 고민 포함 등임.
  나도 지난 구직 때 광범위한 takehome 과제에서 어떤 부분이 평가 기준인지 몰라 탈락했음. 이 경험 이후 이런 과제에 심한 거부감이 생겼음.
- 제안서가 너무 거대해진 게 탈락 이유라 생각함. 지침에 제안서 요청 없었고, 디테일하게 제출하면 오히려 "자율적 추진력 부족"으로 해석될 수 있음. 이렇게 되면 코드 퀄리티는 더 이상 무의미해짐.
  회사는 시간 낭비하게 두지 말고 그 시점에서 과제를 끝내주는 게 낫다고 생각함.
- 요즘 업계에서 요구사항 파악 능력이 부족해 독심술 능력으로 개발자를 거르는 현실이 유감임.
- 지원자가 마감일을 지키지 못한 점도 문제임. 특별한 사정 설명 없는 지연은 이미 탈락임. 마감 내 적절한 솔루션 설계가 과제 목적이었음.
- 4번 터미널 관련 언급에 대해, 작가가 공유한 전체 버전에는 해당 부분 설명 있음.
- 이런 논의는 결과를 놓고 보면 다 쉽게 할 수 있음. 반대 전략(요구 미확인, 최소 요건만 충족)이라도 마찬가지 결과가 나왔을 것임. 이런 상황에서 언제나 "더 적극적으로 요구 명확화가 필요했다"는 의견이 반대 방향으로도 나올 수 있음.
코드를 보고, 그리고 데모 영상을 봤을 때 한 주 동안 웹앱 두 페이지 짜는 데에 시간이 꽤 걸렸구나라는 인상을 받았음.
가장 기본적인 이메일 기능(메일 열기 등)도 없고, 백엔드 엔지니어 자리 지원이면서 실제론 postmark와 turso 같은 외부 제품을 이용했으며, 기본 기능(플레인텍스트 포매팅, 보기, 폴더 등) 부재가 보임.
관리자 페이지, 로그인 같은 부가 기능이 있긴 한데, 메일 헤더 맵 등 최소한의 데이터 구조도 빠져있었음.
좋은 엔지니어일 수는 있겠으나 해당 포지션엔 부적합하다고 판단함.
takehome 제안서도 너무 이례적이라고 느꼈음.
최초 공고를 다시 읽어보니 "최소한의 터미널 영감 이메일 클라이언트"와 aerc, mutt, himalaya 등 레퍼런스가 명시되어 있었음. 이는 명백한 요구사항 해석 실패임.
- "요구사항 해석 실패"라는 말에, 도대체 어떤 요구사항을 못 맞췄는지 궁금함.
  터미널 혹은 웹앱 형태의 이메일 클라이언트, 기본 기능 구현이 요구였는데 이를 충족했다고 생각함.
  터미널 기반 툴에서 영감을 받으라는 부분은 주관적임. 백엔드 포지션이라면 UI에 신경 쓰는 것이 비효율일 수도 있다고 생각함.
- 지원자가 시간 투자했는데 거절 메일 한 통만 받는 건 속상한 일임.
  피드백이라도 받을 수 있으면 성장에 도움이 될텐데 그조차 현실적으로 어려울 때가 많음.
  그래서 takehome 과제에 대한 회의감이 듦. 지원자와 채용자 모두 서로 시간에 대한 존중이 필요함.
- "Email client can either be in the terminal (i.e. a TUI) or a web app"이라는 문구가 존재함.
takehome 평가는 유의미하지만 반드시 시간 제한이 있어야 함.
2~3시간이면 충분히 지원자 평가할 수 있음. 시간 제한이 있었다면 지원자도 그 내에서 알맞은 해결책 제시가 가능했고, 회사가 원하는 바도 분명했을 것임.
또한 회사가 ‘어떤 답안이든 OK’인지, ‘최고의 답안을 희망’하는지 명확히 안내가 필요함.
takehome의 의도가 테스트 통과냐, 미션 충족률이냐, 코드 품질이냐 등 종류마다 달라서 지원자가 헷갈릴 수 있음.
- 채용 담당 관점에선 Kagi의 과제가 너무 방대하고 지원자 시간에 대한 예의가 없다고 생각함.
  오히려 시간이 없는, 바쁜 사람들을 걸러낼 위험이 큼.
  우리 회사는 그냥 간단한 ETL 문제를 내고, 4시간 제한을 둠.
  다 풀지 못해도 괜찮게 유도하고, follow-up에는 코드 리뷰 및 질문 시간을 가짐.
  진짜 역량은 이 후속 미팅에서 파악할 수 있음.
- 지원자들이 실제 투입 시간보다 훨씬 더 투자할 수도 있는데, 그 점을 채용 담당이 어떻게 알 수 있는지 의문임.
  공평한 시간 단위가 지켜지는 현장 과제와 달리 takehome은 각기 다른 시간 분배로 인해 손해를 볼 수 있음.
  이럴 바엔 1시간 현장 코딩이 더 나음. 지원자와 면접관이 같은 시간을 투자해야 서로 시간의 가치를 존중할 수 있음.
- 라이브 리뷰가 라이브 코딩보다 훨씬 낫다고 생각함. 만약 라이브 코딩을 한다면, 내 랩탑으로 45분 멀리서 작업하고 돌아와 리뷰하는 방식이 낫다고 봄.
회사 답변이 불친절하고 도움도 안 된 건 사실이지만 요구사항에 '터미널 영감'이 명확히 명시되어 있었음.
데모 영상에선 일반적인 웹앱만 보여짐. 명시적으로 aerc, mutt, himalaya 등 기존 터미널 이메일 클라이언트에서 영감을 받으라고 했음.
내가 뭔가 놓친 게 있는지 궁금함.
- 거절 메일에서 명확하게 이유를 설명해줬다면 더 좋았겠지만, 애초에 과제 설계에서 터미널 클라이언트 레퍼런스가 직접적으로 요구됐음.
  터미널 클라이언트 특유 UX가 아직 '정답'이 없는 분야라, 오히려 그 지점을 평가 기준으로 잡았을 가능성이 큼.
- Go 언어 중심임을 보았을 때, CLI 만드는 데 20줄도 안 걸리는데 굳이 웹 GUI 개발에 몰두했던 선택이 의문임.
- "Email client can either be in the terminal (i.e. a TUI) or a web app"이라는 안내가 있음.
최근 면접에서 유사한 경험을 겪었음. 과제 프로젝트를 매우 잘 제출했지만 프로젝트에 대한 대화 없이 바로 탈락 통보만 받았음.
과제 요청을 했다면 반드시 follow-up 미팅을 거쳐야 한다고 믿음.
이미 Kagi를 유료로 써왔지만, 이번 일로 계정 탈퇴를 고려하고 있음.
후보자에게 대화를 할 여유조차 없다면 애초에 과제 자체를 요구하지 말아야 함.
- takehome 과제는 지원자뿐 아니라 평가하는 면접관에게도 상당한 노력이 필요함.
  리뷰까지 하고 나면 피드백을 받을 권리가 있다고 생각함.
  하지만 현실적으로 수십 명의 뛰어난 지원 중 한 명만 뽑다 보면, 불합격이 곧 "실력이 부족하다"는 의미는 아님.
  법적으로도 '왜 A를 뽑고 B를 탈락시켰나?'의 공식 답변은 흠집 잡기밖에 없게 되는 게 현실임.
- 회사가 어떻게 평가할지 명확한 기준을 공개했거나, 피드백을 줬다면 더 나았음. 실패 피드백 없는 시간 낭비는 용납할 수 없다고 봄.
  여러 회사들은 이 점을 잘 처리함.
- 과연 '뛰어난 솔루션'이 맞았는지 의문임. 최소한의 터미널 영감 이메일 클라이언트라는 요구와 관련 레퍼런스를 완전히 무시한 것 같음.
  이런 요구사항 오해가 클 경우 논의 자체가 생략될 수 있음.
이 사례는 과제 본문 속 숨은 의도를 잘못 읽은 전형적인 케이스임.
회사는 자율적이고 스스로 목표를 세울 수 있는 사람을 원했음.
모호함은 답변을 다각도로 탐구해 풀어내는 지원자의 역량을 보기 위함임.
- 그 과제는 최대한 단순하고 기발하면서 기능 동작하는 솔루션을 낼 수 있는 사람을 위한 것이었음.
  프로토타입 위주의 회사를 위한 특성에 안 맞는 사람도 있기 때문에, 어떤 후보는 10분 생각해서 60분 내 최대치를 만들어냈을 것임.
- R&D 프로젝트와 '최소화'만 강조했을 경우, 도대체 프로토타입인지, 사용자 대상인지, UX를 신경써야 하는지 등 요구 사항이 모호해 평가자가 뭘 중시하는지 맞추는 게임일 뿐임.
- 이런 "스스로 해석하라"는 과제에선 요구사항 명확화나 추가 질문을 하지 않은 사람이 탈락할 수 있음.
  하지만 개발자에겐 이런 질문 능력이 매우 중요한 덕목임. 그래서 채용 방식에 대해 더 기대하고 실망할 수밖에 없음.
- "misreading the subtext"는 요구 자체에 나와있었다고 생각함.
- 교육 현장에서 '이해 못 한다'고 학생만 탓하는 건 너무 편한 결론임.
  정작 애매한 설명 때문이다.
  훌륭한 교사는 최대한 많은 이들이 이해하게 해줌. 혼란스러운 학생이 많다면, 출제자가 문제임.
  대학생들은 불가의 선승처럼 코안을 풀 일 없어야 함.
글쓴이가 직접 글을 올렸기에 Kagi에서 일한 경험을 바탕으로 맥락을 설명해주고 싶음.
예전엔 Vlad가 직접 지원자를 평가했고 과제도 이런 식이었음.
회사가 커지면서 이제 다른 이들이 평가하는 듯함.
Vlad는 HN 스타일의 성향이 있어 "쿨하다"라고 느끼는 지원자와 일하고 싶어함.
예를 들어, 디자인 문서를 길게 써서 "Galactor를 사용할 거며 프로젝트는 플롭-레디다."라고 하면 완전히 반대 효과임.
"터미널 영감"이라는 요구엔 모든 키보드 단축키 등 실제로 터미널 앱이 구현된 디테일을 기대하는 경향임.
이런 기준이 좋은 필터인지는 논란의 여지 있지만, 만약 그 맥락을 이해하고 통과할 역량이 있다면 과제가 쉽게 보일 것임.
Kagi가 이런 맥락을 더 잘 소통했으면 좋겠음. 시간 낭비된 건 아쉽지만, 성향에 맞는 회사를 찾길 바람.
- 많은 회사들이 자기와 비슷한 사고방식을 찾고자 함.
  다양성 없는 팀은 모두가 같은 벽에 부딪쳐 정체될 수 있음.
  이 현상은 스타트업에서 특히 흔하고, 9/10이 실패하는 이유와도 연관 있다고 생각함.
- Vlad가 "쿨한 사람"을 찾기 위해 너무 많은 사람의 시간을 낭비한다는 점이 문제라고 느껴짐.
  명확한 기준 없이 채점하는 과제는 불공정하다고 생각함.
  결국 "내 머릿속 답"을 맞추라는 암시적 과제와 다름없음.
  사람에 대한 배려가 부족하다는 인상을 받음.
- "나는 정말 이런 부분을 미리 알았어야 했나?"라는 의문이 있음.
  이런 문화라면 누구나 언더커버처럼 조사해 알아내야 했었는지 알 수 없음.
  나와 같은 '쿨하지 않은' 지원자도 명확한 신호를 받고 빠르게 다른 회사를 알아볼 수 있으면 더 나을 것임.
코드를 직접 검토해본 결과, 첫 파일에서부터 목적성 없이 샘플 코드만 베낀 듯한 주석과, 불일치하는 설명, 주의력 부족이 느껴지는 표현을 확인했음.
이런 세부 사항 미비로 인해 리뷰를 그만둘 것임.
- 앱을 내 도메인에 배포했고 성능상 문제없었음. 인증 및 인프라 등 백엔드 특성도 잘 구현함. 그런데 코드 주석에 더 신경을 써야 한다는 지적엔 동의 못함.
- 이 사례에서 핵심 문제는 불합격 자체가 아니라, 명확한 가이드 없고 피드백조차 제공하지 않는 채용 방식이 지원자 시간에 전혀 예의가 없었다는 점임.
DuckDuckGo에서도 유사한 경험이 있었지만 모든 지원 단계에서 소정의 보상을 받았음.
간단한 디자인 제안서부터 구현 과제까지, 제한 시간을 명확히 두고 진행함.
결과적으로 합격하지 못했고, 명확한 이유는 알려주지 않았음.
지원자가 너무 많았던 것 같긴 하나, 이런 경험이 오랜 기간 정서적으로 크게 남았음. OP의 심정에 공감함.
엔지니어링 면접관 입장에서 논함. leetcode도 takehome도 모두 시간이 많이 들고 정보량이 부족함.
하지만 내가 채용담당이어도 글쓴이를 불합격시켰을 것 같음.
스타트업은 신속하고 실용적으로 일하는 인재를 원함.
과거 동료 중 주변 의견 수집 후 며칠씩 혼자 몰입했다가, 요구사항이 이미 바뀌어버리는 경험을 했고 모두에게 좋지 않았음.

답변달기