На примере Codenrock Vibe разобрали цели оценки, требования к роли, расхождения оценок 180–360 и переход от результатов к индивидуальному плану развития. В полной записи — демонстрации тестирования, ИПР и обучения. Нужный фрагмент можно найти по таймкодам.

Смотреть запись и читать итоги вебинара →

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

1. Начните README с задачи и результата

В первых строках объясните, для кого сделан проект, какую проблему он решает и что уже работает. Вместо «инновационная AI-платформа» напишите: «Прототип распределяет обращения по трём категориям и предлагает оператору черновик ответа». Добавьте скриншот или короткую запись демонстрации и ссылку на версию, которую показывали на защите. Запись полезна как запасной вариант, если демостенд перестанет работать, но не заменяет инструкцию запуска.

2. Дайте один проверенный путь запуска

Укажите версии языка и среды, зависимости, требуемые внешние сервисы и порядок команд. Начните с получения кода, затем опишите установку, настройку окружения, подготовку тестовых данных и запуск. Завершите инструкцию адресом приложения и ожидаемым результатом: какую страницу человек увидит и какое действие должен выполнить. Если способ запуска проверен только на одной ОС, прямо назовите её.

Что положить рядом с инструкцией

Добавьте пример конфигурации без секретов, например .env.example, с названиями переменных и пояснениями. Напишите, какие значения обязательны, где пользователь получает собственный ключ и есть ли у внешнего сервиса платные запросы. Реальные токены, пароли и персональные данные не должны попадать в публичный пример. Для демонстрации подготовьте синтетические данные и объясните, как их загрузить. Если внешний API недоступен без аккаунта, обозначьте это до первого шага запуска.

3. Опишите ограничения так, чтобы их можно было проверить

Раздел «Ограничения» — не извинение за прототип. Это инструкция, как правильно понимать показанный результат. Укажите, какие входные данные поддерживаются, что заменено заглушкой, где требуется ручное действие и какие проверки ещё не проводились. Например: «Классификация показана на демонстрационном наборе; качество на реальных обращениях не измеряли». Если нагрузочное тестирование не делали, не обещайте работу на тысячах пользователей.

4. Покажите структуру и вклад команды

Коротко объясните, где интерфейс, сервер, модели, тесты и примеры данных. Зафиксируйте, кто за что отвечал: это помогает использовать проект в портфолио без приписывания себе общей работы. Отдельно обозначьте используемые библиотеки, модели и внешние сервисы. Если применяли ИИ для разработки, полезно описать, что команда проверила сама: тесты, ревью, воспроизведение основного сценария. Подробности архитектуры можно вынести в отдельный документ, оставив ссылку из README.

5. Проверьте запуск с чистого окружения

Попросите участника команды, который не настраивал проект, пройти инструкцию с нуля — в новом окружении или на другом компьютере. Пусть он использует только README и указанные файлы. Запишите все места, где потребовалась устная подсказка, и внесите эти шаги в документацию. Проверьте доступ к репозиторию, ссылкам на демо и файлам с данными. Укажите дату последней проверки и версию кода, на которой она проводилась.

Минимальный шаблон README

Скопируйте структуру ниже и замените подсказки конкретными сведениями. Не добавляйте команды установки «для красоты»: каждая команда должна соответствовать вашему репозиторию и быть проверена.

# Название проекта
## Задача и пользователь
Кому помогает проект и в каком сценарии.
## Что работает
Демонстрация, пример входных данных и результат.
## Требования
Проверенные версии, сервисы, доступы.
## Быстрый запуск
Команды по порядку, конфигурация, тестовые данные.
## Как проверить результат
Адрес приложения и действие для проверки.
## Ограничения
Заглушки, неподдерживаемые случаи, непроверенные свойства.
## Структура проекта
Основные каталоги и их назначение.
## Команда
Участники и вклад каждого.
## Проверено
Дата и версия кода.

Что проверить перед отправкой ссылки

Получатель имеет доступ к коду; инструкция начинается с чистого окружения; примеры не содержат секретов; основной сценарий воспроизводится; ограничения названы; вклад команды понятен. Такой проект проще обсудить предметно: читатель видит результат и может самостоятельно его проверить.

Справка: документация GitHub о README объясняет назначение файла и размещение основной информации о проекте.

До дедлайна 40 минут. Агент предлагает «небольшой рефакторинг», дизайнер экспортирует слайды, а ссылка на демо открывается только у разработчика.

Кода много. Сдавать пока нечего.

План хакатона должен довести команду до результата, который можно открыть и оценить. Для этого нужны ранняя общая сборка, время на проверки и отдельный запас на загрузку. ИИ ускоряет отдельные задачи, но эти этапы за вас не отменяет.

Первое действие: выпишите дедлайн сдачи, время защиты и обязательные промежуточные встречи. Это могут быть три разных расписания.

Как подключить ИИ к планированию

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

Составь черновой план до [дедлайн]. Вот состав, часы работы и обязательный результат. Покажи зависимости: что нельзя начать, пока не готово другое. Оставь время на сон, проверку и загрузку. Не считай, что вся команда работает непрерывно.

Верните правки: «Деплой раньше занимал у нас два часа, а ты оставил десять минут. Пересобери план, сократив необязательные функции». Хороший результат здесь — план, который участники готовы выполнить, а не аккуратная таблица.

До старта: подготовьте рабочее место

Проверьте окружение, доступ к репозиторию и связь команды. Скачайте нужные инструменты, договоритесь о стеке, проверьте вход в разрешённые ИИ-сервисы и доступные лимиты.

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

Подготовить технику можно без разработки конкурсного решения: обновить среду, проверить демонстрацию экрана, установить зависимости знакомого стека.

На старте: запишите, что и к какому времени должно работать

Создайте в общем чате одно сообщение:

Сдача: дата, время, часовой пояс. Что загружаем: список из регламента. Первый запуск всего сценария: время. Прекращаем добавлять функции: время. Внутренняя сдача: раньше официальной, с запасом на исправления. Кто загружает: имя. Кто проверяет доступ: другое имя.

Сначала проверьте платформу сдачи: какие поля обязательны, какие форматы принимает, кто имеет право отправить решение. Обидно обнаружить это после того, как капитан ушёл спать.

Пример плана на 48 часов

Это заготовка для продуктового хакатона. Перенесите в неё реальные чекпоинты, отдых участников и требования своего трека. Для ML, кейс-чемпионатов и CTF используйте отдельные гайды в конце статьи.

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

Не переносите таблицу механически на 24 часа. Сократите объём решения и заново выделите время на сдачу. На недельном соревновании разбейте работу по дням и привяжите финальную заморозку к реальному дедлайну.

Проверьте весь путь, пока проект ещё маленький

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

Так вы проверяете соединение частей, а не качество ещё неготового алгоритма. Следом заменяете заглушку работающей логикой.

Попросите ассистента: «По нашему плану выбери самый короткий путь от входа до результата. Где пока допустима заглушка для проверки соединения частей?» Соберите этот путь и запустите. Затем сообщите, что действительно получилось. На основе наблюдений пересмотрите следующие задачи.

