私も候補者に持ち帰り課題を出す立場として言わせてもらうと、Kagiの課題は大きすぎて、候補者の時間を無駄にしていると思う。おそらく意図せずに、こういうプロジェクトに時間をかけられる候補者をフィルタリングしているんじゃないかな。忙しい人（あなたが求めているタイプの人）は通過しちゃうし。候補者のスキルを把握する方法は他にもあるはずだよ。私たちの場合、データエンジニアリングのスキルを持つ人を採用するために、シンプルなETLチャレンジ（zipファイルからデータを引っ張ってきて、変換して、任意のデータベースに挿入する）をお願いしている。そこにはあえて曖昧さを残していて、データセットにはいくつかのイースターエッグ（例えば、予想外のnull値や、フォーマットが間違っているCSVなど）があって、それを使って候補者のパフォーマンスを評価している。時間は4時間に制限しているけど、時間が足りなくなった場合のガイダンスは与えないのが良い提案だね。フォローアップの電話では、一緒にコードをレビューして、コードを改善する方法について質問する（「もしデータセットがメモリに収まらなかったらどうする？」など）というのが、実際の技術評価になる。ここまで来ると、候補者は問題領域に少しは慣れているはずで、彼らの本当のスキルを評価できる。

面接を受ける人たちがもっと時間をかけていないってどうやってわかるの？全ての候補者が同じ時間をかけている保証はないから、ゲーム理論の問題になっちゃう。候補者は通常、何らかの形で負けることになる。多くの場合、正しい答えは、ほんとに洗練された（でもあまり洗練されすぎない！）解決策を作るために余分な時間を使って、時間制限内に収まったフリをすることだよ。そして、すべての候補者は、a) そうしているか、少なくとも b) 競争相手がそうしているのを心配している。あのダイナミクスを無視しても、3時間は候補者が過ごすには長すぎる時間だよ。1時間の面接なら、プログラミングの演習を通して、余分な時間をかけていないことが保証できる。そして、もし彼らが持ち帰りの評価を好むなら、後で更新した回答を送ってもらうこともできる。（でも、候補者がそれを聞いてくる頃には、すでに彼らのスキルについて好意的な見方を持っていて、「やりたいならどうぞ、でももう私のテストは通過してるよ」と言える。）候補者と面接官の時間投資を同じにすることで、候補者の時間を自分の時間と同じように尊重していることを保証できる（だって、彼らと一緒にいるわけだから）。興味のない部分はスキップさせる手助けもできるし（例えば、検索で見つけられる情報を教えたり、特定の詳細について心配しないように伝えたり）。もし採用マネージャーが候補者の時間を尊重しないなら、彼らが従業員の時間を尊重する可能性はどれくらいあるんだろう？

著者に同意するけど、ライブコーディングよりもライブコードレビューの方がずっと良いと思う。でも、もし企業がライブコーディング演習にこだわるなら、私のノートパソコンとマウスを持って行かせて、45分間部屋を出て、作ったものについて話せるときに戻ってくるっていうのはどう？

UIやAPI統合があるテイクホームはちょっと赤信号だと思う。なぜなら、UIコード（ほとんどの役割において）は比較的退屈だし、API統合は手間がかかる割にあまり情報を提供しないから。HTTPリクエストを作れるのはすごいし、基本的なCRUD編集のセットアップができるのもすごい。でも、それはたくさんのコードで、時間もかかるし、あなたのコーディングスタイルについてほとんど何も教えてくれない。AIツールはそんなものをすぐに生成できるし、かなりの品質でね。私が見たいのは、エンジニアがちょっとしたビジネスロジックを実装するところ。ネストされたif文が百万個できて、「ここにドラゴンがいます」ってコメントが上にあるのか、それとも正しいパターンを見つけて、コードを読んでいても理解できるものを作るのか。これは仕事においてはるかに価値があるし、面接でももっと信号が強いし、AIが正しくやるのはずっと難しい。しかも、時間もかからない。

いろんなプロジェクトがあるスタートアップだよ。作業環境が混沌としているのは予想されること。驚きのない仕事を求める人は、こういう職場には応募しない方がいいかもね。> 良いシンプルな解決策は派手じゃない。スキルを見せつけるって、良くてシンプルな解決策を作ることかも？

何の仕様や要件も明確に定義されていない。もし採用される役割の一部が、人々が仕様や要件を明確に定義する手助けをすることだとしたらどうなる？それはシニアソフトウェアエンジニアであることの大きな部分だと思う。もしかしたらこの形式がそれをテストするのに最適ではないかもしれないけど、「誰かがあいまいさに対処できるかどうかを見たい」というのは、すべての作業があいまいであることを意味するわけではないと思う。すべての作業が「あいまいな要件」から「明確に定義された仕様」に移行するプロセスを経る必要があるということかもしれない。

本当に「卓越した解決策」を提供したの？彼らの解決策は「最小限の、ターミナルにインスパイアされたメールクライアント」とは全く異なるように見えるし、OPは「インスピレーションを得るべき」と言われたツールへの言及を完全に無視している。要件の理解がこんなに悪い場合、私もその議論に時間を無駄にしないだろう。

私は何度もテイクホーム課題を出す側にいたことがあり、テイクホーム課題をお願いするなら、必ずコードについて話し合うべきだと固く信じています。それは本当に妥当な意見ですね。テイクホーム課題は、出す側だけでなく、面接官（あるいは採用チーム）にもかなりの労力を必要とします。プロジェクトをレビューするために時間と労力を投資した後、フィードバックや返事を期待するのは合理的です。しかし、現実も認めなければなりません。1つのポジションに対して20人の優秀な候補者がいる場合、多くの有能な人が落とされてしまいます。これは彼らが不十分だったり「失敗」したということではありません。ただの現実です。採用マネージャーがAを選んでBを選ばなかった理由を正当化するよう求められるのは、法的には「素晴らしい候補者の中から1人を選ばなければならなかったから選んだ」というのは通用しません。法的に正しい回答（残念ながら）は、細かいところを突いて、実際には存在しない欠点を見つけることです。少なくとも、私が見てきたアメリカの企業がこういう風に運営されるのが好きなようです。そして、最後に確認したとき、Kagiはパロアルトに拠点を置いています。

同意する。会社はプロジェクトがどのように評価されるかについて明確なガイドラインを公開するか、何がもっと良くできたかについてフィードバックを提供すべきだった。課題で失敗するのは構わないけど、何も返さずに誰かの時間を無駄にするのは受け入れられない。ポップスタートアップを含め、これをうまく処理している会社はたくさんある。