Kagi Searchの課題型面接で不採用になった体験

• ソフトウェア開発者の面接で課される「take-home assignment」の非効率性と、応募者の時間の無駄という問題を強調している
• Kagi Searchへの応募過程で、過度に広範で曖昧な課題要件を経験した
• 提案した具体的な実行計画に対して、マネージャーから明確なフィードバックがなく、非効率なコミュニケーションを経験した
• 心血を注いで開発したプロジェクトを提出した後、明確な理由のない不採用や基準変更などに不合理さを感じた
• より良い採用プロセスの代案（例: リアルタイムのコードレビュー）と、課題型面接の過度な要求に対する問題意識を共有している

---

序文

• Take-home assignmentとは、ソフトウェア開発者の面接で応募者に課題を出し、それをコードで実装して提出させる評価方式である
• 本記事は、評判の良い会社だと思っていたKagi Searchに応募し、実際に課された課題とその経験を通じて、この方式の不合理さと応募者の時間浪費の問題を指摘しようとするものである

Kagi Searchへの応募

• Kagi Searchのバックエンド開発者ポジションに履歴書を提出した
• 当該ロールの要件は次のとおり
  • バックエンドシステム構築経験
  • Go言語の活用能力
  • 大規模バックエンドシステムの拡張・保守経験
  • SREなどのチームメンバーとの協業能力
  • Dockerなどのコンテナ技術の理解

面接課題の案内と要件

• 書類通過後、take-home assignmentの案内メールを受け取った
• 課題テーマ: 「最小限のターミナル風メールクライアントの実装」
  • ターミナルまたはWebアプリ形式のいずれかを選択
  • 基本的なメールの閲覧/送信機能
  • ダミーまたは実際のメールバックエンド（IMAP/POPなど）を自由に選択
  • plaintextメッセージ処理のみ必須で、rich textは不要
  • プロジェクト提出: GitHubリポジトリ、デプロイ済み成果物、インストール案内文書を含む
• 明確なガイド不足があり、プロジェクト規模もかなり大きい
• 評判が良い会社だったこともあり、課題に取り組むことを決めた

マネージャーとのコミュニケーション

• 明確な課題範囲や追加機能について問い合わせても、「何を追加するかは応募者の自由」という曖昧な返答しか得られなかった
• 課題に時間と労力を投じる前に、**具体的な実行計画（Proposal）**を共有し、それに対する返答を求めたが、特別なフィードバックもないまま進行した

課題提案と計画

• 実行計画:
  • GoベースのWebアプリ
  • AWS ECS FargateによるデプロイとSSL適用
  • メール送信サービス（Postmark）の連携
  • ログイン/認証機能の追加
  • メール送受信およびUI表示
• 技術選定の根拠:
  • バックエンド職と関連する多様な技術を活用
  • Infrastructure-as-Codeツールを用いた実践的なシステム構築
  • 単純なAPI連携を超え、実サービスに近い機能を実装
• 主な実装要素:
  • Pocketbase（backend/DB）、TEMPL（テンプレート）、Pulumi（IaC）、Postmark（メールサービス）
  • ページネーション、ログインなどを実装
  • Stretch Goal: データのバックアップと復旧などの安定性
• 結論: 事前に十分な説明と根拠を提示しており、それに対する明確な検討と返答を期待していた

マネージャーの返答とコミュニケーション上の問題

• 具体的な検討もなく、「興味深い提案」という短い返答しか得られなかった
• 提案の適切性や改善要求などのフィードバックは皆無だった
• 応募者の立場からすると、時間投資と労力に対する尊重が欠けていると感じられた

プロジェクト課題の実施

• 与えられた要件と提案事項をすべて実装し、丸1週間のフルタイムを投入した
• プロジェクトのデモ動画、GitHubリポジトリ、詳細な文書まで提出した

不採用通知とそれに対するフィードバック

• 自動化された不採用メールを受け取った後、フィードバックを求めて得た返答:
  • 「より強力な応募者の提出物があった」「採用競争が激しい」
• 問題点
  1. 単純なソリューションを好むのであれば、最初から案内できたはず
  2. 提案が不十分だったのであれば、その時点でフィードバックできたはず
  3. 不採用後も求人は依然として掲載中であり、単なる競争ではなく過度な時間消費を要求していると判断された
  4. プロジェクト提出後に要件がさらに強化され、提出したソリューションがかえって基準を引き上げた形になった

結論と問題意識