Повторяйте общий запуск после заметных изменений. Быстро написанные модули всё равно придётся соединить.

Как ограничить задачи для ИИ по времени

У каждой задачи должны быть небольшой объём, способ проверки и момент, когда вы остановитесь оценить результат.

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

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

На короткой встрече соберите четыре факта: что работает, что мешает, что изменилось и сколько осталось времени. Передайте их ИИ:

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

Команда выбирает, что убрать. Если ИИ снова предлагает увеличить объём, верните ограничение и попросите план только из оставшихся задач.

На чекпоинт приносите конкретный вопрос

Встречи с экспертами могут быть обязательными или добровольными — смотрите расписание. Используйте их для решения неопределённости.

Вместо «нормальная идея?» спросите:

Мы выбрали сценарий X, потому что в критериях есть Y. Проверять хотим через Z. Правильно ли поняли требование? Вот часть, которая пока не работает.

Запишите ответ эксперта. Попросите ИИ сравнить его с планом: «Какие задачи теперь меняются, какие остаются? Не добавляй требований, которых эксперт не называл». Проверьте список и назначьте ответственных. Подробнее о подготовке — в материале про чекпоинты.

Финал: прекратите расширять проект

Момент остановки новых функций команда выбирает заранее. В примере выше новые функции перестают добавлять за шесть часов до дедлайна. Сложное развёртывание или длинная обязательная документация требуют большего запаса.

К этому моменту должны быть черновик слайдов, сценарий показа и сохранённая рабочая версия. Дальше — исправления, без которых результат нельзя проверить или сдать.

Распределите финальные задачи параллельно:

• один участник проверяет запуск и основной сценарий;
• другой доводит README, зависимости и инструкцию;
• спикер записывает демонстрацию и репетирует в лимит времени;
• ответственный за сдачу загружает актуальные файлы.

На финале передайте ИИ требования к сдаче и список готовых материалов:

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

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

Перед нажатием «Отправить»

Проверьте ссылки с аккаунта человека, которому выдали только необходимые права. Для публичной ссылки подойдёт приватное окно браузера; для закрытого проекта — доступ, предусмотренный регламентом.

Убедитесь, что прикрепили именно финальные файлы, видео воспроизводится, README соответствует сборке, а результат отправки подтверждён платформой. Сохраните подтверждение. Возможность менять решение после отправки зависит от правил — не рассчитывайте на неё заранее.

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

На защите: покажите то, что сдали

Если в формате есть питч, отрепетируйте его по официальному лимиту. Коротко обозначьте задачу, покажите главный сценарий, назовите проверенный результат и ограничения. Распределите, кто отвечает за продукт, код и эксперименты.

Подготовьте ответ об использовании ИИ: какие части он помог сделать, что команда проверила и где модель работает внутри решения. Если живой показ сорвался, используйте запасную запись, когда это допускает формат защиты. Объясните причину сбоя.

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

Заберите в работу: три времени — первый общий запуск, остановка новых функций, внутренняя сдача. Конкретные инструменты организации разобраны в статье о тайм-менеджменте на хакатоне.

После финала: сохраните проект и оформите его для дальнейшего использования.

Если у вас другой формат: план работы на ML-соревновании, подготовка решения кейса, командный CTF jeopardy.

Разберём, как организовать первый проект HR-аналитики на этой задаче: выбрать показатель, запросить данные, посчитать ранние уходы, проверить возможные причины и договориться о действии. Внутри статьи — таблица со списком нужных данных, примеры проверки отдельных записей и заполненные карточки постановки задачи и проверки результата. Все примеры учебные: по ним можно собрать собственную расчётную таблицу.

Что такое HR-аналитика и чем она отличается от отчёта

HR-аналитика — это анализ данных о сотрудниках и HR-процессах, который помогает выбирать и проверять управленческие решения. Например, выяснить, где задерживается подбор, почему уходят новички или каких навыков не хватает для нового проекта.

В международной практике HR-аналитику также называют people analytics. В справочнике CIPD термины people analytics и HR analytics используются как названия анализа данных о людях для решения бизнес-задач.

Метрика — отдельный показатель: например, доля сотрудников, ушедших за первые 90 дней. Отчёт показывает её значение за выбранный период. Анализ начинается с вопросов: в каких группах уходов больше, чем эти группы различаются и что стоит проверить перед изменением процесса. Другие показатели и формулы разобраны в нашем материале «HR-метрики 2026: 12 показателей и дашборд».

Допустим, из 40 новичков восемь ушли за первые 90 дней: ранний отток составляет 20%. Но в подразделении А ушли шесть из двадцати, а в Б — два из двадцати. Общий показатель скрывает разницу: 30% против 10%.

Что видно на графике: подразделение А стоит изучить подробнее. Чего график не доказывает: что виноват руководитель, подбор или адаптация. Группы могут различаться по профессиям, графику работы и условиям найма. Один дополнительный уход из группы в 20 человек меняет результат сразу на пять процентных пунктов.

Какие задачи подходят для первого проекта

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

В таблице — три примера с разными источниками данных. Они выбраны, чтобы показать логику выбора первого проекта, а не ограничить область HR-аналитики.

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

Шаг 1. Договоритесь, на какой вопрос отвечаете

Начните с разговора с руководителем подразделения. Какие вакансии приходится открывать повторно? Что это меняет в работе: растёт нагрузка на остальных, сдвигаются сроки, повторяются затраты на подбор? Что руководитель готов изменить, если предположение подтвердится?

Запишите договорённость в короткую карточку. Она нужна, чтобы HR и руководитель одинаково понимали результат работы.

Карточка первого проекта: повторный найм из-за ранних увольнений

Здесь два разных результата. Сначала нужно разобраться в проблеме. Затем — проверить эффект выбранного изменения. Обещать снижение увольнений ещё до изучения причин было бы преждевременно.

Шаг 2. Запросите данные и запишите правила расчёта

Для этого проекта хватит кадровой выгрузки и сведений о причинах ухода. Систему подбора подключайте, если будете проверять источники кандидатов или обещания на интервью. Не нужно заранее объединять все HR-системы компании.

Таблица 1. Какие столбцы запросить для анализа ранних увольнений

Одна строка — один период работы сотрудника в выбранной компании. Если человек уволился и позже вернулся, это две строки с одним ID человека и разными ID периода работы. ID — устойчивый код записи; он нужен для соединения сведений и проверки дублей.

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

Как записывать причины увольнения

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

Например, в кадровом документе стоит основание «по собственному желанию». В интервью сотрудник объяснил, что не может работать вечером. Для анализа это будет: инициатор — сотрудник; категория — график; комментарий — «вечерние смены несовместимы с учёбой»; источник — интервью. Такое объяснение отражает слова сотрудника, а не автоматически установленную единственную причину ухода.

Если сотрудник и руководитель объясняют уход по-разному, сохраните обе версии с указанием источников. Если интервью не было, оставьте «неизвестно» вместо догадки.

