Валидность и справедливость теста программного навыка при найме

Проблема валидности, которую никто не хочет признавать

Ваша компания использует оценку Excel для ролей финансовых аналитиков. Кандидаты набирают высоко, вы их нанимаете, они на борту, шесть месяцев спустя вы замечаете: нет корреляции между баллами теста и фактической производительностью.

Некоторые высокие баллисты теперь ваши лучшие исполнители. Некоторые борются. Некоторые низкие баллисты оказались компетентны после обучения.

Ваш тест не измеряет производительность работы. Это измеряет что-то — способность теста, предыдущее воздействие конкретному инструменту, комфорт под временным давлением — но не то, о чём вы забуду.

Это проблема валидности. И она распространена, потому что никто не валидирует тесты программного навыка после развёртывания.

Что действительно означает валидность

Тест валиден, если он измеряет то, что претендует измерять, и предсказывает производительность на работе.

Ваш тест Excel претендует измерять "навык Excel для финансового анализа." Это то, что он измеряет?

• Предсказывает ли высокий балл, что человек произведёт точные финансовые модели?
• Предсказывает ли низкий балл, что они будут бороться?
• Или балл предсказывает что-то ещё (уверенность, скорость теста, предыдущий опыт Excel)?

Валидность не о том, сложен ли тест или легко. Это о том, предсказывает ли тест будущую производительность.

Тривиальный тест может быть валиден, если он разделяет людей, которые будут успешны, от людей, которые нет. Сложный тест может быть невалиден, если высокие баллисты не действительно превосходят низких баллистов на работе.

Как валидировать свой тест (после того как вы его использовали некоторое время)

Подождите шесть месяцев после найма людей через вашу оценку. Затем:

1. Отследите производительность на работе 10–20 людей, которые прошли тест:

   • Высокие баллисты (80%+): сколько работают выше ожидаемого? (Отследите ratings производительности или результаты проекта.)
   • Средние баллисты (60–79%): тот же вопрос.
   • Низкие баллисты (ниже 60%): тот же вопрос.

2. Ищите корреляцию.

   • Сильная валидность: высокие баллисты непропорционально успешны. Низкие баллисты непропорционально борются.
   • Слабая валидность: баллы везде. Высокие и низкие баллисты успешны и не успешны поровну.

3. Определите, что тест действительно предсказывает.

   • Если высокие баллисты превосходят при построении формулы, но борются с мышлением качества данных, ваш тест валиден для формул, но не для анализа.
   • Если высокие баллисты быстры, но не лучше при рассуждении, ваш тест измеряет скорость, а не навык.

4. Слушайте менеджеров по найму.

   • Спросите вашу команду: "Люди, которые хорошо набирают на тесте, работают хорошо на работе?" Если они говорят нет, у вас проблема валидности.

Это не идеальная наука, но это превосходит предположение, что ваш тест валиден, потому что он кажется сложным.

Проблема справедливости: кого ваш тест дает преимущество

Справедливость не означает, что тест легко для всех. Это означает, что тест не дезавантажирует людей на основе атрибутов, не связанных с работой.

Тест несправедлив, если:

1. Он требует предыдущего воздействия точному инструменту (инструмент-специфичное смещение)

Пример: "напишите меру Power BI с использованием CALCULATE и логики контекста строки."

Кандидат, использовавший Tableau пять лет, бомбит этот тест, даже если они более сильный аналитик. Они знают концепции; они просто не запомнили синтаксис Power BI.

Исправление: тестируйте концепцию (условная агрегация), а не синтаксис. Позволяйте кандидатам объяснить подход в pseudocode, если нужно.

2. Это предполагает культурный или социоэкономический контекст (смещение происхождения)

Пример (менее распространено сейчас, но случается): "бизнес-аналитик должен представить квартальные результаты совету. Постройте для этого контекста dashboard."

Кандидат с небизнес-происхождением может не знать, что "квартальные результаты совету" подразумевает. Они построят другой dashboard, набирают ниже и отклоняются — не потому что им не хватает аналитического навыка, а потому что им не хватает бизнес-контекста.

Исправление: обеспечьте контекст. Не предполагайте предыдущий опыт с корпоративным отчётом.

3. Это штрафует присмотр или временные ограничения (смещение доступа)

Пример: 6-часовой take-home тест.

Кандидат с ответственностью за присмотр может набирать ниже на 6-часовом тесте не потому что им не хватает навыка, а потому что они не могут найти 6 неинтерруптированных часов. Кандидат с гибким дневным заданием может делать это легко.

Исправление: отрегулируйте пределы времени или предложите синхронные варианты. Два часа сфокусированной работы измеряют навык лучше, чем шесть часов прерванных.

4. Это требует доступа программному обеспечению или стабильности интернета (смещение инфраструктуры)

Пример: live Power BI dashboard-тест, который требует высокую пропускную способность сотрудничества и плотную latency.

Кандидат в регионе с плохим интернетом будет бороться независимо от навыка. Они набирают ниже, отклоняются и отклонение не связано с их способностью.

Исправление: предложите offline альтернативы (локальный PBIX файл, отправка email) или признайте барьер инфраструктуры в интерпретации.

