Interpreting Software Skills Test Results: A Hiring Guide
テストスコアの魅力的な嘘
候補者はExcel testを提出します。彼らは78%をスコアします。データのように感じます。候補者を数値で順位付けして、最高スコアを採用できるようなもの。
実際には、できません。設計が良好な78%は、設計が悪い95%より有用です - ほぼすべてのソフトウェアスキルテストが、スコアの意味を曖昧にする方法で設計が悪いです。
このガイドは、自信を持たずに結果を解釈する方法を紹介しています。
スコアが実際に測定すること(そしてそれがしないこと)
スコアは特定の制約下でのタスクパフォーマンスを測定します
候補者がPower BIダッシュボードテストで82%をスコアしたとき、それは以下を意味します:「これらの条件(このデータ、この時間制限、この観客)では、彼らはこのルーブリックで82%をスコアしたものを生成しました。」
それは以下を意味しません:
- 彼らは次の雇用と同じくらい熟練しています
- 彼らは本番環境で18%遅くなります
- 彼らはパワーBIを82%レベルで理解しています(それが何を意味するにせよ)
- このスコアを異なるテストのスコアと比較できます
スコアはルーブリックに固定されており、絶対的なスキルではありません
2つのシナリオ:
**シナリオA:**ルーブリックは「ダッシュボードはエラーなしで実行(40%)、正しい数字を表示(40%)、専門家に見える(20%)」です。候補者は80%をスコアします。
**シナリオB:**ルーブリックは「エッジケースを処理(30%)、DAXロジックを説明(30%)、パフォーマンスを検討(20%)、将来のクエリを予期(20%)」です。同じ候補者は45%をスコアします。
どちらのスコアも「真」ではありません。彼らは異なる事を測定しています。シナリオBは深い思考を明かします。シナリオAは彼らがタスクを完成させたかどうかを明かします。どちらが重要かは役職に応じます。
実際には:ルーブリックが曖昧な場合(例、「技術スキル:1~5」)、スコアはノイズです。具体的な場合(例、「ゼロによる除算を安全に処理するDAXを書いた」)、スコアはシグナルです。
3つの評価タイプ全体で結果を読む
1.シナリオベーステスト(30~45分)
**何が見えますか:**合格/不合格または単純なスコア。 **それが意味すること:**候補者は現実的な仕事を処理できますか? 何をしますか:
- 合格=良いシグナル。彼らは問題に分別のあるアプローチをしました。
- 失敗=彼らはツールを知らないか、時間圧力下で凍ったかのいずれかです。会話は批判的です。
- かろうじて合格(70~75%)=彼らはそれを理解しましたが、苦労しました。職務が斜面時間またはメンターシップを持っている場合、これは有用なシグナルです。
赤旗:
- 候補者は半時間で見事な仕事を提出します。彼らは答えを見つけたか、慎重になるのに速すぎると働きました?
- 候補者は説明なしで正しい仕事を提出します。彼らは不確実性を隠していますか?
- 候補者は彼らがおそらく理解していない高度な機能を使用して仕事を提出します。(例、機能するが何もコメントがない複雑なDAX式。)
**アクション:**会話+行動インタビュー。テストは能力に「はい」と言いました。今、どのようにして、なぜを聞いてください。
2.テイクホーム評価(2~4時間)
**何が見えますか:**アーティファクト(スプレッドシート、ダッシュボード、コード)と書き込みの説明。
**何を測定しますか:**判断、反復、問題解決プロセス。より長い時間は、彼らが注意深く考えるか、ただ実行するかを明かします。
何をしますか:
- アーティファクトを最初に確認します。使いやすいですか?問題を解決していますか?
- 説明を読んでください。彼らは彼らの選択を正当化していますか?トレードオフを認めていますか?
- 反復の兆候を探してください。彼らは1つの方法を開始して変更しましたか?それは実際の問題解決です。見事な最初のパスは疑わしいです。
スコアが何をキャプチャしないか:
- 彼らがどの程度の助けを得たのか。彼らは友人に聞くか、ChatGPTを使用したかもしれません。ソリューションは評価するのに有用ですが、文脈が重要です。
- 信ぴょう性。監督なしでは、それがそれらの仕事であるかどうかを知りません。
**アクション:**テイクホームを確認のためではなく、深さに使用してください。会話と一組にして、信ぴょう性と推論を検証します。
3.ライブ評価(30~60分、監督または実時間)
**何が見えますか:**時間圧力の下での仕事、おそらく考え方によるか、あなたのプロンプト。
**何を測定しますか:**速度、推論の明確性、割込みを処理する能力、問題解決プロセス結果ではなく。
赤旗:
- 候補者は全時間沈黙しています。彼らはブロックされているか(悪いシグナル)、考えずにタイプしているか(悪いシグナルも)。
- 「なぜ?」と聞くと、彼らは選択を説明することはできません。彼らは考えずにスクリプトに従っています。
- 彼らは正確に時間に完成しています。問題は簡単か、彼らはソリューションを暗記しました。
**アクション:**ソリューションをスコアしますが、会話を50%の重み付けします。70%を得たが推論を明確に説明した候補者は、85%を得たが彼らのアプローチを説明することはできなかった人より強いです。
解釈フレームワーク:スコアを超えて
このフレームワークを任意のソフトウェアスキルテストに使用します:
| 調査結果 | その意味 | 何をするか |
|---|---|---|
| 高スコア+明確な説明 | スキルを持っているため、それを説明できます | 次のラウンドに進みます |
| 高スコア+曖昧な説明 | それを解決しましたが、それが彼ら自身の仕事であるかどうかは不明 | 会話で質問をプローブします。慎重に進みます |
| 中程度のスコア+思慮深いエラー | 彼らはコンセプトを理解しているが、ニュアンスを見落とした | メンターシップがあれば採用のための強いシグナル。彼らは成長します |
| 低スコア+明確な苦労 | 彼らはスキルをまだ持っていません | 役職が必要な場合は再検討してください。コアの場合はスキップしてください |
| 低スコア+イライラ/混乱 | 彼らはスキルが不足しているか、ツールブロッカーにヒットしたか不明 | 会話は重大です。彼らは何をするかを知っていたが、実行できませんでしたか?それとも始める場所を知りませんでしたか? |
候補者を比較する:正しい方法と間違った方法
間違った方法(最も一般的):
候補者A:Excelテストで85% 候補者B:Excelテストで72% **決定:**候補者Aを採用します。彼らは明らかに強いです。
**問題:**スコアはスケール固有です。簡単なテストで85%が難しいテストで72%より弱いです。テストが校正されたかどうかは不明です。
正しい方法:
- すべての候補者に同じテストを使用してください(すでにこれを行っています)。
- 各スコアを他のスコアではなく、ルーブリックに対して解釈してください。
- 候補者A:85%。何がうまくやったか?(速く、正確、クリーンコード?)低くスコアされたのは何ですか?(エッジケースを説明しませんでした?)
- 候補者B:72%。彼らはどこでポイントを失ったのですか?(構文エラー、失われた機能、悪い設計?)
- 彼らが上手に/悪く何をしたかの差を見てください。
- Aが設計で強く、Bが速度で強い場合、それは本当のトレードオフで議論の価値があります。
- テストが簡単だったために85%を取得し、Bが実際に考える必要があったため72%を取得した場合、直感を逆にします。
より良い比較:「候補者Aは上手く実行しましたが、その論理を説明しませんでした。候補者Bは構文に苦労しましたが、強い問題分解を示しました」という候補者を評価して、「85対72」よりも多くを示しています。
一貫性の役割
一貫性は絶対的な精度よりも重要です。テストが一貫して仕事ができる人と仕事ができない人を分離するためにテストが一貫して分離する場合、正確なスコアはセカンダリです。
テストするために誰かが高くスコアした雇用して、彼らのパフォーマンスを追跡してください:
- 高スコアの候補者は役職で成功していますか?
- 低スコアの候補者は苦労していますか?
- 評価のどの側面が職務のパフォーマンスを予測しましたか?
次回のルーブリックを改善するためにそのフィードバックを使用します。悪い採用から良い採用を分離するルーブリックは、「客観的」に感じるものよりも価値があります。
公正性チェック
結果の解釈を始める前に、聞いてください:
- すべての候補者は同じテストを見ましたか?(はい。)
- 彼らは同じ時間とツールを持っていましたか?(通常はい、ただし例外に注意してください。)
- 候補者は不公正な利点を持つことができましたか?(テスト質問の事前知識?オンラインソリューションへのアクセス?)
- ルーブリックは明確で客観的か、主観的か?
何かが不公正に感じたら、結果を注意深く解釈してください。1つの悪い評価は候補者を殺しません。複数の一貫したシグナル。
解釈での赤旗(いつもっと深く掘る)
-
**「このスコアだけでは、この候補者は明らかにフィットではありません。」**間違い。テストスコアは1つのシグナルです。行動証拠、過去のプロジェクト、会話は同等に重要です。テストスコアはノイズの傾向があります(悪い日、不明確な指示、ツール不慣れ)。
-
**「テストスコアは完全に私の直感と一致しました。」**疑わしい。どちらかあなたの直感は素晴らしいか、テストは既に知っていた明らかな何かを測定しています。リアル評価は新しい情報を追加します。
-
**「より高いテストスコアは強く採用されるのと相関していました。」**これはテストが良好であることを意味するかもしれません。または、あなたは高スコアに向かって偏っていました。高スコアの採用が実際に仕事でより良くパフォーマンスしたかどうかを追跡してください。それが検証する唯一の方法です。
-
**「すべての候補者は70~80%の間をスコアしました。」**テストが簡単すぎるか、ルーブリックが甘すぎます。次の時間を調整します。
プロセスの残りの部分との統合
ソフトウェアスキルテストはより広い採用プロセスの1つです:
- **電話スクリーン:**初期実行可能性チェック。彼らは過去の仕事について一貫して話すことができますか?
- **スキルテスト:**彼らは基本的な能力を持っていますか?
- **テイクホーム:**彼らは現実的な問題を解決できますか?
- **行動ラウンド:**彼らはこの仕事をしましたか?彼らは曖昧さをどのように処理しましたか?
- ライブコーディング/システム設計:彼らはリアルタイムで問題を考えることができますか?
- **文化/チームフィット:**彼らはあなたのチームとうまく働きますか?
単一の評価は決定的ではありません。候補者はスキルテストで低くスコアでき、過去の成功の行動インタビューから強い証拠がある場合は採用できます。逆に、過去の動作またはチームフィットが不一致の場合、高いスキルテストスコアは、それらが機能することを保証しません。
文脈内でテスト結果を解釈します。スコアは有用です。スコアだけは誤解を招く。
ソフトウェアスキルを正しく評価すると - ルーブリックは明確で、候補者は彼らの仕事を説明でき、結果は他の証拠と共に解釈されます - 実際の能力を測定します。テストスコアはより少ない謎になり、より有用になります。