Codility は不正を検知するのか？

あなたが知りたいのは、作業中に何かに監視されているかどうかでしょう。ほとんどの場合そうではありません。より重い分析は、あなたが提出したものに対して行われます。このセクションでは、実際に発生する順序でチェックを追っていくので、タイミングがはっきりします。

テスト中、プラットフォームは行動シグナルを記録します。ウィンドウを離れたときのフォーカスの変化、大きく貼り付けられたブロックのタイムスタンプ、そして各関数を構築した編集の順序です。一部の評価はフルスクリーンを必須に設定しており、本人確認のために写真を撮影するものもあります。

提出後、コードは過去の提出や公開されている解答の集合と照らし合わせて類似度比較が行われます。これが最も重視されるチェックです。なぜなら、よく知られた問題には比較対象となる過去の解答が何千件もあるからです。

類似度比較は同一のテキストを探しているわけではありません。比較されるのは構造です。ロジックの形、変数の使い方のパターン、操作の順序です。変数名を変更したり整形し直したりしても結果は大きくは変わりません。測定されているのは根底にある構造だからです。

だからこそこのチェックは誤検知を生みます。標準的なアルゴリズムを標準的な書き方で書けば、他のあらゆる正しい実装と同じように見えますし、二分探索の書き方にはそれほど多くのバリエーションはありません。審査担当者もそれを分かっているため、類似度スコアが高いことは、ファイルを閉じるのではなく、対話を始めるきっかけになります。

他の適性検査ベンダーについての比較情報は検知性トピックハブにまとめられています。

報告はフラグとともに、あなたのコード、所要時間、編集履歴と一緒にリクルーターやエンジニアの手に渡ります。その先どうなるかは完全に会社次第です。候補者を不合格にする企業もあれば、これを理由に、自分の提出内容を説明するライブの追加ラウンドを設ける企業も多くあります。

ある物流会社に応募したデータエンジニアは、よく知られた教科書的な実装と一致したためフラグが立てられました。フォローアップの通話は十五分で終わりました――彼はアプローチを説明し、求められるとその場で調整し、選考プロセスはそのまま続きました。自分自身のコードを説明できるかどうかが、結局このフラグが試していることなのです。

SubcueAI がライブ面接中に何を記録し、その後何を保存するかについてはセキュリティページに記載されています。

SubcueAI はライブの会話をサポートします。ネイティブの macOS および Windows アプリはシステム音声とマイクの両方をキャプチャし、フローティングのローカルオーバーレイに提案を表示します。ブラウザ拡張機能のサイドパネルは、Chromium ブラウザ上の会議タブに対してライブアシストを行い、そのタブの音声のみをキャプチャします。会議に参加するボットは存在せず、会議ページに何かが注入されることもありません。

Codility の適性検査は会話ではないため、これらは一切当てはまりません。もし検査が監視付きであったり、画面がキャプチャされる場合、オーバーレイはそのキャプチャの中に写り込みます。これは設定の問題ではなく、限界です。SubcueAI が対応するのは、リクルーターとの面談、行動面接、そして通常は適性検査を通過した後に行われる設計に関する議論です。

適性検査そのものに対する有効な準備は、時間を計った練習であり、それは模擬面接ページで行えます。