• このような方式は多くの求職者にとって不合理であり、実質的に生活への脅威さえ伴う
• 過度な無給課題の要求については、拒否したり問題提起したりする必要があることを強調している
• プロジェクト型課題に代わる、リアルタイムのコードレビューなどより良い採用プロセスは可能である
  • 実際の開発における問題解決能力は、非同期/同期のコードレビューなどで見極められる
  • Leetcodeスタイルの問題解きと実務要件の乖離を指摘している
• 求職者の消耗と不当な評価の文化改善を訴えている

より良い採用手続きのための提案

• リアルタイムのコードレビュー方式など、開発者の能力をより意味のある形で評価する代案を提示している
• タイマー付きアルゴリズムパズル中心ではなく、実際の能力と問題解決力を重視する方向への変化の必要性を力説している

[GN⁺]

Hacker Newsの意見

• 正直な採用側の立場から意見を述べる。個人的には takehome 課題が嫌いだ。こうした課題はみんなの時間を無駄にしがちだ。採用の最終段階なら理解できるが、応募者の足切り用途で使うのは非効率だ。
  1. 質問が多すぎた。曖昧さの中で判断力を使って解決すること自体が課題の一部だ。与えられた条件なら、1〜2日投資して簡単なローカルプロジェクト程度で十分だったはずだ。
  2. 提案書の作成と共有が過剰すぎた。応募者は徹底性を見せたかったのだろうが、会社側からすると非効率で時間の無駄だと思われてもおかしくない。
  3. 完成した成果物は機能的ではあったが、インフラと仕上げに力を入れすぎていた。不採用になれば結局は時間の無駄だった。
  4. ターミナルに着想を得たメールクライアントという要件があったようだが、成果物からその方向性を見いだせなかった。
     応募者の能力と仕事への熱意は認める。少し違う視点から意見を述べたかった。
  • ブログ執筆者の態度が少し鼻につくように感じる。文章だけを見ても、一緒に働きにくく、自律的に判断を下すのが難しく、明快なガイドラインを必要とする印象だ。大企業には合うが、スタートアップには合わない。
    「ターミナルに着想を得たメールクライアントを開発して顧客にアルファテストしてもらう」というのは、初期スタートアップのエンジニアに対して妥当な依頼だ。仕様がもう少しあったとしても、多くの部分はエンジニアの判断に委ねられる。応募者は確実性を求めすぎている。
    Kagi が課題完了後にどんなフィードバックをくれるのかを事前に気にしているのは、あまり良い兆候ではない。確定的な回答ができる状況ではない。おそらく彼らは何百、何千件もの応募を評価しているのだろう。
  • 筆者はよくやったが、暗黙の「頑張りすぎないこと」という条件で失敗した。
    もし要件の明確化が必要なかったのなら、いっそ「1〜10の数字当て」をさせて、外した人を落とすのと同じだ。
    課題に力を入れて仕上げを良くしたことを理由に落とす事例には賛成できない。
    こういう曖昧な課題は、結局のところ「カルチャーフィット」を見極める別の手段にすぎない。
  • 私の考えでは、応募者が自分のアイデアを検証するアプローチは、最近のエンジニアリングのやり方に似ている。健全なチームは、機能設計書を英語で説明して承認を得てから進める。
    「コード先行、フィードバックは後で」という文化は、キャリア上もっとも有害な経験だった。この応募者は現代的なソフトウェア実務に従っていた。（私は 1000 人超のエンジニアを抱える会社の採用担当だ）
  • 採用側として好ましい takehome 課題は、30 分以内で完了可能、評価基準が明確、さまざまなアプローチやトレードオフの検討が含まれるものだ。
    私も前回の転職活動で広範な takehome 課題に取り組み、どの部分が評価基準なのかわからないまま落ちた。この経験以来、こうした課題に強い拒否感がある。
  • 提案書が大きくなりすぎたことが不採用理由だと思う。指示に提案書の要求はなく、細かく提出すると、かえって「自律的な推進力が足りない」と解釈されることがある。こうなるとコード品質はもはや無意味になる。
    会社は時間を無駄にさせるくらいなら、その時点で課題を打ち切るべきだったと思う。
  • 最近の業界で、要件把握能力が足りないために読心術で開発者を選別している現実は残念だ。
  • 応募者が締め切りを守れなかった点も問題だ。特別な事情の説明もない遅延は、その時点で不採用だ。締め切り内に適切な解決策を設計することが課題の目的だった。
  • 4 番のターミナルに関する言及については、筆者が共有した完全版にはその部分の説明がある。
  • こうした議論は、結果を見た後ならいくらでもできる。反対の戦略（要件を確認せず、最低要件だけ満たす）でも同じ結果になっていたかもしれない。こういう状況では、いつでも「もっと積極的に要件を明確化すべきだった」という意見が逆方向からも出せる。