Какие правила согласовать до расчёта

Для нашего примера правила такие:

• Рассматриваем внешние выходы на выбранные роли в двух подразделениях за январь. В учебной группе нет повторного найма.
• Внутренний перевод внутри выбранного периметра компании не считаем уходом. Если сотрудник перевёлся, сохраняем его историю и относим к подразделению на дату выхода для этого расчёта.
• Считаем все увольнения за первые 90 календарных дней, затем отдельно разбираем добровольные и остальные. День выхода — первый день; увольнение на 90-й день включаем.
• Срез делаем после того, как с даты выхода последнего человека в группе прошло не менее 90 дней. Уже уволившихся из группы не исключаем.
• Результат рассчитывает назначенный HR-специалист. Раз в месяц он получает свежую выгрузку, проверяет новые записи и добавляет следующую группу с завершённым периодом наблюдения. Это и есть обновление отчёта.

Если есть несколько юридических лиц, заранее решите, анализируете отдельного работодателя или всю группу компаний. Один и тот же переход между юрлицами может учитываться по-разному в этих двух отчётах.

Когда нужны данные об оценке навыков

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

Методика оценки — это то, чем и по каким правилам измеряют навык: задания, критерии, шкала и условия прохождения. Версия отмечает изменение этих правил. Например, в первой версии теста было 20 базовых вопросов, а во второй добавили сложные практические задания. Разницу в баллах нельзя сразу считать ухудшением навыков: изменился измерительный инструмент.

Пример из практики Codenrock. В проекте оценки Python-разработчиков промышленной компании команда сначала собрала профиль компетенций под реальные задачи заказчика, затем подготовила отдельные треки для backend-разработки и математических вычислений. Приглашённый Python-эксперт участвовал в проверке заданий и правил оценки.

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

Шаг 3. Проверьте выгрузку и посчитайте показатель

Сначала проверьте несколько вещей, от которых непосредственно зависит результат:

1. Нет повторяющихся строк. Один период работы не должен попасть в расчёт дважды.
2. Даты заполнены и согласуются. Увольнение не может предшествовать выходу; отсутствие даты нужно объяснить.
3. Переводы отделены от уходов. Кадровое оформление перехода не должно автоматически увеличивать отток из группы компаний.
4. Названия подразделений совпадают. «Поддержка А» и «Отдел А» не должны случайно стать разными группами.
5. Учтены уже уволившиеся. Выгрузка только действующих сотрудников не подходит для расчёта увольнений.
6. Период наблюдения завершён. Нельзя улучшать показатель, добавляя в знаменатель тех, кто вышел недавно.

Таблица 2. Как проверить отдельную запись перед расчётом

Условная дата среза — 1 мая 2026 года. Январская группа уже готова к расчёту; апрельский выход относится к другой группе, для которой наблюдение ещё продолжается.

Если считаете в таблице, добавьте столбец «Ранний уход»: 1, когда дата увольнения заполнена, не раньше даты выхода и разница между датами плюс один не превышает 90; иначе 0. Это правило применяют после проверки дат. Далее сводная таблица по подразделению должна показать число периодов работы и сумму единиц в столбце «Ранний уход». Сводную стройте только по выбранной группе с завершённым 90-дневным наблюдением.

Ранний отток за 90 дней = число ранних уходов из выбранной группы ÷ число выходов в этой же группе × 100%.

Если в выбранной группе нет выходов, показатель не рассчитывают: нулевой знаменатель означает «нет данных для расчёта», а не 0% оттока.

В нашем примере: подразделение А — 6 ÷ 20 = 30%; подразделение Б — 2 ÷ 20 = 10%. Вместе — 8 ÷ 40 = 20%. Это те же числа, что на графике в начале статьи.

Все сведения в учебном примере вымышлены. Они показывают метод расчёта и не являются отраслевыми ориентирами.

Отдельно проверьте полноту причин. Если они известны для пяти из восьми ушедших, так и укажите: «Причины известны для 5 из 8 уходов». Три неизвестных причины нельзя записать в «личные обстоятельства» ради заполненной таблицы.

Шаг 4. Проверьте объяснения, прежде чем выбирать действие

Большая доля уходов в подразделении А — повод для разбора. Сначала выясните, сравниваете ли похожие роли и условия. Если в А работают сменные специалисты, а в Б — сотрудники с фиксированным дневным графиком, прямое сравнение подразделений ещё не оценивает качество управления.

Затем разделите уходы по инициатору и проверьте причины. Для нашей условной группы А картина такая:

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

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

Шаг 5. Запишите изменение и способ проверки

В нашем примере руководитель подбора предлагает показывать пример расписания и обсуждать вечерние смены до оффера. Руководитель подразделения подтверждает, что это расписание соответствует реальной работе.

Карточка проверки: помогает ли точное описание графика сократить ранние уходы

15% — условная цель этого пилота, а не норма рынка и не прогноз. Два ухода разницы на небольшой группе не доказывают эффект изменения. На повторной встрече нужно проверить состав группы, другие изменения в работе и причины увольнений.

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

Какие инструменты нужны и сколько времени заложить

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

Система подбора, или ATS, нужна для истории этапов и общения с кандидатами. BI-система помогает автоматически обновлять отчёты из нескольких источников, когда правила расчёта уже согласованы. Сложная программа не исправит неоднозначную причину увольнения или отсутствующую дату выхода.

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

План первого месяца — при доступных данных

За месяц можно подготовить решение и запустить изменение. Чтобы оценить 90-дневный отток новой группы, потребуется дождаться завершения её периода наблюдения.

Что сделать после чтения

Выберите одну проблему и заполните карточку первого проекта: вопрос, группа сотрудников, правила расчёта, источник данных, ответственный и дата разбора. Начните с проверяемого показателя и покажите рядом с процентом число людей.

Для работы с таблицей используйте Excel-шаблон HR-дашборда с 12 показателями. На странице материала можно оставить имя, рабочую почту и компанию в форме и скачать файл. Заполняйте только показатели, связанные с вашей задачей; источники, ответственного и следующий шаг фиксируйте рядом с расчётом.

ИИ собрал интерфейс. Есть вход, профиль, дашборд и даже тёмная тема. Осталось проверить, умеет ли приложение то, ради чего вы его делали.

Загружаете файл. Кнопка крутится. Результата нет.

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

Если до сдачи несколько часов: выберите один сценарий, пройдите его от начала до конца, исправьте поломки и сохраните рабочую версию. Новые функции подождут.

Эта статья — для команд, которые создают продукт или сервис. В ML-соревновании результатом может быть модель, в кейс-чемпионате — обоснованное решение, в CTF — решённые задания. Называть любой конкурсный результат MVP не нужно.

Прототип, MVP, продукт: разница на одном примере

Допустим, вы делаете сервис, который превращает фотографию расписания в события календаря.

Прототип тоже может работать и содержать код. А в MVP часть действий может выполняться вручную. Важно, что вы проверяете: устройство решения или его пользу в реальной задаче.

