DevEvalの仕組み。

1.ルールを明記した招待

候補者は非公開のリンクを開きます。アカウント作成は不要です。招待には、職種、課題の所要時間、AIの利用可否、記録される内容が記載されています。

チームが設定した期間内で開始時期を選べるため、作業はこちらの都合ではなく候補者のスケジュールに合わせられます。

2.課題概要が示された現実的な課題

パズルの代わりに、候補者はその仕事で実際に行う種類の作業に取り組みます。テスト付きの小さなサービス、見つけて直すバグ、レビューする変更、あるいは検証すべきAIの提案です。

課題概要、初期コード、チェックがブラウザ上に並んで表示されます。作業は自動保存され、接続が切れても中断したところから再開できます。

3.エンジニアが実際に働くやり方で

ルールで許可されていれば、候補者はAIを隠さずに使います。チェックを実行し、出力を読み、修正して、もう一度実行します。

• 自分の成果物に対して実行可能なチェックを実行する
• 制約を付けてAIに指示する、あるいはその提案を断る
• 出力が実際に何を証明しているかを確かめる
• 何をリリースすると決めたかを説明する

4.判断メモを添えて提出

候補者は時間切れになる前に、何を変更し、何を検証し、まだ何を確認したいかを短いメモにまとめて提出します。先に時間が尽きた場合は、それまでに保存された作業が自動で提出されます。

確認メールが届くため、提出が完了したかどうか不安になることはありません。

5.費やした時間に報いるフィードバックを

レビュアーの承認後、チームは非公開の候補者成長レポートを共有できます。根拠に基づく強みと役立つ次のステップを示し、社内の評価は開示しません。

1.スコアだけでなく、根拠パケットを

各提出物には、コード、テスト結果、プロンプトとAIの提案、セッションのリプレイ、候補者の判断メモ、そしてフォーカスの切り替えや貼り付けなどのインテグリティ情報が含まれます。

インテグリティのイベントは人が読むための状況情報であり、それだけで不正と判断するものではありません。

2.確認できたこと、できなかったことを明示

実行可能なチェックは、作業が何を証明したかを示します。課題で証明できなかった点はパケットにそう記載されるため、ローカルでの良い結果が保証と誤解されることはありません。

• どのチェックが通過し、どれが一度も実行されなかったか
• 候補者が実際の問題に気づいた箇所
• 確認せずに提案を受け入れた箇所

3.ライブでのフォローアップ用の具体的な質問

不足している点はそれぞれ、短いライブ面接のための的確な質問になります。面接官は評価全体を繰り返すのではなく、何を聞くべきかを把握して臨めます。候補者も、根拠が薄かった部分で深い理解を示す機会を得られます。

4.スコアカードと記録された判断

レビュアーはメモを追加し、スコアカードを記入して、判断を記録します。評価、根拠、ライブ面接、結果は一つの履歴としてつながり、チームで共有することも社内にとどめることもできます。