• コードを見て、さらにデモ動画を見たとき、1 週間かけて 2 ページの Web アプリを作るのにかなり時間がかかったのだな、という印象を受けた。
  もっとも基本的なメール機能（メールを開くなど）すらなく、バックエンドエンジニア職への応募でありながら、実際には postmark や turso のような外部製品を使っており、基本機能（プレーンテキストの整形、表示、フォルダなど）の欠如も見られる。
  管理ページやログインのような付加機能はあるが、メールヘッダーマップのような最低限のデータ構造すら欠けていた。
  良いエンジニアである可能性はあるが、そのポジションには不適切だと判断する。
  takehome の提案書もあまりに異例だと感じた。
  最初の募集要項を読み直すと、「最小限のターミナル着想のメールクライアント」と aerc、mutt、himalaya などの参考例が明記されていた。これは明白な要件解釈ミスだ。
  • 「要件解釈ミス」という言葉に対して、いったいどの要件を満たしていなかったのか気になる。
    ターミナルまたは Web アプリ形式のメールクライアントで、基本機能の実装が求められていたのだから、それは満たしていたと思う。
    ターミナルベースのツールから着想を得るという部分は主観的だ。バックエンド職なら UI に気を配ることが非効率かもしれないとも思う。
  • 応募者が時間を投資したのに、断りのメール 1 通だけを受け取るのはつらいことだ。
    フィードバックだけでももらえれば成長に役立つはずだが、それすら現実的には難しいことが多い。
    だから 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 時間のオンサイトコーディングの方が良い。応募者と面接官が同じ時間を投資してこそ、互いの時間の価値を尊重できる。
  • ライブレビューはライブコーディングよりずっと良いと思う。もしライブコーディングをするなら、自分のノート PC で 45 分離れて作業して戻ってきてレビューする方式の方がよい。
• 会社の返答が不親切で役に立たなかったのは事実だが、要件に「ターミナル着想」と明確に書かれていた。
  デモ動画では一般的な Web アプリしか見えない。aerc、mutt、himalaya など既存のターミナルメールクライアントから着想を得るよう、明示的に求められていた。
  自分が何か見落としているのか気になる。
  • 断りのメールで理由を明確に説明してくれていたらもっと良かったが、そもそも課題設計の段階でターミナルクライアントの参考例が直接的に求められていた。
    ターミナルクライアント特有の UX は、いまだに「正解」がない分野なので、むしろそこを評価基準にしていた可能性が高い。
  • Go 言語中心であることを考えると、CLI を作るのに 20 行もかからないのに、あえて Web GUI 開発に没頭した選択は疑問だ。
  • 「Email client can either be in the terminal (i.e. a TUI) or a web app」という案内がある。
• 最近の面接で似た経験をした。課題プロジェクトを非常によく仕上げて提出したのに、そのプロジェクトについて会話もないまま、すぐ不採用通知だけが来た。
  課題を求めたのなら、必ず follow-up ミーティングを経るべきだと信じている。
  もともと Kagi を有料で使っていたが、今回の件でアカウント削除を考えている。
  候補者と話す余裕すらないなら、最初から課題そのものを要求すべきではない。
  • takehome 課題は応募者だけでなく、評価する面接官にもかなりの労力が必要だ。
    レビューまでしたのなら、フィードバックを受ける権利があると思う。
    だが現実には、何十人もの優秀な応募者の中から 1 人だけ採るとなると、不採用は必ずしも「実力不足」を意味しない。
    法的にも、「なぜ A を採って B を落としたのか」という公式回答は、あら探しのようなものにしかならないのが現実だ。
  • 会社がどう評価するのか明確な基準を公開していたり、フィードバックをくれたりしていれば、もっとよかった。失敗フィードバックもない時間の無駄は容認できないと思う。
    多くの会社はこの点をうまく処理している。
  • そもそも「優れたソリューション」だったのか疑問だ。最小限のターミナル着想メールクライアントという要求と、関連する参考例を完全に無視していたように見える。
    こうした要件の誤解が大きい場合、議論自体が省略されることはある。
