Метрики технического скрининга: как измерить эффективность

Большинство HR-команд оценивают кандидатов на скрининге, но не оценивают сам процесс скрининга. Без метрик невозможно понять: хорошо ли работает наш тест? Правильно ли мы установили порог прохождения? Не теряем ли мы сильных кандидатов?

Основные метрики SQL-скрининга

1. Completion Rate (Процент завершения)

Сколько кандидатов, получивших тест, действительно его прошли?

Completion Rate = (кандидаты, сдавшие тест / кандидаты, получившие приглашение) × 100%

Benchmark: 50–70% — нормально, меньше 40% — тест слишком длинный или сложный, либо процесс отправки неудобный.

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

2. Pass Rate (Процент прохождения)

Сколько кандидатов, завершивших тест, набрали проходной балл?

Pass Rate = (кандидаты с баллом ≥ порога / всего сдавших) × 100%

Benchmark: 30–50% — нормально. Ниже 20% — либо задачи слишком сложные, либо вы привлекаете нерелевантных кандидатов. Выше 70% — задачи слишком лёгкие, тест не фильтрует.

3. Time-to-Screen

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

Benchmark: 3–5 дней при дедлайне 5 рабочих дней. Если большинство сдаёт в последний момент — дедлайн слишком длинный или кандидаты не чувствуют срочности.

4. Predictive Validity

Коррелирует ли балл на скрининге с качеством работы после найма?

Это самая важная метрика, но требует данных после найма. Через 6–12 месяцев сравните:

• Балл на скрининге
• Оценку на испытательном сроке
• Производительность за первый год

Если корреляции нет — тест измеряет не то, что важно в работе.

5. Interview-to-Hire Rate

Сколько кандидатов, прошедших скрининг и приглашённых на интервью, получили оффер?

Interview-to-Hire = (офферы / интервью) × 100%

Benchmark: 20–40%. Если ниже — скрининг пропускает слабых кандидатов. Если выше — возможно, порог скрининга слишком высокий и вы отсеиваете хороших.

Как построить дашборд метрик скрининга в SQL

Если вы храните данные о скрининге в базе данных, можно построить автоматический отчёт:

-- Таблицы: screening_invitations(id, candidate_id, sent_at, test_id)
--          screening_results(id, invitation_id, completed_at, score, max_score)
--          interview_outcomes(candidate_id, status, offer_extended)

WITH screening_stats AS (
    SELECT
        DATE_TRUNC('month', si.sent_at)                   AS month,
        COUNT(DISTINCT si.id)                             AS invitations,
        COUNT(DISTINCT sr.id)                             AS completions,
        COUNT(DISTINCT CASE WHEN sr.score::FLOAT / sr.max_score >= 0.7
                            THEN sr.id END)               AS passed
    FROM screening_invitations si
    LEFT JOIN screening_results sr ON sr.invitation_id = si.id
    GROUP BY 1
)
SELECT
    month,
    invitations,
    completions,
    passed,
    ROUND(100.0 * completions / invitations, 1)  AS completion_rate,
    ROUND(100.0 * passed / NULLIF(completions, 0), 1) AS pass_rate
FROM screening_stats
ORDER BY month;

Анализ качества заданий

Используйте Item Analysis для оценки каждой задачи в тесте:

Difficulty Index (индекс сложности):

P = (число верных ответов / всего ответов) × 100%

• P < 20% — задача слишком сложная
• P > 80% — задача слишком лёгкая
• P = 40–60% — оптимально для дифференциации

Discrimination Index (дискриминативность):

D = P_top - P_bottom

где P_top — процент верных ответов среди топ-27% по общему баллу, P_bottom — среди нижних 27%.

D > 0.3 — задача хорошо дифференцирует кандидатов.

-- Анализ сложности задач
WITH task_stats AS (
    SELECT
        task_id,
        COUNT(*)                                       AS total_attempts,
        SUM(CASE WHEN is_correct THEN 1 END)           AS correct_attempts
    FROM task_responses tr
    JOIN screening_results sr ON sr.id = tr.result_id
    WHERE sr.completed_at >= CURRENT_DATE - 90
    GROUP BY task_id
)
SELECT
    task_id,
    total_attempts,
    correct_attempts,
    ROUND(100.0 * correct_attempts / total_attempts, 1) AS difficulty_pct,
    CASE
        WHEN 100.0 * correct_attempts / total_attempts < 20 THEN 'Слишком сложная'
        WHEN 100.0 * correct_attempts / total_attempts > 80 THEN 'Слишком лёгкая'
        ELSE 'Оптимально'
    END AS assessment
FROM task_stats
ORDER BY difficulty_pct;

Частые ошибки при анализе метрик

Ошибка 1: Смотреть только на Pass Rate. Высокий Pass Rate может означать, что тест слишком лёгкий, а не что кандидаты хорошие.

Ошибка 2: Не связывать результаты скрининга с результатами работы. Без этой связи нельзя понять, предсказывает ли тест успех.

Ошибка 3: Менять тест без измерений до/после. Любое изменение — это эксперимент. Зафиксируйте базовые метрики, введите изменение, измерьте результат.

Ошибка 4: Игнорировать completion rate. Если кандидаты не завершают тест, вы теряете кандидатов ещё до оценки.

Чеклист оптимизации скрининга

• Задокументирован проходной балл и обоснование порога
• Completion Rate измеряется ежемесячно
• Pass Rate в диапазоне 30–50%
• Каждые 6 месяцев проводится Item Analysis
• Есть данные о корреляции балла с результатами найма
• Обратная связь кандидатам об уровне сложности

Хотите дать кандидатам качественную практику перед скринингом? SQLlab.ru — это платформа с сотнями задач и аналитикой прогресса.