AIエンジニアのテイクホームアサインメントで「動くものを作ること」を求めると、LLMに全部生成させたものが来る。確認すべきは判断の跡だ。

AIエンジニア採用でテイクホームアサインメントをどう設計するか

思考版1 AI執筆

AIエンジニアのテイクホームアサインメントは、設計を間違えると意味がなくなる。

LLMを使って仕事をするエンジニアが増えた今、「動くコードを提出させる」だけでは何も確認できない。

従来の設計が機能しなくなった理由

以前のテイクホームアサインメントは「一定の技術力があれば解けるが、LLMに丸投げすると動かないコード」を前提に設計されていた。

今は「LLMに正しく指示すれば、動くコードが出てくる」のが前提だ。

「このAPIを使って音声認識システムを作ってください」という課題を出すと、LLMが生成したコードをそのまま提出する候補者が出てくる。そのコードが動いていても、候補者がそのコードを理解しているとは限らない。

「判断の跡」を確認する設計

有効なテイクホームアサインメントは「判断を記録させる」構成にする。

具体例： 「この仕様に対してシステムを作ってください。合わせて以下を提出してください：

  1. 作る前に検討した選択肢（3つ以上）とそれぞれの長所・短所
  2. 最終的に選んだ理由
  3. 実装後に「もっと早く知りたかった」と思ったこと」

コードではなく「なぜそのアプローチを選んだか」を見る。LLMにコードを生成させることはできても、「自分がなぜそのアプローチを選んだか」の記録は自分でないと書けない。

AIエンジニア採用に特化した課題の設計

プロンプトエンジニアリングを確認する場合

「このユーザーフィードバック100件を分類して要約するプロンプトを設計してください。プロンプトの変遷も記録してください」

確認するのは、最初に試したプロンプトと、どう改善したかのプロセスだ。

RAG設計を確認する場合

「100ページのPDFから特定の情報を正確に抽出するシステムの設計書を書いてください（実装不要）。精度とコストのトレードオフについて考慮した内容を含めること」

設計書は実装より判断が見えやすい。

LLMコストの最適化を確認する場合

「同じタスクを処理するコードを、コスト優先と精度優先の2パターンで設計してください。それぞれの想定コストと精度の見積もりを付けてください」

設計で避けるべきパターン

避けるべき1：時間をかければ誰でも解けるもの

「完璧な解答を作る能力」ではなく「限られた時間でどう判断するか」を見る。提出期間は2-3日が適切だ。

避けるべき2：採用候補者の本番業務に使えるもの

実際の業務課題に近いテイクホームアサインメントは、無料の労働力になる。候補者もそれを察して「使われると思うとやる気が出ない」という感想になる。

避けるべき3：評価基準が曖昧なもの

採用チームが「良い提出物」について事前に合意していない課題は、評価時に「なんとなく好き/嫌い」で判断になる。評価基準を先に書いてから課題を設計する。

関連記事