Например, макет поможет понять, удобна ли загрузка фото. Рабочая версия, которую дали студентам, — проверить, получается ли переносить расписание и хотят ли они делать это снова. Показ жюри сам по себе на второй вопрос не отвечает.

Сначала напишите, что должно получиться

До генерации кода заполните четыре строки:

• Пользователь: студент с расписанием в виде фотографии.
• Задача: перенести занятия в календарь без ручного ввода каждого события.
• Сценарий: загрузить фото → проверить распознанное → исправить ошибки → скачать файл для календаря.
• Проверка: файл импортируется, даты и время совпадают с исходным расписанием после исправлений.

Теперь понятно, зачем нужна каждая часть. Экран редактирования нужен: распознавание может ошибаться. Лента друзей пока не помогает проверить эту гипотезу.

Это учебный пример. В вашей задаче сначала выпишите обязательные требования трека — их нельзя убрать ради красивого короткого сценария.

Что оставить, что отложить

Разложите задачи на три списка.

Нужно для результата. Загрузка, распознавание, проверка, экспорт. Если убрать любой шаг, студент не получит события в календаре.

Нужно по условиям соревнования. Например, определённый API, измерение качества, исходный код, видео или инструкция запуска. Проверьте это в правилах.

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

Вопрос к каждой новой функции: без неё пользователь не получит результат или нам просто хочется её добавить?

Безопасность тоже зависит от сценария. Для публичного сервиса с пользовательскими файлами нельзя автоматически вычеркнуть ограничения доступа и обработки загрузок. Проще сузить демо до разрешённых тестовых данных, чем наскоро принимать чужие документы.

Как собрать MVP с ИИ: от брифа до рабочего показа

Для обсуждения задачи подойдёт любой ИИ-сервис. Для правок в проекте нужен инструмент с доступом к файлам либо участник, который перенесёт код из чата и запустит его. Не считайте сообщение «готово» доказательством запуска.

Шаг 1. Объясните результат, который хотите получить. Передайте бриф, навыки команды и доступное время. Если правила запрещают загружать материалы, используйте разрешённое описание без закрытых данных.

Мы делаем [задача] для [пользователь]. Вот требования и ограничения. Перескажи главный сценарий и задай вопросы, без которых нельзя начать. Код пока не пиши.

Если ассистент добавил магазин, личный кабинет и рекомендации, верните его к задаче: «Оставь только перенос расписания. Что обязательно для этого?» Дальше идите, когда команда согласна с получившимся сценарием.

Шаг 2. Сократите план. Попросите разложить сценарий на маленькие части.

Для каждого шага укажи вход, результат и проверку. Отдельно — обязательное по брифу и то, что можно отложить.

Проверьте список сами. Если распознавание — главный риск, сначала пробуйте его на нескольких разрешённых примерах. Красивый экран этого риска не снимет.

Шаг 3. Сделайте одну часть. Например, загрузку файла.

Реализуй загрузку изображения в текущем проекте. Форматы: [список], размер: [предел]. Неподходящий файл должен давать понятную ошибку. Не меняй соседние функции. Покажи, как проверить результат.

Запустите и обычный файл, и неподходящий. Если что-то сломалось, отправьте точный текст ошибки, входные данные и ожидаемый результат: «Найди причину и исправь только её». После проверки сохраните рабочую версию и переходите к следующей части.

Шаг 4. Соедините всё. Пройдите путь от загрузки до готового календаря. Если части работают отдельно, но вместе нет, дайте ИИ фактические запрос и ответ между ними.

Вот что отправляет интерфейс и что ждёт обработчик. Где расхождение? Предложи минимальную правку и способ проверить её.

Повторите весь путь после исправления. Проверка отдельной кнопки ещё не означает, что готов пользовательский сценарий.

Шаг 5. Подготовьте показ. Дайте ассистенту список того, что действительно работает.

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

Откройте проект и пройдите этот сценарий с таймером. Если текст предлагает показать то, чего нет, исправьте рассказ. Сохраните рабочую сборку и запасную запись.

Если ИИ работает внутри вашего продукта

Здесь появляется ещё одна задача: проверить ответы модели.

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

Проверьте три вещи:

• Ошибки видны? Пользователь может исправить дату, которую модель распознала неверно.
• Есть предел ожидания? Если API не отвечает, интерфейс объясняет, что произошло, и предлагает повторить запрос.
• Есть чем подтвердить качество? «На наших 12 тестовых изображениях…» честнее, чем «точность 99%», которую никто не измерял.

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

Придуманные данные помогают отладить экран, но не доказывают качество на настоящих расписаниях.

Демо готово, когда его может повторить тиммейт

Попросите человека, который не собирал эту часть, открыть проект и пройти сценарий по инструкции.

Перед сдачей проверьте:

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

Запишите запасное видео и сохраните версию, которую показывали. Видео помогает объяснить работу при сбое связи, но не заменяет обязательный запуск, если его требует регламент.

Не успеваем. Что резать сейчас?

Сначала сократите охват: один формат расписания, один способ экспорта, один язык. Затем уберите необязательные экраны.

Если заменяете часть системы заранее подготовленным ответом, скажите об этом. «Этот участок пока заглушка» — точное описание состояния проекта. Заглушка основной функции означает, что её работу вы ещё не доказали.

Для защиты подготовьте три короткие фразы:

Сейчас работает: … Проверили на: … Следующий шаг и главное ограничение: …

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

Дальше по серии: как распределить роли и как оставить время на сдачу.

Модель обучилась, число на экране выросло — хочется запускать следующую. Но если вы случайно включили в признаки ответ или перепутали порядок строк, улучшение окажется иллюзией.

Разберём рабочий процесс для соревнований по машинному обучению с оценкой на данных. Это не инструкция для всех возможных ML-треков: формат запуска, метрику и список того, что нужно сдать определяет организатор.

Если выбираете первое событие и готовитесь до старта, начните с обзорной статьи Codenrock о подготовке к ML-соревнованиям. Здесь сосредоточимся на работе с уже выданным заданием.

Что такое baseline, validation и submission

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

Для обсуждения задачи подойдёт любой привычный ИИ-сервис. Код из обычного чата вы запускаете сами; агент с доступом к проекту может запускать проверки, если такая возможность настроена. В обоих случаях сохраняйте реальные результаты, а не только рассказ модели о них.

1. До обучения разберите правила и данные

Выпишите в один файл:

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

Если команда участвует ради опыта, ей тоже нужен этот список. Работать два дня с запрещённым источником данных — плохой способ проверить навыки.

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

Промпт для разбора:

Вот разрешённые описание задачи, схема данных и требования. Составь список проверок перед первым запуском. Отдели явные условия от предположений. Для каждого ограничения укажи место в документе. Не предлагай внешние данные и модели, пока не проверена допустимость.

После ответа уточните: «Какие пункты ты вывел из документа, а какие предположил? Покажи места, где указаны метрика и ограничения». Сверьте их и сохраните короткую инструкцию проекта. Она будет контекстом для следующих задач ИИ.