5. Это предполагает беглость английского для не-английских говорящих (смещение языка)

Пример: тест с комплексными письменными инструкциями на английском, даже для роли, которая не в основном о письме по-английски.

Говорящий не-натив может набирать ниже, потому что они неправильно поняли инструкции, не потому что им не хватает технического навыка.

Исправление: простые, прямые инструкции. Предложите уточнения. Оценивайте работу, не качество письма.

6. Это использует нервность (смещение контекста)

Пример: 30-минутный live кодирующий тест с вами смотрящим.

Тревожный кандидат может заморозить и произвести плохую работу, даже если они компетентны. Уверенный кандидат произведёт сильную работу под тем же давлением.

Исправление: сочетайте live оценки с take-homes. Take-homes измеряют мышление; live оценки измеряют производительность под давлением. Оба валидны; просто не переоценивайте один.

Построение более справедливой оценки

Используйте этот чек-лист перед развёртыванием любого теста программного навыка:

• тестирует ли это навык или инструмент? Если вам нужно аналитическое мышление, тестируйте это. Не делайте это зависимым от знания Power BI конкретно.
• Это предполагает предыдущий контекст, который я не измеряю? Если роль требует бизнес-контекста, включите onboarding. Не штрафуйте людей, которые еще не имеют это.
• Время реалистично для разных жизненных ситуаций? Кто-то с ответственностью за присмотр может завершить это? Если нет, отрегулируйте время или формат.
• Инструкции ясны в простом языке? Говорящий не-натив понял бы, о чём просится?
• Оценка позволяет разные пути к одному ответу? Если Excel и Google Sheets оба работают, не штрафуйте пользователей Sheets.
• я измеряю навык или уверенность? Высокие баллы коррелируют с уверенностью или фактической способностью? Запустите быструю проверку валидации.

Специальный случай: инструмент-специфичный vs концепция-базованный тесты

Некоторые роли подлинно требуют специфичные инструменты. Финансовый аналитик в компании, которая использует Excel обширно вероятно нуждается в навыке Excel.

Но будьте явны об этом.

Тест инструмент-специфичный: "эта роль использует Excel ежедневно. Мы протестируем Excel конкретно."

• Справедлив к кандидатам, которые знают Excel
• Несправедлив к кандидатам, которые знают концепции в других инструментах
• Уместен, если профессионализм инструмента действительно требуется

Концепция-базированная оценка: "мы заботимся об анализе данных и моделировании. Вы можете использовать Excel, Google Sheets или Python — что вам удобно."

• Справедлива через фоны инструмента
• Измеряет основной навык
• Уместна, если выбор инструмента гибкий

Оба валидны. Просто будьте ясны о том, что вы делаете.

Валидность и справедливость не противостоят — они связаны

Тест может быть валиден, но несправедлив (высокие исполнители на тесте работают хорошо на работе, но тест дает преимущество определённых групп). Тест может быть справедлив, но невалиден (каждая демография работает подобно, но баллы не предсказывают производительность работы).

Лучшие оценки оба:

• Валидны: высокие баллы предсказывают успех работы
• Справедливы: производительность на тесте не коррелирует с демографической группой или происхождением

Для достижения оба:

1. тестируйте реальные навыки используемые на работе (валидность).
2. Удалите барьеры не связанные с теми навыками (справедливость).
3. Валидируйте после найма (измеряйте, предсказывает ли тест фактически производительность).
4. Проверьте на демографическое смещение (определённые группы систематически набирают ниже, и это совпадает с производительностью работы?).

Данные, которые вы должны собирать

Если вы наймёте 10+ людей через одну и ту же оценку, отследите:

корреляции для поиска:

• балл теста коррелирует с рейтингом производительности? (Проверка валидности)
• кандидаты из определённых происхождений кластер в разных уровнях производительности? (Проверка справедливости)
• что ещё предсказывает производительность? (сигнал поведенческого интервью? Предыдущий опыт?)

эти данные говорят вам, работает ли ваша оценка и для кого.

неловкая правда о тестах программного навыка

Большинство платформ оценки в сети претендуют валидность и справедливость. редко они действительно валидировали против производительности работы. Они измерили внутреннюю последовательность (баллы теста надёжны, если вы берёте его дважды) и face validity (тест выглядит, что он должен измерять).

Но они не отследили: люди, которые набирают высоко, действительно успешны в работах, они наймены для?

Вы не можете доверять претензии валидности без того данные.

Построить вашу собственную валидацию. Наймите людей через вашу оценку. Отследите их производительность. Отрегулируйте. повторяйте. после двух циклов найма, вы будете знать, работает ли ваш тест фактически.

до тех пор, относитесь к тестам программного навыка как полезным сигналам, не определителям. высокий балл ордеров продвинутое разговор и реалистичный preview работы. низкий балл причина пробить глубже, не автоматический отказ.

лучший найм объединяет множество сигналов: тест навыка, поведенческое интервью, выборки работы и разговор с текущими членами команды. ни один тест не определяет найм/не-найм. вот как вы остаёте оба валидны и справедливы.