私も候補者に持ち帰り課題を出す立場として言わせてもらうと、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はパロアルトに拠点を置いています。

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

要件を読む能力が深刻に欠けている。どの要件が満たされていなかったの？ - メールクライアントはターミナル（つまりTUI）かウェブアプリのどちらでも良い - 基本的なメールの閲覧と送信機能が必要 どちらも十分に満たされてると思うけど。既存のツールからのインスピレーションは主観的だよね。バックエンドのポジションでUIに時間をかけるのが、テイクホームテストで自分のスキルをアピールする最善の方法だとは思わなかった。

それでも、候補者としては、何時間も働いてテンプレートメッセージで拒否されるのは辛いよね。少なくとも、私の仕事がなぜ気に入らなかったのか理由を教えてほしいな、そうすれば何か学べるから！採用マネージャーがホットな役職のために何百もの応募をレビューするのは現実的じゃないことも分かるけど、それが持ち帰り課題がダメな理由なんだ。候補者が無駄に何時間も過ごすことになるかもしれないし、両方の側が他の人の時間を尊重する必要があるよね。

「メールクライアントはターミナル（つまりTUI）かウェブアプリのどちらかにできます」

うん、拒否のメールにもう少し明確な説明があれば良かったし、提案に対する警告があっても良かったかも（ただ、提案だけではOPがその課題の一部を無視する道を進むとは100%明確ではないけど）。でも、プロンプトには他のターミナルクライアントがインスピレーションとして明記されている。また、ターミナルクライアントのプロンプトは、彼らが何をテストしているかを本当に変える！メールのウェブUIは何年も前から知られているものだから。でも、ターミナルクライアントのUXはまだ「解決済み」ではない。質問のルーブリックには、OPの提出物が全く触れていない部分が大きく含まれていると思う。

それに、Goプログラミングに重点を置いているようですが、CLIを動かすのに20行未満で済むのに、なぜブラウザのGUIを選んだのか、正直よくわかりません。

「メールクライアントはターミナル（つまりTUI）かウェブアプリのどちらかにできます」

4についてだけど、著者が共有した完全版には「ターミナルにインスパイアされた」という意味についての情報があるよ。https://archive.md/A95Ju

言い換えれば、著者は良い仕事をしたけど、あまり頑張りすぎないという暗黙の要件があったために失敗した。> 課題の一部には判断力を使ったり曖昧さの中で働くことが含まれている。要件を明確にしようとするのが彼らが望んでいたことではないのなら、候補者に1から10の間の数字を選ばせて、間違ったら拒否するようにすればいい。> インフラと仕上げが過剰だというのは意見だと知っているけど、両方に強く反対する。持ち帰りテストは自分の能力をアピールするためのもの。具体的なガイダンスがないと、誰がどれくらいアピールすることが期待されているのかを推測できる？仕上げが納品を妨げる場合のみ悪い。あまりにも「仕上げが過剰」として拒否されるのは、誰かが良い仕事をしすぎたと言っているように感じる。--- 私の意見では、こういう曖昧な要件のテストは、「カルチャーフィット」でない人を拒否する別の方法になりがちだと思う。

ブログの著者のやり取りの態度もなんだかおかしい感じがします。このブログ記事を読むだけで、この人と働くのは難しそうだな、すごく明確なガイドラインや指示が必要で、自分で決断するのが苦手なんじゃないかと思います。大企業には合うかもしれませんが、スタートアップには独自のニーズがあります。「顧客と一緒にアルファテストを行うために、ターミナルにインスパイアされたメールクライアントを作成してほしい」というのは、初期段階のスタートアップのエンジニアにとっては妥当な要求です。もちろん、もう少し具体的な指示はあるでしょうが、多くの詳細はエンジニアに任されるでしょう。この応募者は、自分が得られる以上の確実性を求めています。「完成に向けて進めた場合、Kagiからどんな反応が期待できるのか知りたい」という一文がそれを示しています。これはあまり良いリクエストではありません。その質問には答えられないでしょう、なぜなら確実性がないからです。おそらく、評価するための応募が数百件か数千件も来ているでしょう。