2. Запустите baseline и проверьте весь путь

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

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

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

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

Готовность baseline: решение запускается повторно, выдаёт корректный файл и имеет записанную локальную оценку. Скриншота успешного обучения недостаточно.

3. Настройте валидацию под задачу

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

Зафиксируйте выбранный способ разбиения: иначе две модели будут сравниваться в разных условиях.

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

Есть и менее заметная утечка: параметры заполнения пропусков или масштабирования рассчитаны на всех данных до разделения. Обучаемые преобразования нужно настраивать на обучающей части и применять к проверочной. Удобно собрать эти шаги в один пайплайн — последовательность обработки и обучения, которую вы запускаете одинаково каждый раз.

ИИ может проверить код на возможные утечки. Но он не всегда знает, когда конкретное поле становится доступно в бизнес-процессе: это нужно выяснить по описанию данных.

Передайте ИИ описание полей и схему разбиения: «Проверь, не используем ли сведения из будущего. Какие поля доступны только после события? Что нужно уточнить?» Проверьте вопросы по заданию. Затем попросите проверить код обработки: на какой части он учится и к какой применяется. Дальше идите, когда можете сами объяснить эту схему.

4. Меняйте одну понятную вещь за эксперимент

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

Начните с одной гипотезы: «признак дня недели помогает учитывать различия в доставках». Сравните версии при той же проверке, затем посмотрите, на каких примерах стало лучше или хуже.

Ведите короткий журнал:

Задача ИИ-агенту:

Реализуй только гипотезу [описание] в существующем пайплайне. Не меняй разбиение данных и метрику. До запуска оцени необходимые ресурсы. Сохрани параметры и результаты отдельно от baseline. После работы укажи, какие проверки выполнил; не называй улучшением результат, который не измерял.

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

После запуска верните модели фактическую метрику, время и примеры ошибок:

Сравни с baseline. Что подтверждено, а что пока предположение? Предложи одну следующую проверку. Не меняй сразу модель, признаки и разбиение.

Если стало хуже, попросите объяснения, которые можно проверить. Выберите одно и повторите эксперимент. Не сохраняйте изменение только потому, что ИИ убедительно объяснил, почему оно «должно помогать».

5. Не превращайте лидерборд в единственный ориентир

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

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

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

6. Подготовьте решение, которое можно запустить заново

Резерв до дедлайна должен покрывать полный расчёт предсказаний, загрузку и возможный повтор. Если один запуск длится три часа, запас в двадцать минут не спасёт.

Перед отправкой проверьте:

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

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

Сохраняйте лучшее проверенное решение отдельно от новых экспериментов. Если при повторении возможна случайность, фиксируйте настройки и описывайте её влияние; один seed не гарантирует идентичность на любом оборудовании.

Дальше: убедитесь, что baseline сохранён и вы можете объяснить схему проверки. По выбору инструментов есть отдельный материал Codenrock о стеке для ML. О совместной работе — статья про команду, о дальнейшем использовании результата — гайд по портфолио.

В обзоре — сервисы российского рынка для предварительного технического скрининга, живых интервью с кодом и контестов. Разберём, что умеет каждый, когда его выбирать и как проверить платформу на своей вакансии до покупки.

Какие бывают платформы для оценки ИТ-специалистов

Технический скрининг — проверка навыков до подробного интервью. Кандидат проходит задания самостоятельно, а команда получает результаты для следующего этапа. Здесь важны содержание теста, понятная оценка и доступ к исходным ответам.

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

Контест — набор задач с правилами, сроками и системой баллов. Решения проверяются автоматически на подготовленных тестах. Формат подходит для массового отбора на стажировку, если задачи похожи на будущую работу.

Эти форматы не заменяют, а дополняют друг друга. Скрининг отсеивает тех, кому не хватает базовых навыков, интервью разбирает решения прошедших, контест помогает при большом потоке стажёров. Поэтому выбирать платформу лучше под конкретный этап: «сократить ручную проверку первого этапа» или «собрать код, схемы и заметки интервью в одном месте».

Сравнение платформ для оценки ИТ-специалистов

✓ — возможность есть по официальному описанию сервиса; ? — в открытых источниках нет данных, это не значит, что функции нет. Сведения собраны в сентябре 2026 года, набор функций зависит от тарифа и модуля. На телефоне таблицу можно прокручивать вбок.

«Свои задачи» означает, что содержание заданий готовит команда. Запуск кода и автоматическое выставление баллов на тест-кейсах показаны отдельными строками.

Codenrock Vibe: оценка до технического интервью

В Codenrock Vibe рекрутер или тимлид описывает роль — стек, уровень, ключевые задачи, — и ИИ собирает тест по нужным компетенциям. Вопросы можно отредактировать, добавить свои задания и пригласить кандидатов по ссылке.