• この事例は、課題本文にある隠れた意図を読み違えた典型例だ。
  会社は自律的で、自分で目標を立てられる人を求めていた。
  曖昧さは、応募者が答えを多面的に探りながら解く力を見るためのものだった。
  • その課題は、できるだけシンプルで機知に富み、かつ機能するソリューションを出せる人のためのものだった。
    プロトタイプ中心の会社には向き不向きがあるので、ある候補者なら 10 分考えて 60 分以内で最大限のものを作れたかもしれない。
  • R&D プロジェクトで「最小化」だけが強調されると、それがプロトタイプなのか、ユーザー向けなのか、UX を気にすべきなのかなど要件が曖昧で、評価者が何を重視するのかを当てるゲームにすぎなくなる。
  • こういう「自分で解釈しろ」という課題では、要件の明確化や追加質問をしなかった人が落ちることもある。
    しかし開発者にとって、こうした質問力は非常に重要な資質だ。だからこそ、この採用方式にはもっと期待してしまうし、失望も大きくなる。
  • 「misreading the subtext」は、要件そのものに書かれていたと思う。
  • 教育現場で「理解できない」と学生だけを責めるのは、あまりにも安易な結論だ。
    実際には曖昧な説明のせいであることも多い。
    優れた教師は、できるだけ多くの人が理解できるようにする。混乱する学生が多いなら、問題は出題側にある。
    大学生は不可の禅僧のように公案を解く必要などない。
• 投稿者本人が記事を上げたので、Kagi で働いた経験をもとに文脈を説明したい。
  以前は Vlad が直接応募者を評価していて、課題もこういう形式だった。
  会社が大きくなるにつれ、今は別の人たちが評価しているようだ。
  Vlad には HN スタイルの気質があり、「クールだ」と感じる応募者と働きたがる。
  たとえば、長い設計文書を書いて「Galactor を使う予定で、プロジェクトは flop-ready です」などと言うと、完全に逆効果だ。
  「ターミナル着想」という要求には、すべてのキーボードショートカットなど、実際にターミナルアプリで実装される細部まで期待する傾向がある。
  こうした基準が良いフィルターかどうかは議論の余地があるが、その文脈を理解して通過できる力があれば、課題は簡単に見えるだろう。
  Kagi がこうした文脈をもっと上手く伝えてくれていればよかった。時間が無駄になったのは残念だが、自分に合う会社を見つけてほしい。
  • 多くの会社は、自分たちと似た思考様式の人を探そうとする。
    多様性のないチームは、全員が同じ壁にぶつかって停滞することがある。
    この現象はスタートアップで特に多く、10 社中 9 社が失敗する理由にも関係していると思う。
  • Vlad が「クールな人」を探すために、多くの人の時間を無駄にしている点が問題だと感じる。
    明確な基準なしに採点する課題は不公平だと思う。
    結局は「自分の頭の中の答え」を当てろという暗黙の課題と変わらない。
    人への配慮が足りない印象を受ける。
  • 「私は本当にこういう部分を事前に知っておくべきだったのか？」という疑問がある。
    こういう文化なら、誰もが潜入捜査のように調べて把握しなければならなかったのか分からない。
    私のような「クールではない」応募者でも、明確なシグナルを受け取ってすぐ別の会社を探せる方がよい。
• コードを直接レビューした結果、最初のファイルからして、目的もなくサンプルコードを写したようなコメントや、食い違う説明、注意力不足を感じさせる表現が見つかった。
  こうした細部の不備のため、レビューをやめる。
  • アプリは自分のドメインにデプロイしており、性能上の問題もなかった。認証やインフラなどバックエンド的な特性もきちんと実装している。だが、コードコメントにもっと気を遣うべきだという指摘には同意できない。
  • この事例の核心は、不採用そのものではなく、明確なガイドもなくフィードバックすら提供しない採用方式が、応募者の時間にまったく敬意を払っていなかった点だ。
• DuckDuckGo でも似た経験があったが、すべての応募段階で一定の報酬が支払われた。
  簡単な設計提案書から実装課題まで、時間制限を明確にして進めていた。
  結果として採用には至らず、明確な理由も知らされなかった。
  応募者が多すぎたのだろうとは思うが、この経験は長い間感情面で強く残った。OP の気持ちはよくわかる。
• エンジニアリング面接官の立場から言う。leetcode も takehome も、どちらも時間がかかるわりに情報量が不足している。
  それでも、自分が採用担当でも筆者は不採用にしていたと思う。
  スタートアップは、迅速かつ実務的に動ける人材を求めている。
  過去の同僚に、周囲の意見を集めてから何日も一人で没頭した結果、その間に要件がすでに変わってしまっていた、ということがあり、誰にとっても良いことではなかった。