課題の一部は、判断力を使い、あいまいな状況で働くことです。業界が要件を集めるのがこんなに下手になってしまったのは、開発者が今や実質的に心を読む能力でフィルタリングされているからだと思います。

採用者として、私が出したいテイクホーム課題のタイプは、以下のようなものです： * 熟練したプログラマーが30分で完了できる * 客観的かつ主観的な明確な評価基準がある * 異なるトレードオフを必要とする複数のアプローチがある そしてもちろん、結果が重要な候補者にのみ出します。私が最後に仕事を探していたときに受けたこういう広範なテイクホーム課題では、私は自分が過剰資格を持っている仕事の課題に失敗しました。なぜなら、非常に広範な課題のどの部分で評価されるかを見抜けなかったからです。今後、紹介以外で仕事を得ることができるとは思えませんが、こういう課題には本当に嫌気がさしました、受けるのも出すのも。

私の意見では、著者のアイデアを検証するアプローチは、現代のエンジニアリングのワークフローを反映しています。コーダーは、MRを独立して何時間もコーディングしてから、機能が「完成」した後にプロダクション、テックリード、QA、UXからフィードバックを受けることはありません。「先にコーディングして、後でレビュー」という作業環境は、私のキャリアの中で最も有害なものの一つでした。数日間かけて機能を構築したのに、それが必要ないとわかるのは本当に辛いです。だから、機能を英語で説明して承認を得ることが、プロジェクトを出荷するための業界標準なのです。この候補者は、健全な職場が従う現代のソフトウェアプラクティスに従っていました。（私は1,000人以上のエンジニアがいる会社の採用マネージャーでもあります。）

彼が沈んだのは、巨大な提案（何度も質問された後）だったと思う。指示には提案を求める内容は書かれていなくて、特にあんな詳細なものを提出することで「OPは事前に承認を求めずに自分から進めることができない」って印象を与えちゃった。プロジェクトは、いくつかの質問をして、いくつかの仮定を挙げて、自分自身に承認を与えてあいまいなものを自信を持って作り始めることだったんだ。もしかしたら間違ってるかもしれないけど、そのメールが送られた後はコードなんて関係なかったと思う。会社は彼が課題を作るのに無駄な時間を使う前に、そこで終わらせるべきだった。

それに、彼は締切を逃した。 >納品日：3月30日（日）EOD、 >これはあなたが最初のメールを送ってからの2週間のマークよりも2営業日遅れています。遅延の個人的な理由がない限り、私の中ではすでに拒否です。目的は、締切内に適切な解決策を設計することだった。

こういうことは後から言うのは簡単だけど、逆の戦略を取った場合も同じ結果になったかもしれない（要求を明確にせず、最低限のことだけをやる）。誰かが「候補者は要求を明確にすべきだったし、最低限を超えるべきだった」と言うレスを投稿することも十分に考えられるよね。

この話の問題は、候補者が拒否されたことではなく、明確なガイドラインもなく、貴重なフィードバックも与えずに多くの無給の時間を要求するプロセスが大いに失礼だということだ。

自分のドメインにアプリをデプロイしたけど、機能に問題はなかったよ。すごく時間がかかったけどね。認証やインフラストラクチャー・アズ・コードみたいなバックエンドの役割に典型的な追加機能も含めたんだ。僕の努力の結果、空の拒否メールが来た。で、君は僕がコードのコメントにもっと時間をかけるべきだったって言ってるの？その意見には賛成できないな。

それは「これはR&Dプロジェクトです」と「最小限」という文脈以上のものがテイクホームに設定されていれば、正当な指摘かもしれない。ここで何を達成したいのか、これは使い捨てのプロトタイプなのか、それともユーザーが見ることになるのか？不完全なUXで叩かれるのか、それともただ何かを見たいだけなのか。レビューアの感覚を推測する練習になってしまう。

