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

 (bloggeroo.dev)
4P by GN⁺ | ★ favorite | 댓글 1개
  • Kagi Search 백엔드 채용 과정에서 한 개발자가 터미널 느낌의 이메일 클라이언트를 일주일가량 풀타임으로 구현했지만, 제출 후 후속 인터뷰 없이 탈락함
  • 과제는 TUI 또는 웹앱, 기본 이메일 조회·발송, 가짜 백엔드 또는 IMAP/POP/JMAP 선택 등으로 열려 있어 구현 범위와 평가 기준을 지원자가 직접 판단해야 했음
  • 지원자는 Go 웹앱, AWS ECS Fargate, SSL, Postmark, 로그인, Pulumi, Pocketbase, TEMPL 등을 포함한 상세 계획을 미리 보냈지만, Kagi 측은 구체적인 합격 기준을 알려주지 않음
  • 탈락 후 요청한 피드백에는 “더 단순하고 강한 제출물”이 있었다는 답만 돌아왔고, 이 단계에서는 보통 개별 피드백을 제공하지 않는다고 안내됨
  • 이 경험은 무급 과제형 면접과 시간 제한 코딩 퍼즐이 실제 엔지니어링 역량보다 지원자의 시간과 생활 여건을 더 크게 시험할 수 있음을 보여줌

지원과 과제 수령

  • 지원자는 Kagi Search의 백엔드 역할에 이력서를 보냈고, 역할 요약에는 다음 역량이 포함돼 있었음
    • 백엔드 시스템 구축 경험
    • Go 숙련도
    • 백엔드 시스템 확장·유지보수 이해
    • SRE 및 팀원과의 협업 능력
    • Docker 같은 컨테이너화 기술 이해
  • 이후 Kagi로부터 다음 단계로 Kagi Developer Assessment를 완료해 달라는 이메일을 받음
    • 과제 URL은 HackMD로 전달됨
    • 완료 후 연락하면 검토하고, 통과 시 후속 인터뷰에서 접근 방식과 솔루션을 논의하겠다는 내용이 포함됨

과제 요구사항과 열린 평가 기준

  • 과제 목표는 “최소한의 터미널 느낌 이메일 클라이언트”를 만드는 것이었음
  • 구현 조건은 비교적 넓게 열려 있었음
    • 이메일 클라이언트는 터미널 TUI 또는 웹앱으로 구현 가능
    • 기본 이메일 조회와 발송 기능 필요
    • 가짜 백엔드(DB, 인메모리 등) 또는 실제 IMAP/POP/JMAP 백엔드 사용 가능
    • 리치 텍스트 메시지는 제외하고 일반 텍스트만 처리하면 됨
  • 평가 대상은 코딩 능력뿐 아니라 Kagi Labs 같은 R&D 프로젝트에 필요한 모호함과 열린 문제 처리 능력까지 포함한다고 안내됨
  • 산출물 조건은 다음과 같았음
    • 개발자로서의 역량을 보여주는 방식으로 구현
    • 완료된 프로젝트를 GitHub 저장소에 올리고, 쉽게 테스트할 수 있도록 어딘가에 배포
    • README에 설정 방법 작성

채용 담당자와의 커뮤니케이션

  • 지원자는 요구사항이 너무 넓다고 보고 채용 담당자에게 질문을 보냄
  • 담당자는 후보자가 많으며, 어떤 후보자는 기본만 구현하고 어떤 후보자는 추가 기능, 훌륭한 문서화, 의사결정 설명, 데모 배포, 향후 계획까지 제공한다고 답함
  • 어떤 추가 기능이 높게 평가되는지 묻자, 담당자는 “그 자체가 평가의 일부”라며 후보자가 떠올리는 추가 기능을 보겠다고 답함
  • 지원자는 실제 코딩 전에 전체 산출물의 구현 계획을 자세히 작성해 보내기로 함
    • 제안이 받아들여지면 전화 인터뷰나 채용 제안에 가까워질 수 있다고 기대함
    • 이후 결과를 보며, 사전에 조건을 맞추려 한 노력이 채용 담당자에게 큰 의미가 없었다고 판단함

