Kagi Searchの課題型面接で不合格になった開発者の経験
(bloggeroo.dev)- Kagi Searchのバックエンド採用プロセスで、ある開発者がターミナル風のメールクライアントを約1週間フルタイムで実装したものの、提出後に後続インタビューもなく不合格となった
- 課題はTUIまたはWebアプリ、基本的なメール閲覧・送信、モックバックエンドまたはIMAP/POP/JMAPの選択など、幅広く開かれており、実装範囲と評価基準を応募者自身が判断しなければならなかった
- 応募者はGoのWebアプリ、AWS ECS Fargate、SSL、Postmark、ログイン、Pulumi、Pocketbase、TEMPLなどを含む詳細な計画を事前に送ったが、Kagi側は具体的な合格基準を示さなかった
- 不合格後に求めたフィードバックには「よりシンプルで強い提出物」があったという回答しかなく、この段階では通常は個別フィードバックを提供しないと案内された
- この経験は、無給の課題型面接や時間制限付きコーディングパズルが、実際のエンジニアリング能力よりも応募者の時間や生活条件をより強く試してしまう可能性を示している
応募と課題の受領
- 応募者はKagi Searchのバックエンド職に履歴書を送り、職務概要には次の能力が含まれていた
- バックエンドシステム構築経験
- Goの習熟
- バックエンドシステムの拡張・保守への理解
- SREおよびチームメンバーとの協業能力
- Dockerのようなコンテナ化技術への理解
- その後、Kagiから次のステップとしてKagi Developer Assessmentを完了してほしいというメールを受け取った
- 課題URLはHackMDで共有された
- 完了後に連絡すればレビューし、通過した場合は後続インタビューでアプローチとソリューションを議論するという内容が含まれていた
課題要件と開かれた評価基準
- 課題の目標は「最小限のターミナル風メールクライアント」を作ることだった
- 実装条件は比較的広く開かれていた
- メールクライアントはターミナルTUIまたはWebアプリとして実装可能
- 基本的なメール閲覧と送信機能が必要
- モックバックエンド（DB、インメモリなど）または実際のIMAP/POP/JMAPバックエンドを使用可能
- リッチテキストメッセージは除外し、プレーンテキストのみ扱えばよい
- 評価対象はコーディング能力だけでなく、Kagi LabsのようなR&Dプロジェクトに必要な曖昧さやオープンエンドな問題への対処能力まで含むと案内されていた
- 成果物の条件は次のとおりだった
- 開発者としての力量を示す形で実装すること
- 完成したプロジェクトをGitHubリポジトリに上げ、簡単に試せるようどこかにデプロイすること
- READMEにセットアップ方法を書くこと
採用担当者とのコミュニケーション
- 応募者は要件が広すぎると考え、採用担当者に質問を送った
- 担当者は候補者が多く、基本だけを実装する人もいれば、追加機能、優れたドキュメント、意思決定の説明、デモのデプロイ、今後の計画まで提供する人もいると答えた
- どの追加機能が高く評価されるのかと尋ねると、担当者は「それ自体が評価の一部」だとして、候補者が思いつく追加機能を見たいと答えた
- 応募者は実際にコーディングする前に、成果物全体の実装計画を詳しく書いて送ることにした
- 提案が受け入れられれば、電話インタビューや内定に近づけると期待していた
- その後の結果を見て、事前に条件をすり合わせようとした努力は採用担当者にとって大きな意味を持たなかったと判断した
応募者が提案した実装
- 提案の中心はGoのWebアプリベースのメールクライアントだった
- AWSにデプロイ
- ECS Fargateを使用
- SSL/HTTPSを適用
- メール送信プロバイダと統合
- ログイン画面による認証
- フォームベースのメール送信
- UIで受信メールを表示
- 提案書には納品日を3月30日（日）EODとし、最初のメールから2週間の時点より営業日ベースで2日遅い日程だと記していた
- 技術選定は次のとおりだった
- Goバックエンド: Pocketbase と TEMPL を使用
- インフラコード: Pulumi を使用し、TypeScript SDKを選択
- メールサービスプロバイダ: Postmark を使用
- UI: 送受信メールのページネーション、ログイン画面、デモ用アカウントを2つ提供
- こうした選択の理由は、職務と評価範囲をより広く示そうというものに近かった
- バックエンド職ではあるが、Webフロントエンドを追加することでWeb技術の幅を示せる
- データベースはバックエンド職と関連がある
- AWSとインフラコードによるデプロイは、IaC、Docker、ネットワーキング、レジリエンスの議論につながる
- Postmarkのようなメールサービスは、IMAP/POP統合の複雑さを減らしつつ機能を維持できる
- 応募者は「完成させたらKagiでどんな反応を期待できるか」と尋ねたが、返答は「とても興味深く、提出を楽しみにしている」という程度にとどまった
提出物と不合格
- 応募者は提案した内容をすべて実装し、全作業に1週間フルタイムかかったと明かした
- WebアプリケーションのデモはYouTubeに公開し、コードはドキュメントとともにGitHubで公開した
- 自動不合格メールを受け取った後にフィードバックを求めると、Kagi側は次のように答えた
- この段階では通常フィードバックは提供していない
- よりシンプルで強い提出物があり、その候補者たちと選考を継続することにした
- 各ポジションには多くの関心と応募があり、選考は非常に競争的である
- 今後のポジションも引き続き確認し、再応募してほしい
不合格後に残った疑問
- 応募者は、「よりシンプルなソリューション」を求めていたのなら、3月18日に提案書を送った時点でそう言えたはずだと考えている
- ソリューションが職務に合っていなかったのなら、同様に3月18日の提案書段階で判断できたはずだとも見ている
- 5月13日時点では、不合格から1か月半たっても求人票がまだ掲載されていたと記している
- 会社が同じ求人で複数の役割を埋められる点は認めている
- ただし、「勝者の席がすでに埋まった競争」のようには見えないと判断している
- 元の課題ガイドラインではデモのデプロイはあると望ましいが必須ではなかったのに、提出後にはガイドラインがデプロイを厳格な必須要件へ変更していたと記している
より良い選考方法への提案
- 応募者は無給課題が求職者、特に失職中で貯蓄が減っていく人々にとって大きな負担だと批判している
- LeetCode式インタビューにも否定的だった
- 最近のClojureベースの職務では「coin change」問題を解き、50分でテストの半分ほどは通したが、backtracking部分を実装する時間が足りなかったと記している
- 代替案としてライブコードレビューを提案している
- 非同期でも同期でも可能だと考えている
- 実際のソフトウェアプロジェクトの問題やテーマを言葉で解きほぐしていける
- 経験豊富なソフトウェアエンジニアの知識をよりよく示せる
- ライブコーディング自体を完全に否定しているわけではないが、50分でknapsackを解く能力は日常的なエンジニア業務とかけ離れていると見ている
- 切迫した状況でない限り、この種の無給作業を要求する役割は断るべきだと勧めている
1件のコメント
Hacker News のコメント
採用側の視点で見ると、課題型選考はこうした理由で好まない。全員の時間を無駄にするし、採用直前の最終段階としてはよいが、フィルターとして使うには不適切
それでも能力と本気度は明らかに見えるし、別の観点から悪魔の代弁者をしてみただけ
「顧客数名にアルファテストしてもらえるターミナル風メールクライアントを作ってほしい」というのは、初期スタートアップのエンジニアに対する合理的な依頼であり、細部はエンジニアに任せるしかない
特に「完成まで進めた場合、Kagi からどのような反応を期待できるのか知りたい」という依頼はよくなかった。数百〜数千件の提出物を見なければならない状況で、確実な答えを出す方法はない
要件を明確にしようとすることが望まれない行動なら、いっそ1から10の数字を選ばせて、外れた人を落とすのと変わらない
課題型テストは能力を示すためのものなのに、具体的な案内がなければ、どの程度まで見せるべきかをどうやって当てればよいのか
仕上げが納品を妨げるときだけ悪いのであって、「磨き込みすぎた」から落とすのは、仕事をうまくやりすぎたという理由で落とすように感じる
こうした曖昧なテストは、結局カルチャーフィットではないという理由で人をふるい落とす別のやり方に近く見える
「先に作って後でレビュー」する環境は、キャリアの中で最も有害な職場だったし、数日かけて機能を作ったのに望まれていない機能だと分かるのは最悪
だから機能を文章で説明して承認を得るやり方は、プロジェクトをリリースする際の業界標準に近く、この応募者は健全な組織が従うソフトウェアの慣行に従ったのだ
1,000人以上のエンジニアがいる会社の採用マネージャーの立場でもそう見る
もちろん、結果が合否を分ける一部の応募者にだけ出すべき
前回の転職活動でこうした広範な課題を受け、過剰なほど資格を満たしている仕事だったにもかかわらず、どの部分が採点対象なのか推測できないという理由で落ちた
今後、推薦以外の方法で仕事を得る可能性は低そうだが、こうした課題を受けることにも出すことにも強い抵抗を感じるようになった
この課題は、いくつか質問し、前提を書き、曖昧な仕事に自信を持って飛び込んで作れる能力を見るものだった
おそらくそのメールが送られた後はコードは重要ではなかった可能性が高く、会社はその時点で終わらせて、応募者が課題の実装に時間を無駄にしないようにすべきだった
コードを見てデモ動画を見たときの第一印象は、「2ページのWebアプリを作るのに1週間かかっていて、メッセージを開く機能のような最も基本的なメール機能さえ抜けているな」だった
要件を見ると、この人は「Email Backend Engineer」に応募していたのに、実際のメールバックエンドには Postmark や Turso のようなサードパーティ製品を使っていた
プレーンテキストメールのフォーマット、表示、フォルダー、少なくとも受信箱と送信済みフォルダーのような基本要素が欠けており、ログイン画面・管理者ページ・バックエンドフレームワークのような選択機能は入っている
バックエンドのデータベースにはメールヘッダーのマップすらない
優秀なエンジニアかもしれないが、この特定のポジションには合っていないように見えるし、自分でも断ったと思う
元の求人を見ると、タイトルは “The project is to build a minimal, terminal-inspired email client” で、aerc、mutt、himalaya のような既存のターミナルメールツールから着想を得るよう明記されていた
これは要件をきちんと読めていないレベルなので、採用不可に見える
どちらも十分満たしているように見える
既存ツールから着想を得るというのは主観的だし、バックエンド職の課題でユーザーインターフェイスに時間を使うことが実力を示す最善だとは考えなかったのだろう
人気ポジションで採用担当者が数百人を見なければならないなら、常に現実的ではないことは理解するが、だからこそ課題型選考はよくない
応募者が人生の数時間を何も得られないまま無駄にすることがあるのだから、双方がお互いの時間を尊重すべきだ
返答が非常に短く役に立たなかったという点は理解できるが、要件には明確に terminal-inspired なメールクライアントを作るよう書かれている。
共有されている動画 https://www.youtube.com/watch?v=yY1sVXMkP_o を見ると、特にターミナルから着想を得た点のない、普通のメール用Webアプリに見える。
実際のTUIかWebアプリのどちらかを求めていたとしても、Webアプリもターミナル風であるべきだった可能性が高い。
全体要件の「Inspiration」には、「aerc、mutt、himalaya のような既存のターミナルメールツールから着想を得ること」と明記されている。
それでもプロンプトでは、他のターミナルクライアントを着想源として明示していた。
また、ターミナルクライアントという要件は評価対象を大きく変える。メールのWeb UIは昔から知られた領域だが、ターミナルクライアントのユーザー体験はまだ完全に「解決済み」の領域ではない。
評価表には、応募者の提出物がまったく扱っていない ターミナルクライアント設計上の判断 が大きな比重で含まれていた可能性が高い。
課題型評価は面接プロセスで価値を持ち得るが、必ず 時間制限 が必要だ。2〜3時間あれば必要な情報は十分得られるし、それ以上は扶養家族・趣味・責任のない新人だけを選別しようとしているのに近い。
3時間に制限していれば、最悪でも応募者が失うのは3時間だけだったし、より可能性が高いのは、その時間に合わせたまったく別の提案や解法を出したはずだということだ。
応募者は「どんな答えでも欲しいのか、よい答えが欲しいのか」も確認すべきだ。
課題によってはテスト群を通るかどうかだけを見て方法は問わないものもあるが、要件の80%しか満たしていなくても、より良いコードを好む課題もある。どちらのケースでも応募者が読み違えるのを見たことがある。
こうした課題は、プロジェクトに多くの時間を浪費できる人を選別し、実際には忙しい人たち、つまり欲しいはずの人たちを遠ざけてしまう可能性が高い。
データエンジニアリング能力を採るときは、単純な ETL課題 を出している。ZIPファイルからデータを取り出して変換し、任意のデータベースに入れてもらう。
あいまいな部分を残しておき、データセットには予期しないnull値や誤ってフォーマットされたCSVのような隠れた要素を入れて、遂行能力を見る。
4時間に制限しているが、時間が足りない場合の案内はしていなかった。それは良い提案だ。
その後の通話でコードを一緒に見ながら、「データセットがメモリに収まりきらなかったら？」といった質問で改善の方向を尋ね、そこが実際の技術評価になる。
すべての応募者が同じ時間を使った保証がないためゲーム理論の問題になり、応募者はたいてい何らかの形で損をする。
多くの場合、正解はさらに時間をかけて非常に磨き込まれた、ただし磨き込みすぎてはいない解法を作り、そのうえで制限時間を守ったふりをすることになる。
3時間でも、次の人と話せるか分からない応募者にとっては非常に長い時間だ。
1時間の面接なら、プログラミング課題を進めながら、応募者が余計な時間を浪費していないことを保証できる。
応募者が望むなら後で改善版の回答を送ってもらうこともできるし、通常その時点ではすでに能力を高く評価していて、「やりたければやってよいが、すでに通過している」と言える。
応募者と面接官の時間投資を同じに保てば、自分の時間を尊重するのと同じように応募者の時間も尊重することになる。
採用担当者が応募者の時間を尊重しないなら、従業員の時間も尊重しない可能性が高そうだ。
最近いくつかの場所で面接を受けたが、この経験と非常によく似ていた。課題に対して優れた解法を出したのに、成果物についての議論もなく不採用になった。
課題型選考を採用側として何度も運用してきた立場から言うと、誰かに自宅で課題をやってもらったなら、必ずコードについて会話すべきだと信じている。
課題型を受けるなら、評価結果に関係なく後続の会話があるかを必ず確認し、同意できないなら「宿題」はしないことを強く勧める。
正直、多くの採用チームの水準は低く、良い解法を実装することがかえってマイナスになることもある。採用チームがその水準に達していないという、もどかしい理由で落とされることがある。
Kagiの初期ユーザーだったが、この件のせいでアカウント解約を検討している。応募者と話す時間がないなら、そもそも仕事をさせるべきではない。
課題型は応募者だけでなく、それを運用する人や採用チームにも相当な労力が必要であり、プロジェクトをレビューしたのであれば、求めに応じてフィードバックや返答を期待するのは合理的だ。
ただし現実もある。1つのポジションに優秀な候補者が20人いれば、有能な人たちも多く不採用になる。それは彼らが不足していたとか「失敗した」という意味ではない。
法的に、なぜAを採用してBを採用しなかったのかを説明しなければならない場合、「どちらも素晴らしかったが一人を選んだ」とは言いにくく、結局は存在しない欠点まで探し出す方向に流れがちだと思う。
米国の企業文化ではそのようなやり方がよく見られたし、KagiはPalo Altoを拠点としている。
課題で落ちること自体は構わないが、何も返さずに誰かの時間を無駄にするのは受け入れがたい。
人気のあるスタートアップを含め、これをうまく扱っている会社も多い。
成果物は「最小限のターミナル風メールクライアント」とはあまり似ておらず、着想を得るよう提示されたツールも完全に無視したように見える。
要件をここまで大きく誤解していたなら、自分でも議論に時間を使わなかっただろう。
これは隠れた文脈を読み違えた典型的なケース。会社は、自立して自分の仕事と目標を作れる人を求めていたのだと思う。
課題の曖昧さは、何通ものメールで根掘り葉掘り確認させるためではなく、かなり広い課題を受け取り、自分で問題空間を探索して成果物を作るやり方を見せるための白紙のキャンバスだったのだろう。
大学で働いていると、課題を理解していなかった学生が予想外の点数を受けて不満を言う姿にとてもよく似ている。
印象よく見せたい面接の場で、あえて「怠ける」ように振る舞える人は多くない。
迅速な実験投入とプロトタイプ中心のアプローチを取る会社なら、ある人は本当に合わないし、それは全員にとってよくない。
おそらく、ある応募者は10分かけて60分以内に何ができるかを考え、HTTP認証とフォームを使って小さなGoバックエンドで動かし、短いメールを添えて送ったのだろう。そういう人のほうが、選考過程ではずっとよく見えた可能性が高い。
これが捨てる前提のプロトタイプなのか、実際のユーザーが見るものなのか、不完全なユーザー体験として指摘されるのか、単に何かを見たいだけなのか分からない。
結局、レビュアーの好みを当てる訓練になってしまう。
逆に、要件をしつこく詰めて明確化しなかったとして落ちる人もいるだろうが、それはエンジニアにとって重要な資質だ。
人生は公平ではないが、採用マネージャーにはもっと多くを期待してしまうし、だからこそ失望し続けることになる。
学生が読心術を使えず、指示文の出来がひどかったために誤解した可能性もある。
良い教師とは、できるだけ多くの学生に理解させる人であり、悪い教師はその反対だ。
最高の教師たちのもとでは、採点基準が最初から透明だったので、点数を疑う必要がなかった。
混乱している学生が多いなら、共通項は教師かもしれない。
仏教の僧侶が公案という難解な謎を解きながら学ぶからといって、授業料を払っている大学生にも同じ方式を適用すべきではない。
投稿者本人が上げたようなので、受け取った反応の文脈を説明してみる。以前Kagiで働いていて、似たような課題型テストを受けたことがある。
当時の会社は非常に小さく、Vladが直接応募者を見ており、こうした課題型プロジェクトを使っていた。今は会社が大きくなって直接見ていないかもしれないが、核心は似ているように見える。
Vladと話してみると、彼はほとんどHacker Newsコメンターの典型で、面接は「まともな人に見えるか」を見る雰囲気確認に近い。
彼に長い設計文書で「Galactorを使い、florp-readyにし、fleemする」と書くのは、クールさの正反対だ。
課題が「ターミナル風メールクライアント」なら、満点に近いプロジェクトは、すべての機能にキーボードショートカットがあり、1フレームを描画するのに2msを超えない、と1段落で説明されるようなものだろう。
面接官は、応募者がKagiで働くにはあまりにエンタープライズ的な思考をしていると見た可能性が高い。
もちろん、こういう選抜方式が良いかどうかは別問題だ。Vladは自分のように考える人を求めていて、こうした面接には長く議論され研究されてきた問題が多い。
ただ、それを理解し、その過程に付き合う余裕があるなら、課題は実際には筋が通っている。Kagiはこの点をもっと上手く伝えられたはずだ。
多くの時間を無駄にすることになったのは残念だが、作業スタイルにもっと合う場所を見つけられることを願う。
問題に新しい洞察をもたらすには、思考の多様性が必要だ。全員が同じやり方で考えるなら、一人が詰まったときに全員が詰まる可能性が高い。
スタートアップでよくある問題に見えるし、スタートアップ10社中9社が失敗する理由を示す兆候かもしれない。
能力をテストすることとは違う。ここでは、知らされていない指標で高得点を取らなければ通過できない。
「何でもいいからコードを書いてみて。曖昧さをうまく扱えないといけないから」と課題を出しておきながら、実際には私が頭の中に置いているものを当てろと言っているのと大差ない。
人に対して非常に配慮のないやり方であり、Vladという人物についても良いシグナルではない。
それを知るために会社の人たちのソーシャルメディアを掘らなければならないということなのか。
結局、私がクールではないことを十分に示していたのに「進めてください」と言って好奇心を満たしたのだとしたら、彼らも他人への扱い方そのままに扱われればいいと思う。
説明してくれたことには感謝しているし、悪感情はない。ただ、こういう話をもっと早く見ていればよかった。
今後「take-home」がある仕事は、クールな子たち向けの仕事に分類するとよさそうだ。そうすれば、退屈だが経験豊富なエンジニアたちが、会社が本当に私たちの労働を望むならやり方を変えるよう圧力をかけられる。
変えない会社なら、その役割を「提供」している会社がどんなところか推測できる。
レビュアーならどう見るかと思ってコードを見てみた。
最初に開いたファイルでここまで見て止めただろう: https://github.com/Sleepful/mymail/blob/main/app/router/page...
最初のコメントは作業と無関係で非常に奇妙で、ブログの例からコピーしてきたように見える。いずれにせよ、そのまま残したのは注意不足だ。
2行目の表現は3行目と一貫していない。
ここでレビューを止めただろう。細部への注意不足であり、明確に考える能力を示せていない。
しかし返ってきたのは空っぽの不採用メールだった。
その状況で、コードコメントにもっと時間を使うべきだったという話には同意しがたい。
エンジニアリング面接官として言いたい。LeetCode も課題型も好きではない。どちらも時間がかかるわりに、得られる情報は少ない。
それでもこのケースでは、筆者を不採用にした可能性が高い。Kagi Search はスタートアップであり、こうしたところはたいてい、素早く動ける実用的な楽観主義者で、深さと広さのバランスを取れる人を探している。
以前、入力を集めて数日間こもって解法を作って出てきたら、その間に要件が変わっていた同僚がいた。誰にとっても楽しい経験ではなかった。
課題型選考が本当に嫌い。
「このプロジェクトはコーディングだけでなく、曖昧さやオープンな問題を扱う能力もテストします」という文言は、実際には a) 課題の設計があまりに粗雑で、評価表すら作っていない、または b) 職場環境があまりに混沌としていて、どんな仕様や要件も明確に定義しない、という意味に聞こえる。
さらに「技術を見せつけろ」と「実用的で機能する解法を出せ」という指示は互いに矛盾している。よいシンプルな解法は派手ではない。
HTTP リクエストを作れて、基本的な CRUD 編集画面を作れるということは、ほとんど何も示さない。AI ツールもこうしたものは素早く、かなりまともな品質で作れる。
見たいのは、ぎこちないビジネスロジックをエンジニアがどう実装するかだ。
100 万個のネストした if と「ここにドラゴンあり」コメントになるのか、それとも適切なパターンを見つけて、読みやすく推論可能なコードにするのかを見たい。
こちらのほうが実務でははるかに価値があり、面接でのシグナルも強く、AI が正解しにくく、時間もかからない。
よいシンプルな解法を作ることこそが、実力を示す方法である可能性もある。
それはシニアソフトウェアエンジニアの大きな役割だと思う。
この形式がそれをテストする最善の方法ではないかもしれないが、「曖昧さを扱えるかを見る」というのは、すべての仕事が曖昧だという意味ではない。
すべての仕事が「曖昧な要件」から「明確な仕様」へ向かう過程を経なければならない、という意味かもしれない。