完全に同意する。課題は、できるだけ最小限に賢い機能的な解決策を作る人を探しているように見える。面接で印象を与えたいのに「怠ける」ことを恐れない人。これはあまり一般的な特性ではない。でも、もしあなたの会社がプロトタイプ駆動のアプローチで迅速な「実験」リリースをしているなら、そういう人はフィットしないことが多くて、みんなにとって悪いことだ。おそらく、ある候補者は10分考えて「60分で何ができるか」を考えたんだろう。彼らはおそらくHTTP認証やフォームを使って、それを小さなGoバックエンドで処理し、簡単なメールで送った。そして、そのプロセスでずっと良く見えたに違いない。

... そして、こういう「自分で選ぶ冒険」みたいな課題では、サブテキストを「読み間違えた」せいで多くの人が落とされることになるんだよね。要求を押し続けるのはエンジニアにとって非常に重要な美徳なのに！人生は公平じゃないけど、採用マネージャーにはもっと期待してるみたい。だから、人生が公平じゃないからこそ、私たちは採用マネージャーに失望し続けるんだ。

サブテキストを読み間違える それはテキスト自体にちゃんと書いてあるよね。

大学で働いている者として、これは課題を理解できない学生が、予想外の成績をもらって文句を言うのを思い出させるね。これは指示を出す側にとって、すごく怠惰で都合のいい結論だよ。学生が課題を誤解するもう一つの理由は、彼らが心を読むことができないからで、指示が下手に書かれているからだよ。良い教師は、できるだけ多くの学生に理解されるようにする人だ。悪い教師はその逆。僕の良い教師たちのもとでは、最初から成績について疑問を持つことはなかったよ。だから、混乱している学生が多いなら、君が共通の要因かもしれないね。仏教の僧侶は、謎を解いたり、コアンと呼ばれる暗号的なメッセージの意味を推測したりして学ぶんだ。だから、学費を払っている学生が同じような扱いを受けるべきではないってことで合意しよう。

たくさんの会社が「自分と同じように考える人」を雇いたがってるみたいだけど、個人的にはそれは間違いだと思う。問題に新しい視点を提供するためには、多様な考え方が必要なんだよね。みんなが同じ考え方をしていて、一人が行き詰まったら、みんなが行き詰まる可能性が高い。これはスタートアップに共通する問題だと思うし、9割のスタートアップが失敗する理由の一つかもしれない。

僕が気に入らないのは、ヴラドが「クール」な人を見つけるために、他の人の時間を無駄にしていることだよ。これは、僕が人の能力を試すテストをするのとは全然違う。ここでは、君が知らされていない指標で良いスコアを出したら合格なんだ。まるで「何かをコードしてみて - 曖昧さに慣れていないとダメだよ！」っていう宿題を出すのと同じだよ。冗談だけど、僕が考えていたことを当てるだけなんだ。これは人に対してすごく配慮が足りないし、このヴラドって人について良いことは何も教えてくれないね。

こんにちは :) > 彼にとって、長いデザインドキュメントを提出して「ガラクターを使います。プロジェクトをフロルプ準備します。フリームします。」って言うのは、クールの真逆なんだ。これくらいを推測しなきゃいけないの？彼らは僕がこれを理解するために、SNSをこっそり見ることを期待してるの？最後に、僕が全然クールじゃないってことをはっきり言ったのに、ただ好奇心を満たすために「進めていいよ」って言われても…彼らが他の人に対してするように扱われることを願ってるよ。君に対して悪意はないけど、むしろ君が僕にとっては納得のいく説明をしてくれてるからね。もっと早く自分と同じような投稿に出会っていればよかったな。僕たち全体で、「テイクホーム」ってついてる仕事は「クールな子たち」のための仕事としてカテゴライズし始めることを願ってる。そうすれば、退屈で経験豊富なエンジニアたちが、実際に僕たちの労働を望むなら、企業に適応を強いることができるかもしれない。適応しない企業は、その役割を「提供」するタイプの企業が分かるね。