지원자가 제안한 구현

  • 제안의 중심은 Go 웹앱 기반 이메일 클라이언트였음
    • AWS에 배포
    • ECS Fargate 사용
    • SSL/HTTPS 적용
    • 이메일 발송 제공자와 통합
    • 로그인 화면을 통한 인증
    • 폼 기반 이메일 발송
    • UI에서 수신 이메일 표시
  • 제안서에는 산출일을 3월 30일 일요일 EOD로 잡았고, 최초 이메일 이후 2주 시점보다 영업일 기준 이틀 늦은 일정이라고 적음
  • 기술 선택은 다음과 같았음
    • Go 백엔드: Pocketbase와 TEMPL 사용
    • 인프라 코드: Pulumi 사용, TypeScript SDK 선택
    • 이메일 서비스 제공자: Postmark 사용
    • UI: 발신·수신 이메일 페이지네이션, 로그인 화면, 데모용 계정 2개 제공
  • 선택 이유는 역할과 평가 범위를 넓게 보여주려는 쪽에 가까웠음
    • 백엔드 역할이지만 웹 프런트엔드 추가가 웹 기술 폭을 보여줄 수 있음
    • 데이터베이스는 백엔드 역할과 관련 있음
    • AWS와 인프라 코드 배포는 IaC, Docker, 네트워킹, 복원력 논의와 연결됨
    • Postmark 같은 이메일 서비스는 IMAP/POP 통합 복잡도를 줄이면서 기능을 유지함
  • 지원자는 “완성하면 Kagi에서 어떤 반응을 기대할 수 있는지”를 물었지만, 답장은 “매우 흥미롭고 제출을 기대한다”는 수준에 머묾

제출물과 탈락

  • 지원자는 제안한 내용을 모두 구현했고, 전체 작업에 일주일 풀타임이 걸렸다고 밝힘
  • 웹 애플리케이션 데모는 YouTube에 올렸고, 코드는 문서와 함께 GitHub에 공개함
  • 자동 탈락 메일을 받은 뒤 피드백을 요청하자, Kagi 측은 다음과 같이 답함
    • 이 단계에서는 보통 피드백을 제공하지 않음
    • 더 단순하고 강한 제출물이 있어 해당 후보들과 계속 진행하기로 함
    • 각 포지션에 많은 관심과 지원이 있어 선택 과정이 매우 경쟁적임
    • 향후 포지션을 계속 확인하고 다시 지원해 달라고 함

탈락 이후 남은 의문

  • 지원자는 “더 단순한 솔루션”을 원했다면 3월 18일 제안서를 보냈을 때 말할 수 있었다고 봄
  • 솔루션이 역할에 맞지 않았다면, 마찬가지로 3월 18일 제안서 단계에서 판단할 수 있었다고 여김
  • 5월 13일 기준 탈락 후 한 달 반이 지났는데도 채용 공고가 여전히 올라와 있었다고 적음
    • 회사가 같은 공고로 여러 역할을 채울 수 있다는 점은 인정함
    • 다만 “승자 자리가 이미 찬 경쟁”처럼 보기는 어렵다고 판단함
  • 원래 과제 지침에서는 데모 배포가 있으면 좋지만 필수는 아니었는데, 제출 이후 지침이 배포를 엄격한 요구사항으로 바뀌었다고 적음

