コーディングのテストを作る

What you'll need

• SkillCort のワークスペース（またはデモ）
• あなたのチームが実際に書くコードの例 — 一つの不具合、小さな機能、書き直し
• 課題と評価ルーブリックを定める先輩のエンジニア
• どの言語を受け付けるかの決定

Step 1: アルゴリズムのパズルより、現実味のある課題を選ぶ

この 1 か月の変更依頼を見て、繰り返し現れるものと同じ形の課題を選んでください。うまく動かない挙動を手がかりに不具合を直す、小さな関数を新しい場合に対応するよう広げる、散らかった部分を書き直す、データの変換を書く。こうした課題は、二分木を反転させる問題よりはるかによく、日々の働きぶりを見せてくれます。

力のある人が集中して 30〜45 分で終わる大きさにしてください。パズルは、それを練習した人に報います。現実味のある小さな課題は、既存の意図を読み取り、筋の通った変更を加え、コードを分かるままに保てる人に報います。あなたが採ろうとしているのは、そういう人のはずです。

その職務が本当に必要としているのでない限り、特定の枠組みや自社に固有の知識は取り除き、課題に要る文脈は課題文の中に入れてください。あなたの技術の組み合わせに触れたことのない優れたエンジニアでも、筋の通った判断を見せられるべきです。測るのはスキルであって、自社のコードの細かな事情への慣れではありません。

• 面接対策の本ではなく、実際のコードで繰り返し現れること
• 筋の通った解き方が一つ以上あること
• 無理をせずに 30〜45 分に収まること
• 評価者が 10 分以内に読めること

Step 2: 問題バンクにコードの設問を作る

その職務のためのフォルダ — たとえばバックエンドのエンジニア — を作り、スキルの領域と難しさのタグを用意したうえで、コードの設問の種類で設問を作ります。候補者は回答欄で直接コードを書いて直し、評価者はあとでその場のまま確認します。

空の編集画面ではなく、出発点のコードを置いてください。不具合の説明が付いた短い関数や、約束事のはっきりした骨組みがあれば、すべての候補者が同じ地点から始めるので、加えた変更をそのまま比べられます。実際の仕事が空のファイルから始まることはほとんどありません。テストもそうであるべきです。

Step 3: 編集画面の隣に課題文を書く

左右に並べた画面を使ってください。片側に課題文、要件、入出力の例、その隣にコードの編集画面です。候補者は仕様から離れてスクロールすることなく解答を書けます。開発環境でチケットを見ながら働くのと同じ形です。

課題文は良いチケットのように書いてください。いまの挙動、期待される挙動、制約、そして具体的な例が二つか三つ。何を大切にしているのか — 「まず動くコード。読みやすさも見ます」 — をはっきり書けば、候補者は実際に採点されるものに力を注げます。課題文の曖昧さは、結果の雑音になります。

Step 4: 正しさ以上を採点する評価ルーブリックを作る

正しい出力は必要ですが、それだけでは足りません。三つか四つの基準 — たいていは正しさ、読みやすさ、進め方、必要なら境界の扱い — を持つ、水準で刻んだマトリクスの評価ルーブリックを作り、強い、許せる、弱いコードがそれぞれどう見えるかを、手がかりのある記述で示してください。「名前が意図を語り、使われないコードがない」は採点できますが、「きれいなコード」は採点できません。

正しさを最も重くしつつ、他の基準も本気で扱ってください。かろうじて動くけれど誰にも手入れできない解答は、良い採用のしるしではありません。評価ルーブリックを結び付けるとその内容が固定されるので、あとで問題バンクの版が変わっても、その回のすべての候補者は同一の基準で確認されます。

Step 5: ビルダーで組み立て、時間を区切る

アセスメントをセクション、ページ、ブロックとして作り、選択画面からコードの設問を取り込みます。多くのチームは、短い判断の設問 — 差分を読む、断片のなかの不具合を見つける、といった多肢選択を貼り付けで取り込んだもの — を最初のセクションに置き、コーディングの課題は独立したセクションに置きます。

全体の制限時間は読んで考える余裕を見て決め、コーディングのページにはページごとの制限を設けて、その課題が受験全体を飲み込まないようにします。コーディングのセクションの重みを最も大きく（たとえば 3 倍に）しておけば、Decision Board の職務適合度が助走ではなく実際の取り組みを映します。案内には、使える言語と、時間が尽きたときにどうなるかを書いてください。

Step 6: 下見し、チェックリストを片づけ、公開する

候補者と同じ画面の下見で自分でも課題に取り組んでください。できれば、それを書いていないエンジニアに、前もって知らせずに解いてもらうほうが良いでしょう。10 分で終わるなら簡単すぎますし、制限のなかで終わらないなら、範囲か時計をゆるめてください。相手が迷ったところは、どこでも課題文を直します。

そのうえで公開のチェックリストを満たします。採点、時間、案内がそろうまで公開は止められます。評価ルーブリックのないコーディングのテストや、試していない制限時間のテストが候補者に届くことはあってはなりませんし、チェックリストがそれを防ぎます。

Step 7: 重要度に見合った不正防止の手立てにする

名前と期間を付けて配信を作り、そのうえで守りの切り替えを意図的に選びます。ふつうの採用の選考なら、複写と貼り付けの遮断と、ほどよい違反の上限を伴う全画面の Lockdown でたいてい十分です。カメラの録画、画面の録画、二つ目の画面の検知、身分証の確認は、本当に重みの大きい回 — 資格認定や最終選考 — のためにあり、既定として置くものではありません。

有効にしたものはすべて、候補者が始める前の同意と事前確認の画面で伝えられます。不正防止のシグナルは、人が文脈のなかで確認するための印であって、自動の不合格の根拠ではありません。全画面から出たのは通知のせいであって、不正ではないかもしれません。重要度に見合っていることが、良い候補者が監視の網から立ち去ってしまうのを防ぎます。

Step 8: 評価ルーブリックでコードを確認し、AI は支えに使う

評価者は共有の評価ルーブリックに照らして提出物を確認し、正しさ、読みやすさ、進め方のそれぞれで、そのコードに合う水準のカードを選びます。際どい場合や重みの大きい場合に確認者を二人置けば基準は正直に保たれますし、全員が同じ固定された評価ルーブリックで採点するので、意見の違いは漠然とした肌感覚の差ではなく、特定の基準の差として姿を現します。

AI は提出物の要約と基準ごとのスコアの案を下書きできます。コードに対しては本当に役立つ一次の目であり、モデルと版は記録に残ります。ただし一つひとつのスコアを確かめるか上書きするのは、記名されたエンジニアです。ここでも AI は判断の支えであって、決める者ではありません。候補者のコードについて責任を負う判断は、常に人のものです。