Для ИТ-ролей в Vibe есть задачи с кодом и автопроверкой на скрытых тест-кейсах (Python, Java, C++, JavaScript, Go, C#, PHP), задания на code review с комментариями прямо в строках кода, SQL-задания, открытые вопросы и устные ответы голосом. Развёрнутые ответы проверяет ИИ по заданным критериям, а результат можно открыть и пересмотреть.

В адаптивном режиме платформа подбирает следующий вопрос по предыдущим ответам и отдельно уточняет темы, где ответы слабее. Результат — профиль навыков: баллы по компетенциям, сильные стороны и пробелы, которые стоит разобрать на интервью. Мониторинг поведения показывает, как проходил тест: переключения вкладок, вставки текста, паузы. Отчёт выгружается в PDF и Excel, а публичный API позволяет передавать результаты в вашу ATS или HR-систему.

На тех же компетенциях Vibe оценивает и действующую команду. В «Клерке» так проверили 15 разработчиков: у 12 результаты полностью или почти полностью совпали с тем, что руководитель видел в ежедневной работе, — разбор кейса. Подробнее о возможностях платформы — в обзоре Codenrock Vibe.

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

Как использовать. Выберите роль, стек и уровень, соберите тест с помощью ИИ или добавьте свои задания. После прохождения сравните кандидатов по единым критериям и передайте инженеру отчёт для подготовки интервью. Так команда тратит меньше времени на первичный отбор и больше — на содержательный разбор.

Jumse: скрининг по техническому стеку

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

Когда рассмотреть. Если нужен повторяемый первый этап оценки для нескольких технических вакансий.

Что проверить. Сопоставьте темы теста с ежедневными задачами команды и уточните доступ к исходным ответам кандидата. На странице тарифов просмотр вопросов и ответов указан среди возможностей корпоративного пакета, поэтому до покупки меньшего пакета стоит выяснить, какие данные получит техлид для проверки итоговой оценки.

Предложенный сервисом грейд полезно сопоставить с вашей матрицей компетенций: одинаковое название уровня не гарантирует одинаковых требований в разных компаниях. Почему так происходит, мы разбирали в статье «Грейды разработчиков — это договорённость, а не измерение».

TalentTest: технические задания и антифрод

TalentTest предлагает вопросы с выбором ответа, открытые технические вопросы, написание кода, поиск ошибок и отчёт о подозрительных событиях во время теста. У сервиса есть экспресс-тесты и полный формат оценки.

Когда рассмотреть. Если вместе с результатом важно разбирать обстоятельства прохождения теста.

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

Meet2Code: лайвкодинг и задания с проверкой кода

Meet2Code и Enterly — инструменты для этапа живого интервью. Они не заменяют предварительную оценку, а продолжают её: с кандидатом, который прошёл скрининг, инженер разбирает решения в общем редакторе.

Meet2Code объединяет совместный редактор, запуск кода, онлайн-доску, библиотеку собственных задач и воспроизведение набора кода. Для самостоятельных заданий сервис описывает автоматическую оценку на тест-кейсах и ограничение времени.

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

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

Библиотека для хранения собственных задач и готовый банк заданий — разные возможности. В FAQ сервис отдельно пишет, что готовая библиотека ещё развивается, поэтому её наполнение стоит посмотреть до запуска.

Enterly: единый процесс технических интервью

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

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

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

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

Яндекс Контест: задачи с автоматической проверкой

В Яндекс Контесте можно создавать задачи или брать готовые наборы, задавать правила и сроки, автоматически проверять решения и выгружать результаты. Сам Яндекс использует Контест для тестовых заданий при отборе на ИТ-стажировки.

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

Что проверить. Прочитайте соглашение для организаторов: доступ к кабинету организатора Яндекс предоставляет для некоммерческих целей (п. 2.2), а на все загруженные материалы — задания, тесты, решения — организатор выдаёт Яндексу неисключительную лицензию (п. 2.5). Если задачи — ваша интеллектуальная собственность или вы планируете регулярный коммерческий найм, это стоит обсудить заранее. Прогоните заведомо правильные и ошибочные решения, включая крайние случаи, и решите, как баллы будут связаны с критериями вакансии.

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

StartExam: корпоративная система тестирования

StartExam — универсальная система тестирования, которую применяют и для оценки ИТ-специалистов. В опубликованном кейсе компания описывает тестирование разработчиков, DevOps-инженеров, администраторов СУБД и архитекторов: вопросы по теории, поиск ошибок в коде, передачу решения файлом на ручную проверку. Открытые ответы можно обрабатывать с помощью ИИ, есть прокторинг.

Когда рассмотреть. Если компания строит собственную систему оценки знаний и хочет использовать её для разных ИТ-ролей и действующих сотрудников.

Что проверить. Запросите актуальный список языков и форматов практических заданий, условия подключения модулей и объём готового ИТ-контента. Выясните, какие задания проверяются автоматически, а какие требуют эксперта: от этого зависит нагрузка на команду.

Зарубежные ориентиры: HackerRank и Codility

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

Дополнительный сигнал: подтверждённые навыки hh.ru

На hh.ru кандидат может подтвердить технические навыки, а работодатель — увидеть отметки в резюме. Доступны теоретические тесты и, для ряда технологий, практические задания с запуском кода: Python, Java, C#, C++, SQL, PHP и Go. Форматы перечислены на странице подтверждения навыков hh.ru.

Когда использовать. Для дополнительной проверки сведений из резюме и подготовки вопросов к интервью.

Граница применения. Это подтверждение отдельных навыков в системе hh.ru, а не задание под вашу вакансию: компания может предъявлять другие требования к стеку, сложности и рабочему контексту. Отсутствие отметки тоже не означает, что кандидат не владеет навыком.

Как выбрать платформу под вашу вакансию

Начните с рабочих задач

Сначала опишите, что должен делать разработчик после выхода в команду, затем выберите формат проверки. Ниже — примеры заданий, которые можно адаптировать под роль; они не привязаны к конкретному сервису. Как описать сами компетенции для роли, мы разбирали в руководстве по оценке компетенций в ИТ-отделе.

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

Проверьте, что стоит за итоговым баллом

Попросите показать полный путь от ответа до оценки. Какие тесты прошли? Где потеряны баллы? Можно ли увидеть исходный код? Почему ИИ счёл ответ неполным? Может ли интервьюер исправить оценку и оставить объяснение?

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

Заранее определите правила использования ИИ

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

Событие прокторинга — повод разобраться, а не приговор. Вставка текста или переключение вкладки сами по себе не объясняют, чем пользовался кандидат и нарушил ли согласованные правила.

Посчитайте нагрузку на кандидата и команду

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

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

Проверьте, как результат попадёт в систему найма. Попросите показать конкретный сценарий: приглашение из карточки кандидата, смену статуса и получение отчёта через API.

До покупки запросите условия договора с вашим юридическим лицом, оплаты в рублях и получения закрывающих документов. Уточните, что считается оплаченной попыткой, как учитываются незавершённые тесты и повторные прохождения, можно ли перенести остаток пакета. Отдельно проверьте хранение и удаление ответов, разграничение доступа, экспорт результатов и поддержку при сбоях.

Как провести пилот перед покупкой

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

1. Согласуйте критерии. Выберите несколько обязательных компетенций и опишите признаки сильного, пограничного и недостаточного ответа. До начала пилота запишите условия покупки: нужные форматы заданий и отчётов, допустимые трудозатраты и критичные ошибки оценки. Рекрутер проверяет маршрут кандидата, техлид — задания и баллы, руководитель найма — результат пилота.
2. Подготовьте небольшой пробный набор. Пригласите, например, 12–20 добровольных участников разного уровня. Этого достаточно, чтобы найти очевидные проблемы, но недостаточно, чтобы доказать точность оценки на всём потоке.
3. Сделайте независимый разбор. Пусть два инженера оценят ответы, не видя итогового балла платформы. Зафиксируйте и расхождения между самими экспертами.
4. Разберите ошибки. Посмотрите, кого система оценила слишком высоко или низко, какие решения не смогла корректно проверить, какие события антифрода потребовали уточнения.
5. Посчитайте результат. Сравните долю начавших тест среди приглашённых и долю завершивших среди начавших, время кандидата и инженера, стоимость оценки и расхождения с независимым разбором. Отдельно посмотрите на участников, которых система предложила бы отсеять: среди них могут быть подходящие кандидаты. Позже, на рабочем потоке, отслеживайте, сколько прошедших скрининг подтверждают нужные компетенции на интервью, и сопоставляйте результаты внутри одной вакансии и грейда.

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

После пилота сформулируйте решение: какой этап вы автоматизируете, кто разбирает спорные ответы и по каким результатам пересмотрите выбор платформы. Так закупка будет связана с изменением процесса найма.

Проще всего начать с одной открытой вакансии: соберите в Codenrock Vibe тест под роль, пригласите нескольких кандидатов и сравните отчёт платформы с впечатлениями интервьюеров. На странице Vibe для ИТ-команд можно запросить демо.

В материале — выбор заданий, проверка спорных баллов, пилот и план развития. В записи — демонстрации отчёта и ИПР, а также обсуждение вопросов участников. Нужные фрагменты доступны по таймкодам.

Смотреть запись и читать итоги вебинара →

Попросили ИИ предложить идеи. Получили десять помощников: умного, персонального, проактивного и ещё семь почти таких же.

Чтобы получить другой результат, измените сам вопрос. Можно разобрать задачу на части, переделать готовую идею, перенести подход из другой области или специально придумать провал.

Разберём четыре техники на одной учебной задаче: помочь студенту не пропускать дедлайны по курсам. Во всех примерах польза ещё требует проверки — мы пока ищем варианты.

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

Выберите один приём

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

1. Mind map: найдите проблему до выбора технологии

В центре карты напишите: «Студент пропускает срок сдачи». Ветки — этапы его действий:

• Узнать о задании. Информация лежит в разных чатах и учебных системах.
• Понять срок. «До пятницы» — до начала дня или до полуночи?
• Оценить объём. Задание выглядит маленьким, но требует прочитать три главы.
• Начать работу. Напоминание приходит, когда времени уже не осталось.
• Сдать. Файл готов, но загружен не туда или не в том формате.

Вот уже пять разных мест, где можно помочь. Приложение с ещё одним списком дедлайнов — только один вариант.

Как провести: каждый за несколько минут записывает известные трудности. Затем объедините похожие и пометьте, что подтверждено брифом или разговором с пользователем, а что придумано командой.

Задание ИИ:

Разложи путь пользователя [описание] на этапы. Для каждого предложи возможную трудность и вопрос, которым мы проверим её у пользователя. Не выдавай предположения за факты. Не предлагай технологии, пока карта не готова.

После ответа вычеркните ветки, которых нет в вашей задаче. Верните правку: «У нас задания уже собраны в одном месте. Не предлагай ещё один агрегатор. Разверни ветку “начать вовремя” и добавь вопросы пользователю». Проверьте хотя бы ключевое предположение по брифу или разговору.

Результат упражнения — выбранный участок пути и вопрос для проверки. Например: «Действительно ли студенты чаще пропускают срок из-за потерянного сообщения, а не из-за нехватки времени?»

2. SCAMPER: измените готовую идею семью способами

Возьмём основу: «бот напоминает о дедлайнах». Каждая буква SCAMPER — отдельный вопрос к идее.

Не нужно внедрять все семь вариантов. Выберите один-два для сравнения.

Важная ловушка: убрать действие пользователя не всегда значит упростить разработку. «Пусть ИИ сам найдёт все задания во всех чатах» может потребовать сложных доступов и интеграций. Считайте обе стороны: удобство для человека и работу команды.

Задание ИИ:

Примени SCAMPER к идее [описание]. На каждый приём дай один вариант. Для каждого укажи: что меняется для пользователя, что придётся добавить в реализацию и какое предположение проверить. Сохрани ограничения: [данные, срок, навыки].

Теперь выберите два интересных варианта и попросите: «Покажи самый простой сценарий каждого. Что придётся сделать вручную, какие данные нужны, без чего он не работает?» Если вариант требует недоступных интеграций, попросите уменьшить объём. На выходе нужен вариант, который команда может попробовать, а не только красивое описание.

3. Аналогии: позаимствуйте работающую механику

Полезная аналогия объясняет действие, а не только внешний вид.

Например, навигатор строит маршрут от текущего положения к цели и пересчитывает его при задержке. В планировщике учёбы можно взять именно это: разбить задание на шаги и пересчитать план, если студент пропустил один день.

Но вместе с механикой появляется вопрос: откуда взять оценку длительности шагов? Если модель просто угадает её, план может оказаться бесполезным. Для прототипа можно предложить пользователю указать время самому.

Упражнение на 15 минут: выберите три знакомых сервиса, выпишите по одному принципу их работы и попробуйте перенести его на задачу.

Задание ИИ:

Найди три аналогии для [задача] из других областей. Для каждой объясни механику, её перенос и место, где аналогия перестаёт работать. Не ограничивайся фразами «как Uber для…».

После списка аналогий выберите одну: «Разверни идею с навигатором в три действия пользователя. Не добавляй новые функции». Пройдите эти действия на бумаге. Если непонятно, откуда берутся данные, верните вопрос модели и упростите сценарий. К следующему этапу идите, когда можете объяснить действия без самой аналогии.

4. Обратный штурм: придумайте худшее решение

Вопрос команде: «Как сделать так, чтобы наш сервис дедлайнов хотелось удалить через день?»

Возможные ответы:

• Присылать десять уведомлений об одном задании.
• Уверенно придумывать отсутствующий срок.
• Напоминать после завершения работы.
• Не давать исправить ошибку распознавания.

Переведите каждый провал в проверку: ограничение частоты, ссылка на исходное сообщение, статус «выполнено», ручное редактирование.

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

Попросите ИИ: «Назови пять ситуаций, в которых наш основной сценарий подведёт пользователя». Затем: «Оставь две самые важные. Для каждой дай входной пример, ожидаемое поведение и способ проверки». Пройдите примеры сами. Если система ведёт себя иначе, исправьте её и повторите проверку — список рисков без этого ещё ничего не улучшил.

Как отсеять идеи после упражнений

Сначала — обязательные условия. Соответствие брифу, разрешённые технологии, доступные данные и выполнимый формат сдачи. Если идея нарушает условие, измените её или отложите. Одного такого препятствия может быть достаточно.

Затем — сравнение оставшихся вариантов. Для каждого заполните четыре строки:

Пользователь получает: … Доказательство на защите: … Самая маленькая работающая версия: … Главный риск и способ его проверить: …

Например, «автоматически читать все студенческие чаты» зависит от доступа к ним. «Извлекать срок из вставленного сообщения и просить подтверждение» можно проверить без этой интеграции. Второй вариант уже по охвату — это может быть полезно для короткого хакатона, если он соответствует заданию.

Передайте ИИ заполненные карточки: «Сравни по этим критериям. Не ставь оценку, если нет данных; вместо неё напиши, что проверить». Команда выполняет доступные проверки и выбирает вариант. Ответ «пользователи точно оценят» оставляйте в разделе предположений, пока люди сами не попробуют решение.

Что забрать из упражнения

Одну выбранную идею, один главный риск и одну ближайшую проверку. Если осталось десять направлений без решения, продолжение генерации вряд ли поможет — пора сравнивать.

Для полного маршрута от задания к выбору используйте план на 90 минут. А чтобы выбранная идея поместилась в срок, определите границы MVP.

Коротко

• Начните с брифа: запишите пользователя, задачу, критерии оценки, обязательные условия и формат сдачи.
• Просите ИИ предлагать разные способы решения, а не разные названия одного чат-бота. Оставьте два варианта и проверьте главный риск каждого.
• Для короткого продуктового хакатона можно выделить 90 минут на выбор идеи, включая разбор брифа и проверку риска. Это ориентир, а не универсальный срок.
• Зафиксируйте выбранный сценарий, границы проекта и первые задачи. Меняйте решение по новым данным, а не только потому, что появилась ещё одна идея.

«Придумай 20 идей для хакатона» — и через несколько секунд у вас есть умный помощник, рекомендательная система и платформа, объединяющая всё со всем.

Идей стало больше. Понимания, какую делать, не прибавилось.

Чтобы выбрать из этого списка, вернитесь к трём вопросам: кому помогаем, что человек получит и успеем ли мы это проверить. Ниже — маршрут на 90 минут. Это пример тайминга для короткого продуктового хакатона: сложному исследовательскому треку может понадобиться больше времени на данные и эксперименты.

Результат этих 90 минут: выбранный сценарий, проверенный главный риск и первые задачи. Список из ста идей для этого не нужен.

0–15 минут. Разберите бриф вместе

Откройте задание и регламент. Заполните пять строк в общем документе:

ИИ здесь — помощник по разбору документов. Передайте разрешённый к загрузке текст и попросите не смешивать требования с догадками.

Извлеки из брифа пользователя, задачу, критерии, обязательные условия и формат сдачи. Для каждого пункта приведи короткую цитату и раздел документа. Если информации нет, напиши «не указано». Отдельно перечисли вопросы организатору. Не предлагай решения на этом шаге.

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

Сверьте ответ с оригиналом, особенно сроки и запреты. Если нет прямого ответа, уточняйте у организаторов: модель не может разрешить использование внешнего API или изменить условия трека.

Если ИИ перепутал условие, не просите просто «переделать». Укажите расхождение: «В разделе 3 нужен экспорт, а у тебя его нет. Исправь список и покажи, какие ещё требования пропущены». Переходите дальше, когда список совпадает с брифом.

15–25 минут. Найдите момент, который хотите улучшить

Допустим, в брифе написано: «Повысить эффективность поддержки».

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

Выберите один участок. Например: оператор тратит время на поиск нужного пункта инструкции.

Теперь гипотеза звучит так:

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

Пока это предположение. Запишите, что его подтвердит: например, сравнение времени поиска и правильности выбранного фрагмента на одинаковом наборе обращений.

Не придумывайте исходные цифры. Если вы не знаете, сколько времени уходит сейчас, так и обозначьте: «нужно измерить».

Теперь попросите: «Перечисли возможные причины этой проблемы. Отдели то, что известно из брифа, от предположений. К каждому предположению добавь вопрос для проверки». Выберите проблему, для которой у вас есть данные или возможность уточнить ответ. Не выбирайте только по уверенности формулировки.

25–40 минут. Получите несколько разных решений

Сначала каждый участник предлагает по два варианта самостоятельно. Потом подключите ИИ для расширения набора — так у команды останутся собственные исходные версии.

Просите различия в механике, а не десять названий одного чат-бота.

Задача: [описание]. Пользователь: [роль]. Доступны: [данные, инструменты]. Команда: [навыки], срок: [время]. Предложи четыре разных подхода: простые правила, поиск по материалам, решение с языковой моделью и изменение самого процесса. Для каждого укажи вход, результат, необходимые данные и самое рискованное допущение. Не выдумывай исследования и показатели рынка.

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

После первого ответа дайте обратную связь: «Варианты 1 и 3 — один и тот же поиск с разными названиями. Объедини их. Добавь вариант без языковой модели и объясни, что он позволит проверить». Оставляйте подходы, которые отличаются действиями и данными.

Если варианты всё равно похожи, используйте одну из методик генерации идей. Не нужно проходить все техники подряд.

40–55 минут. Оставьте два варианта

Сначала проверьте обязательные условия. Идею нельзя спасать высокой оценкой «за красоту», если она не соответствует заданию или требует недоступных данных.

Потом сравните кандидатов:

• Какой критерий соревнования закрывает решение?
• Как пользователь получит результат?
• Чем докажем, что подход работает?
• Что команда умеет делать уже сейчас?
• Какая зависимость может остановить работу?

Можно поставить оценки по шкале 1–3, но рядом напишите основание. «Реализуемость — 3, API уже проверили» полезнее, чем «кажется несложно». Если у критериев есть веса, учитывайте их.

Отдайте ИИ свои оценки и спросите: «Где мы поставили высокий балл без доказательств? Какое недостающее условие может поменять выбор?» Исправьте оценки по данным, а не по новому мнению модели. На выходе должны остаться два кандидата с понятными рисками.

55–75 минут. Проверьте то, на чём всё может сломаться

У одного варианта неизвестно качество поиска. У другого — есть ли доступ к нужному API. Проверьте самый опасный риск каждого кандидата маленьким экспериментом.

Примеры проверки:

• Отправить один разрешённый запрос в API и посмотреть настоящий ответ.
• Открыть датасет: нужные поля вообще есть?
• Найти правильную инструкцию для нескольких разных обращений.
• Запустить простое базовое решение, с которым потом будете сравнивать улучшение.

Красивый экран не снимет риск, что нужных данных нет. На этом шаге вполне достаточно консоли или таблицы.

Верните ассистенту результат эксперимента: «Ожидали X, получили Y. Какие объяснения согласуются с наблюдением? Как различить их одной проверкой?» Выберите и выполните проверку. Если ИИ снова предлагает уже отвергнутый вариант, напомните результат и исключите повтор.

Если проверить предположение быстро не получается, запишите неопределённость. Иногда разумнее выбрать менее эффектный вариант с доступными данными; иногда риск оправдан критериями трека. Главное — понимать, чем вы рискуете.

75–90 минут. Зафиксируйте решение

Сделайте короткую карточку проекта:

Делаем: поиск инструкции по обращению оператора. Показываем: обращение → найденный фрагмент → ссылка на источник. Проверяем: найден ли правильный документ на подготовленном наборе вопросов. Пока не делаем: автоматическую отправку ответа клиенту и интеграцию со всеми каналами поддержки. Главный риск: в базе может не быть ответа; в этом случае показываем, что он не найден. Следующая проверка: [время, ответственный, результат].

Попросите ИИ сверить карточку с исходным брифом: «Что мы забыли? Где обещаем больше, чем проверили?». Уберите обещания без проверки, сохраните финальную карточку и передавайте её в дальнейшие чаты как контекст.

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

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

А если завтра появилась идея лучше?

Менять курс имеет смысл, когда появилась новая информация: обязательное API недоступно, ключевых данных нет, эксперт указал на неверно понятое требование.

Перед сменой ответьте на три вопроса:

1. Что конкретно делает текущий путь неудачным?
2. Сколько готовой работы пригодится в новом варианте?
3. Когда проверим, что новый путь действительно работает?

Если единственный аргумент — «ИИ предложил ещё более интересную идею», сначала доведите текущую до ближайшей проверки. Новизна сама по себе не сокращает объём работы.

С чего начать прямо сейчас: откройте бриф и заполните пять строк из первого блока. Затем поставьте время, к которому команда выберет сценарий.

После выбора: определите границы MVP и распланируйте работу до дедлайна.

Для других форматов есть отдельные инструкции: ML-соревнование, кейс-чемпионат, CTF jeopardy.