더 나은 선발 방식에 대한 제안

  • 지원자는 무급 과제가 구직자, 특히 실직 상태에서 저축이 줄어드는 사람들에게 큰 부담이라고 비판함
  • LeetCode식 인터뷰에도 부정적임
    • 최근 Clojure 기반 역할에서 “coin change” 문제를 풀었고, 50분 안에 테스트 절반 정도는 통과했지만 backtracking 부분을 구현할 시간이 부족했다고 적음
  • 대안으로 라이브 코드 리뷰를 제안함
    • 비동기 또는 동기 방식 모두 가능하다고 봄
    • 실제 소프트웨어 프로젝트의 문제와 주제를 말로 풀어갈 수 있음
    • 경험 많은 소프트웨어 엔지니어의 지식을 더 잘 드러낼 수 있음
  • 라이브 코딩 자체를 완전히 반대하지는 않지만, 50분 안에 knapsack을 푸는 능력은 일상적인 엔지니어 업무와 거리가 멀다고 봄
  • 절박한 상황이 아니라면 이런 종류의 무급 작업을 요구하는 역할을 거절하라고 권함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 채용자 관점에서 보면, 과제형 전형은 이런 이유로 싫어함. 모두의 시간을 낭비하고, 채용 직전 마지막 단계로는 괜찮지만 필터로 쓰기엔 부적절함

    1. 질문이 너무 많았고, 과제의 일부는 모호함 속에서 판단하는 능력을 보는 것이었음
    2. 제안서를 작성해 공유한 건 과해 보였고, 회사 입장에선 수백~수만 명 지원자를 처리해야 하니 장황하게 시간을 쓰게 만드는 신호로 보였을 수 있음
    3. 결과물은 동작하지만 인프라와 마감이 과했으며, 탈락하면 본인 시간만 크게 낭비됨
    4. 요구사항의 terminal-inspired가 결과물에서 거의 보이지 않았음
      그래도 역량과 진심은 분명해 보이고, 다른 관점에서 악마의 변호인을 해본 것임
    • 블로그 글의 상호작용 태도도 어긋나 보임. 글만 봐도 함께 일하기 까다롭고, 매우 명확한 지침과 안내가 필요하며, 스스로 결정하는 데 어려움을 겪는 사람처럼 느껴짐
      “고객 몇 명에게 알파 테스트할 수 있는 터미널풍 이메일 클라이언트를 만들어 달라”는 초기 스타트업 엔지니어에게 합리적인 요청이고, 세부 사항은 엔지니어에게 맡겨질 수밖에 없음
      특히 “완성까지 진행하면 Kagi에서 어떤 반응을 기대할 수 있는지 알고 싶다”는 요청은 좋지 않았음. 수백~수천 개의 제출물을 봐야 하는 상황에서 확실한 답을 줄 방법이 없음
    • 달리 말하면 글쓴이는 잘했지만, 너무 열심히 하지 말라는 암묵적 요구사항 때문에 실패한 셈임
      요구사항을 명확히 하려는 게 원치 않는 행동이라면, 차라리 1부터 10 사이 숫자를 고르게 하고 틀린 사람을 떨어뜨리는 것과 다르지 않음
      과제형 테스트는 능력을 보여주기 위한 것인데, 구체적 안내가 없으면 어느 정도까지 보여줘야 하는지 어떻게 맞히겠나
      마감이 납품을 막을 때만 나쁜 것이고, “너무 다듬어서” 탈락시키는 건 일을 너무 잘했다는 이유로 떨어뜨리는 것처럼 느껴짐
      이런 식의 모호한 테스트는 결국 문화 적합성이 아니라는 이유로 사람을 거르는 다른 방식에 가까워 보임
    • 아이디어를 검증하려는 글쓴이의 접근은 현대적인 엔지니어링 흐름과 닮아 있음. 요즘은 기능을 다 만든 뒤에야 운영, 기술 리드, 품질보증, 사용자 경험 팀에게 피드백받지 않음
      “먼저 만들고 나중에 리뷰”하는 환경은 커리어에서 가장 독성이 강한 곳들이었고, 며칠을 들여 기능을 만들었는데 원치 않는 기능이라는 걸 알게 되면 최악임
      그래서 기능을 글로 설명하고 승인받는 방식이 프로젝트 출시의 업계 표준에 가깝고, 이 지원자는 건강한 조직이 따르는 소프트웨어 관행을 따른 것임
      1천 명 이상 엔지니어가 있는 회사의 채용 관리자 입장에서도 그렇게 봄
    • 채용자로서 선호하는 과제형 과제는 숙련된 개발자가 30분 안에 끝낼 수 있고, 객관·주관 평가 기준이 명확하며, 여러 접근 방식과 절충을 요구하는 형태임
      물론 결과가 합격 여부를 가를 일부 지원자에게만 줘야 함
      마지막 구직 때 이런 광범위한 과제를 받았고, 과한 자격을 갖춘 일자리였는데도 어떤 부분이 채점 대상인지 점칠 수 없었다는 이유로 탈락했음
      앞으로 추천이 아닌 방식으로 직장을 얻을 가능성은 낮아 보이지만, 이런 과제를 받는 것도 내는 것도 크게 꺼리게 됨
    • 여러 차례 질문한 뒤 보낸 거대한 제안서가 결정타였다고 봄. 지시문은 제안서를 요구하지 않았고, 특히 그렇게 상세한 문서는 “사전 승인 없이는 주도적으로 진행하지 못한다”는 신호를 줌
      이 과제는 몇 가지 질문을 하고, 가정을 적고, 모호한 일에 자신 있게 뛰어들어 만드는 능력을 보는 것이었음
      아마 그 이메일이 간 뒤에는 코드가 중요하지 않았을 가능성이 높고, 회사는 그 시점에서 끝내서 지원자가 과제 구현에 시간을 낭비하지 않게 했어야 함

  • 코드를 보고 데모 영상을 봤을 때 첫 생각은 “두 페이지짜리 웹 앱을 만드는 데 일주일이 걸렸고, 메시지를 여는 기능 같은 가장 기본적인 이메일 기능도 빠졌네”였음
    요구사항을 보니 이 사람은 “Email Backend Engineer”에 지원했는데 실제 이메일 백엔드에는 Postmark와 Turso 같은 서드파티 제품을 썼음
    일반 텍스트 이메일 포맷, 보기, 폴더함, 최소한 받은편지함과 보낸편지함 같은 기본 요소가 빠졌고, 로그인 화면·관리자 페이지·백엔드 프레임워크 같은 선택 기능은 들어가 있음
    백엔드 데이터베이스에는 이메일 헤더 맵조차 없음
    훌륭한 엔지니어일 수는 있지만 이 특정 포지션에는 맞지 않아 보이고, 나라도 거절했을 것임
    원래 공고를 보니 제목이 “The project is to build a minimal, terminal-inspired email client”였고, aerc, mutt, himalaya 같은 기존 터미널 이메일 도구에서 영감을 받으라고 명시돼 있었음
    이건 요구사항을 제대로 읽지 못한 수준이라 채용 불가로 보임

    • 어떤 요구사항을 충족하지 못했는지 모르겠음. 이메일 클라이언트는 터미널, 즉 TUI여도 되고 웹 앱이어도 되며, 기본적인 이메일 보기와 보내기 기능이 있으면 됨
      둘 다 충분히 충족한 것으로 보임
      기존 도구에서 영감을 받는다는 건 주관적이고, 백엔드 포지션의 과제에서 사용자 인터페이스에 시간을 쓰는 게 실력을 보여주는 최선이라고는 생각하지 않았을 것임
    • 지원자 입장에선 몇 시간을 들였는데 템플릿 거절 메일만 받는 건 정말 별로임. 적어도 왜 마음에 들지 않았는지는 알려줘야 다음에 배울 수 있음
      인기 포지션에서 채용 담당자가 수백 명을 검토한다면 항상 현실적이지 않다는 건 이해하지만, 그래서 과제형 전형이 별로임
      지원자가 인생의 몇 시간을 아무것도 얻지 못한 채 낭비할 수 있으니, 양쪽 모두 서로의 시간을 존중해야 함

  • 응답이 매우 짧고 도움이 되지 않았다는 건 이해하지만, 요구사항에는 분명 terminal-inspired 이메일 클라이언트를 만들라고 되어 있음
    공유된 영상 https://www.youtube.com/watch?v=yY1sVXMkP_o를 보면 특별히 터미널에서 영감을 받은 점이 없는 평범한 이메일 웹 앱처럼 보임
    실제 TUI나 웹 앱 중 하나를 원했다면, 웹 앱도 터미널풍이어야 했을 가능성이 높음
    전체 요구사항의 “Inspiration”에는 “aerc, mutt, himalaya 같은 기존 터미널 이메일 도구에서 영감을 받으라”고 명시돼 있음

    • 거절 메일에서 더 명확히 설명했거나, 제안서에 답할 때 경고해줬다면 좋았을 것임. 다만 제안서만으로는 과제의 그 부분을 무시하는 방향으로 갈지 100% 명확하진 않았음
      그래도 프롬프트는 다른 터미널 클라이언트들을 영감으로 명시했음
      또한 터미널 클라이언트라는 요구는 평가 대상을 크게 바꿈. 이메일 웹 UI는 오래전부터 알려진 영역이지만, 터미널 클라이언트의 사용자 경험은 아직 완전히 “해결된” 영역이 아님
      평가표에는 지원자의 제출물이 전혀 다루지 않은 터미널 클라이언트 설계 판단이 큰 비중으로 있었을 가능성이 큼
    • Go 프로그래밍을 강조한 것처럼 보이는데, Go에서 명령줄 인터페이스를 띄우는 건 20줄 미만으로도 가능함. 굳이 훨씬 더 일이 많은 브라우저 GUI를 선택한 이유가 불분명함

  • 과제형 평가는 면접 과정에서 가치가 있을 수 있지만, 반드시 시간 제한이 필요함. 2~3시간이면 필요한 정보는 충분히 얻을 수 있고, 그 이상은 부양가족·취미·책임이 없는 신입만 걸러내려는 것에 가까움
    3시간으로 제한했다면 최악의 경우 지원자는 3시간만 잃었을 것이고, 더 가능성 높은 경우에는 그 시간에 맞는 전혀 다른 제안이나 해법을 냈을 것임
    지원자는 “아무 답이나 원하는가, 좋은 답을 원하는가”도 확인해야 함
    어떤 과제는 테스트 묶음을 통과하는지만 보고 방식은 상관하지 않지만, 어떤 과제는 요구사항의 80%만 충족하더라도 더 나은 코드를 선호함. 양쪽 모두에서 지원자가 잘못 판단하는 경우를 봤음

    • 채용하고 과제형 과제를 내는 입장에서 Kagi의 과제는 거대하고, 지원자의 시간을 존중하지 않는다고 느낌
      이런 과제는 프로젝트에 많은 시간을 낭비할 수 있는 사람을 걸러내고, 정작 바쁜 사람들, 즉 원할 법한 사람들은 지나치게 만들 가능성이 큼
      데이터 엔지니어링 역량을 뽑을 때는 단순한 ETL 과제를 냄. ZIP 파일에서 데이터를 꺼내 변환하고 아무 데이터베이스에 넣게 함
      애매한 부분을 남겨두고, 데이터셋에는 예상치 못한 null 값이나 잘못 포맷된 CSV 같은 숨은 요소를 넣어 수행 능력을 봄
      4시간으로 제한하지만 시간이 부족할 때의 안내는 주지 않았는데, 그건 좋은 제안임
      이후 통화에서 코드를 함께 보고 “데이터셋이 메모리에 다 안 올라가면?” 같은 질문으로 개선 방향을 묻고, 그 지점이 실제 기술 평가가 됨
    • 지원자가 실제로 더 많은 시간을 쓰지 않았는지 어떻게 알 수 있나
      모든 지원자가 같은 시간을 썼다는 보장이 없기 때문에 게임 이론 문제가 되고, 지원자는 대체로 어떤 형태로든 손해를 봄
      많은 경우 정답은 시간을 더 들여 매우 다듬어진, 하지만 너무 다듬어지지는 않은 해법을 만든 뒤 제한 시간을 지킨 척하는 것임
      3시간도 다음 사람과 대화할 수 있을지 모르는 지원자에게는 매우 긴 시간임
      1시간 면접에서는 프로그래밍 과제를 진행하며 지원자가 추가 시간을 낭비하지 않는다는 걸 보장할 수 있음
      지원자가 원하면 나중에 개선 답안을 보내게 할 수도 있고, 보통 그 시점에는 이미 역량을 좋게 봐서 “원하면 하되 이미 통과했다”고 말할 수 있음
      지원자와 면접관의 시간 투자를 같게 유지하면, 내가 내 시간을 존중하듯 지원자의 시간도 존중하게 됨
      채용 관리자가 지원자의 시간을 존중하지 않는다면, 직원의 시간을 존중할 가능성도 낮아 보임
    • 실시간 코딩보다 실시간 코드 리뷰가 훨씬 낫다는 글쓴이 의견에 동의함. 그래도 회사가 실시간 코딩을 고집한다면, 내 노트북과 마우스를 가져오게 하고 45분 동안 방을 비운 뒤 내가 만든 것을 두고 이야기하면 좋겠음

  • 최근 여러 곳에서 면접을 봤는데 이 경험과 매우 비슷했음. 과제에 대해 뛰어난 해법을 냈지만, 결과물에 대한 논의 없이 거절당함
    과제형 전형을 채용자로 여러 번 운영해본 입장에서, 누군가에게 집에서 과제를 하게 했다면 반드시 코드에 대해 대화해야 한다고 믿음
    과제형을 받는다면 평가 결과와 관계없이 후속 대화가 있는지 꼭 확인하고, 동의하지 않으면 “숙제”를 하지 않는 걸 강하게 추천함
    솔직히 많은 채용 팀의 수준이 낮아서, 좋은 해법을 구현하는 게 오히려 마이너스가 될 수 있음. 채용 팀이 그 수준에 맞지 않기 때문이라는 답답한 이유로 떨어질 수 있음
    Kagi 초기 사용자였지만, 이 일 때문에 계정 해지를 고려 중임. 지원자와 이야기할 시간이 없다면 애초에 일을 시키지 말아야 함

    • 과제형 과제를 냈다면 코드에 대해 후속 대화를 해야 한다는 건 매우 타당함
      과제형은 지원자뿐 아니라 이를 운영하는 사람과 채용 팀에도 상당한 노력이 필요하고, 프로젝트를 검토했다면 요청 시 피드백이나 응답을 기대하는 게 합리적임
      다만 현실도 있음. 한 자리마다 훌륭한 후보가 20명 있으면 능력 있는 사람들도 많이 거절됨. 그들이 부족했다거나 “실패했다”는 뜻은 아님
      법적으로 왜 A를 뽑고 B를 뽑지 않았는지 설명해야 하면 “둘 다 훌륭했지만 하나를 골랐다”고 말하기 어렵고, 결국 존재하지 않는 흠까지 찾아내는 식으로 흐르기 쉽다고 봄
      미국 기업 문화에서는 그런 방식이 자주 보였고, Kagi는 Palo Alto 기반임
    • 회사는 프로젝트 평가 기준을 명확히 공개하거나, 무엇을 더 잘할 수 있었는지 피드백을 줬어야 함
      과제에서 떨어지는 건 괜찮지만, 아무것도 돌려주지 않고 누군가의 시간을 낭비하는 건 받아들이기 어려움
      인기 있는 스타트업을 포함해 이를 잘 처리하는 회사도 많음
    • 정말 뛰어난 해법을 냈는지는 의문임
      결과물은 “최소한의 터미널풍 이메일 클라이언트”와 별로 닮지 않았고, 영감을 받으라고 제시된 도구들도 완전히 무시한 것처럼 보임
      요구사항을 이렇게 크게 오해했다면 나라도 토론에 시간을 쓰지 않았을 것임

  • 이건 숨은 맥락을 잘못 읽은 전형적인 경우임. 회사는 독립적으로 자기 일과 목표를 만들 수 있는 사람을 원한 것임
    과제의 모호함은 여러 이메일로 캐묻기 위한 것이 아니라, 꽤 넓은 과제를 받아 스스로 문제 공간을 탐색하고 결과물을 만드는 방식을 보여주기 위한 빈 캔버스였음
    대학에서 일하다 보면 과제를 이해하지 못한 학생이 예상 못 한 점수를 받고 불평하는 모습과 매우 비슷함

    • 전적으로 동의함. 이 과제는 최대한 작고 영리한 기능적 해법을 만들 사람을 찾는 것처럼 보임
      인상 깊게 보이고 싶은 면접 상황에서 감히 “게으르게” 굴 수 있는 사람은 흔하지 않음
      빠른 실험 출시와 프로토타입 중심 접근을 가진 회사라면 어떤 사람은 정말 맞지 않고, 그건 모두에게 나쁨
      아마 어떤 지원자는 10분 동안 60분 안에 무엇을 할 수 있을지 생각하고, HTTP 인증과 폼을 활용해 작은 Go 백엔드로 돌린 뒤 짧은 이메일과 함께 보냈을 것임. 그런 사람이 과정에서 훨씬 좋아 보였을 가능성이 큼
    • 숨은 맥락이라고 하지만, 사실 텍스트 자체에 그대로 있음
    • 과제가 “R&D 프로젝트”이고 “최소한”이라는 말 외에 맥락을 전혀 주지 않았다면 그 주장은 성립하기 어려움
      이게 버리는 프로토타입인지, 실제 사용자가 볼 물건인지, 불완전한 사용자 경험으로 지적받을지, 그냥 무언가 보려는지 알 수 없음
      결국 리뷰어의 취향을 맞히는 훈련이 되어버림
    • 이런 Choose Your Own Adventure식 과제마다 “숨은 맥락을 잘못 읽었다”는 이유로 떨어지는 사람이 많을 것임
      반대로 요구사항을 계속 밀어붙여 명확히 하지 않았다고 떨어지는 사람도 있을 텐데, 그건 엔지니어에게 중요한 덕목임
      삶은 공평하지 않지만 채용 관리자에게는 더 많은 걸 기대하고, 그래서 계속 실망하게 됨
    • 과제를 내는 사람에게 “학생이 과제를 이해하지 못했다”는 결론은 너무 게으르고 편리함
      학생이 독심술을 못 하고 지시문이 형편없이 쓰였기 때문에 오해했을 수도 있음
      좋은 교사는 최대한 많은 학생이 이해하게 만드는 사람이고, 나쁜 교사는 그 반대임
      최고의 교사들 밑에서는 채점 기준이 처음부터 투명했기 때문에 점수를 의심할 필요가 없었음
      혼란스러워하는 학생이 많다면 공통분모는 교사일 수 있음
      불교 승려가 공안이라는 난해한 수수께끼를 풀며 배운다고 해서, 등록금을 내는 대학생들에게도 같은 방식을 적용해선 안 됨

  • 글쓴이가 직접 올린 것 같으니, 받은 반응의 맥락을 설명해보겠음. 예전에 Kagi에서 일했고, 비슷한 과제형 테스트를 거쳤음
    당시 회사는 매우 작았고 Vlad가 직접 지원자를 검토했으며 이런 과제형 프로젝트를 사용했음. 지금은 회사가 커져서 직접 보지 않을 수 있지만 핵심은 비슷해 보임
    Vlad와 이야기해보면 그는 거의 Hacker News 댓글러의 전형이고, 면접은 “괜찮은 사람처럼 보이는지” 보는 분위기 확인에 가까움
    그에게 긴 설계 문서로 “Galactor를 쓰고, florp-ready하게 만들고, fleem하겠다”고 쓰는 건 멋짐의 정반대임
    과제가 “터미널풍 이메일 클라이언트”라면, 만점에 가까운 프로젝트는 모든 기능에 키보드 단축키가 있고, 한 프레임을 그리는 데 2ms를 넘지 않는다고 한 문단으로 설명하는 물건일 것임
    면접관은 지원자가 Kagi에서 일하기엔 너무 엔터프라이즈식 사고를 한다고 봤을 가능성이 큼
    물론 이런 선발 방식이 좋은지는 별개임. Vlad는 자신처럼 생각하는 사람을 원하고, 이런 면접에는 오래 논의되고 연구된 문제가 많음
    다만 그걸 이해하고 그런 과정을 감당할 여유가 있다면 과제가 실제로 말이 되긴 함. Kagi는 이 점을 더 잘 전달할 수 있었을 것임
    시간을 많이 낭비하게 된 건 안타깝지만, 작업 방식에 더 맞는 곳을 찾길 바람

    • 많은 회사가 “나처럼 생각하는 사람”을 뽑고 싶어 하는 것 같음. 하지만 그건 실수라고 봄
      문제에 새로운 통찰을 주려면 사고의 다양성이 필요함. 모두가 같은 방식으로 생각하면 한 명이 막혔을 때 모두가 막힐 가능성이 큼
      스타트업에서 흔한 문제로 보이고, 스타트업 10곳 중 9곳이 실패하는 이유를 보여주는 신호일 수도 있음
    • 마음에 걸리는 건 Vlad가 “멋진” 사람을 찾기 위해 나머지 모두의 시간을 낭비한다는 점임
      능력을 테스트하는 것과는 다름. 여기서는 알려주지 않은 지표에서 높은 점수를 받아야 통과함
      “아무거나 코딩해봐, 모호함을 잘 다뤄야 하니까”라고 과제를 내놓고, 사실은 내가 머릿속에 둔 걸 맞히라는 것과 크게 다르지 않음
      사람들에게 매우 배려 없는 방식이고, Vlad라는 사람에 대해 좋은 신호를 주지도 않음
    • “긴 설계 문서가 멋지지 않다”는 걸 내가 이렇게까지 맞혀야 하나
      이걸 알아내려고 회사 사람들의 소셜미디어를 뒤져야 한다는 건가
      결국 내가 멋지지 않다는 걸 충분히 드러냈는데도 “진행하라”고 해서 호기심을 채운 셈이라면, 그들도 남을 대하는 방식 그대로 대우받길 바람
      설명을 준 건 고맙고 악감정은 없음. 다만 이런 글을 더 일찍 봤더라면 좋았겠음
      앞으로 “take-home”이 있는 일자리는 멋진 애들용 일자리로 분류하면 좋겠음. 그러면 지루하지만 경험 많은 엔지니어들이 회사가 실제로 우리 노동을 원한다면 방식을 바꾸도록 압박할 수 있음
      바꾸지 않는 회사라면 그 역할을 “제공”하는 회사가 어떤 곳인지 추론할 수 있음

  • 리뷰어라면 어떻게 볼지 보려고 코드를 살펴봤음
    처음 연 파일에서 여기까지 보고 멈췄을 것임: https://github.com/Sleepful/mymail/blob/main/app/router/page...
    첫 주석은 작업과 무관해 매우 이상하고, 블로그 예제에서 복사해온 것처럼 보임. 어쨌든 그대로 남긴 건 주의 부족임
    두 번째 줄의 표현은 세 번째 줄과 일관되지 않음
    여기서 리뷰를 멈췄을 것임. 세부 사항에 대한 주의 부족이고, 명확히 생각하는 능력을 보여주지 못함

    • 이 이야기의 문제는 지원자가 탈락했다는 게 아니라, 명확한 가이드라인이나 가치 있는 피드백 없이 많은 무급 시간을 들여 프로젝트를 구현하게 하는 과정이 대체로 무례하다는 것임
    • 앱을 내 도메인에 배포했고 기능은 문제없이 동작했음. 시간이 엄청나게 오래 걸렸고, 백엔드 역할에 흔한 인증과 Infrastructure as Code 같은 추가 기능도 넣었음
      그런데 돌아온 건 빈 거절 메일이었음
      그 상황에서 코드 주석에 시간을 더 썼어야 한다는 말에는 동의하기 어려움

  • 엔지니어링 면접관으로서 말하고 싶음. LeetCode도 과제형도 좋아하지 않음. 둘 다 시간이 많이 들고 얻는 정보는 적음
    그래도 이 경우 글쓴이를 거절했을 가능성이 큼. Kagi Search는 스타트업이고, 이런 곳은 보통 빠르게 움직이는 실용적 낙관주의자와 깊이·넓이의 균형을 맞출 수 있는 사람을 찾음
    예전에 입력을 모아 며칠 동안 틀어박혀 해법을 만들고 나왔더니 그 사이 요구사항이 바뀌어 있던 동료가 있었음. 누구에게도 즐거운 경험이 아니었음

  • 과제형 전형이 정말 싫음
    “이 프로젝트는 코딩뿐 아니라 모호함과 열린 문제를 다루는 능력도 테스트합니다”라는 문구는 실제로는 a) 과제가 너무 부실하게 설계되어 평가표도 만들지 않았거나 b) 업무 환경이 너무 혼란스러워 어떤 명세나 요구사항도 명확히 정의하지 않는다는 뜻처럼 들림
    게다가 “기술을 뽐내라”와 “실용적이고 기능적인 해법을 내라”는 지시는 서로 충돌함. 좋은 단순한 해법은 화려하지 않음

    • 사용자 인터페이스나 API 연동이 들어간 과제형은 약간 경고 신호로 봄. 대부분 역할에서 UI 코드는 비교적 지루하고, API 연동은 신호는 적은데 번거로운 코드가 많음
      HTTP 요청을 만들 수 있고 기본 CRUD 편집 화면을 만들 수 있다는 건 거의 아무것도 말해주지 않음. AI 도구도 이런 건 빠르게 꽤 괜찮은 품질로 만들어냄
      보고 싶은 건 어색한 비즈니스 로직을 엔지니어가 어떻게 구현하는지임
      백만 개의 중첩 if와 “여기 용 있음” 주석이 되는지, 아니면 적절한 패턴을 찾아 읽고 추론 가능한 코드를 만드는지 보고 싶음
      이게 실제 업무에서 훨씬 가치 있고, 면접 신호도 강하며, AI가 맞히기도 더 어렵고, 시간도 덜 듦
    • 여러 프로젝트를 하는 스타트업이라면 업무 환경이 혼란스러울 것으로 예상됨. 예측 가능한 한 주를 원하는 사람은 그런 직장에 지원하지 않는 편이 나음
      좋은 단순한 해법을 만드는 것이야말로 실력을 보여주는 방식일 수도 있음
    • 채용하려는 역할의 일부가 사람들이 명세와 요구사항을 명확히 정의하도록 돕는 것이라면 어떨까
      그건 시니어 소프트웨어 엔지니어의 큰 역할이라고 봄
      이 형식이 그걸 테스트하는 최선은 아닐 수 있지만, “모호함을 다룰 수 있는지 보겠다”가 모든 일이 모호하다는 뜻은 아님
      모든 일이 “모호한 요구사항”에서 “명확한 명세”로 가는 과정을 거쳐야 한다는 뜻일 수 있음
답변달기