Тестовое задание или алгоритмические задачи: почему проект на дом лучше контеста
Найм разработчиков много лет строился по одной схеме. Сначала алгоритмические задачи или контест: развернуть связный список, найти путь в графе, уложиться в ограничение по памяти. Потом лайвкодинг с интервьюером. Схема никогда не была идеальной, но она хотя бы отсеивала тех, кто совсем не умеет программировать.
Сейчас она ломается. Типовую алгоритмическую задачу нейросеть решает за несколько секунд, и решает чисто. Контест без контроля проверяет, кто быстрее скопирует ответ, а с жёстким контролем всё равно проверяет навык, который в обычной работе почти не нужен.
Мы считаем, что честный способ понять, как человек будет работать, остался один: дать ему задачу, похожую на настоящую работу, и посмотреть, как он с ней справится. Ниже разберём, почему, и ответим на главные возражения против тестовых заданий. А как составить такое задание, мы рассказали в отдельной статье «Тестовое задание для разработчика».
Что не так с алгоритмическими задачами и контестами
Первая проблема очевидная: их решает ИИ. Задачи из контестов и сборников для подготовки к собеседованиям хорошо известны и разобраны тысячи раз, и любая современная модель решит их быстрее и аккуратнее большинства людей.
Вторая проблема была и раньше: такие задачи проверяют подготовку к собеседованиям, а не работу. Человек, который месяц тренировался на типовых задачах, пройдёт контест лучше опытного инженера, который десять лет строил сервисы, но давно не вспоминал, как развернуть дерево. В итоге компания отбирает тех, кто хорошо готовится к отбору.
Третья: контест ничего не говорит о том, что действительно важно в работе. Как человек разбивает задачу на части, как называет переменные, пишет ли тесты, как организует проект, что делает, когда в условии есть неопределённость.
Что не так с лайвкодингом
Лайвкодинг честнее контеста: интервьюер видит, как человек думает. Но и у него есть ограничения.
Это стресс, который мало связан с работой. Писать код под взглядом незнакомого человека за 45 минут умеют не все сильные разработчики, и часть из них на этом проваливается.
Это дорого. Каждый лайвкодинг занимает час времени опытного инженера, а кандидатов на одну вакансию бывают десятки.
И это всё равно маленькая задача. За час не построишь даже небольшой сервис, а значит, архитектуру, тесты и организацию кода вы так и не увидите.
Лайвкодинг хорошо работает как разговор о решении, которое кандидат уже сделал. Как основной фильтр он слишком дорог и слишком узок.
Что показывает проект на дом
Тестовое задание в формате проекта устроено как обычная рабочая задача: есть требования, есть несколько дней, есть репозиторий, куда нужно сдать решение. Например, написать небольшой чат-бот для банка, найти и исправить баги в готовом проекте или собрать интерактивный отчёт по данным рынка.
В таком решении видно то, чего не видно в контесте:
- как кандидат разбивает задачу и устраивает проект;
- выполнены ли требования и что он сделал, когда условие было неоднозначным;
- есть ли тесты и собирается ли проект;
- насколько код понятен человеку, который откроет его через полгода;
- какие компромиссы кандидат выбрал и может ли их объяснить.
И главное: пользоваться ИИ в таком задании можно. В работе разработчик тоже пользуется нейросетями, и это нормально. Важно, что модель не примет за кандидата решения: какую выбрать архитектуру, что покрыть тестами, чем пожертвовать ради срока. Именно эти решения и оцениваются.
Сравнение форматов
| Алгоритмические задачи и контесты | Лайвкодинг | Проект на дом | |
|---|---|---|---|
| Что проверяет | Знание алгоритмов и подготовку к собеседованиям | Мышление на маленькой задаче под давлением | Как человек делает реальную работу |
| Можно ли решить с ИИ | Да, почти полностью | Сложно, но интервьюер тратит час | Можно помочь себе, но решения кандидат принимает сам |
| Время кандидата | 1–2 часа | Около часа | 1–3 вечера |
| Время команды | Почти нет | Час инженера на каждого | Раньше много, сейчас несколько минут с ИИ-проверкой |
| Похоже на работу | Нет | Частично | Да |
Возражение первое: кандидаты не хотят тратить несколько дней
Это правда, если задание огромное, скучное и даётся всем подряд. Сильный кандидат не будет неделю писать бесплатный продукт для компании, которая даже не позвала его на разговор.
Поэтому работает несколько правил. Задание должно занимать один-три вечера, а не неделю. Давать его стоит тем, кто уже прошёл первый этап, например короткий тест или видеоинтервью. Задача должна быть интересной и похожей на настоящую работу в вашей команде: многие разработчики охотнее делают такой проект, чем решают очередную задачу про графы. И каждый кандидат, сдавший проект, должен получить обратную связь.
Возражение второе: проверять проекты долго
Раньше это было главным аргументом против тестовых заданий. Открыть репозиторий, собрать проект, запустить тесты, прочитать код, написать заключение: на одного кандидата уходило от получаса до часа времени тимлида. При потоке в сотни кандидатов это невозможно.
Сейчас большую часть этой работы делает автоматика. В Talense для каждого кандидата создаётся приватный репозиторий с условиями, решение фиксируется на момент сдачи, а дальше платформа сама собирает проект, запускает тесты и проводит ИИ-ревью кода: сильные стороны, слабые места, риски и вопросы, которые стоит задать на собеседовании. Если нужно разобраться глубже, ИИ-ассистент анализирует код и отвечает на вопросы по решению, и ручная проверка занимает около пяти минут.
На практике это выглядит так: в одном из наших проектов через автоматическую проверку прошло 1300 репозиториев кандидатов. Около половины работ оказались слабыми или средними, и они отсеялись без участия проверяющих. Тимлиды смотрели только тех, кто действительно подходил. На что смотреть при ручной проверке, мы собрали в чек-листе для тимлида.
Возражение третье: а вдруг решение сделал не кандидат
Полностью исключить это нельзя ни в одном формате. Но у проекта есть встроенная защита: кандидату предстоит о нём говорить. На собеседовании достаточно попросить объяснить два-три решения из своего кода: почему выбрана такая структура, что будет при росте нагрузки, как бы он поменял проект, если бы требования изменились. Тот, кто делал проект сам, отвечает легко. Вопросы для такого разговора ИИ-ревью предлагает автоматически.
Когда алгоритмические задачи всё ещё уместны
Отказываться от них полностью не обязательно. Короткий тест на базовые знания хорошо работает как первый фильтр при большом потоке, например при наборе стажёров. Только проводить его стоит с прокторингом, иначе вы проверяете ту же нейросеть. А для ролей, где сложные алгоритмы действительно составляют суть работы, такие задачи остаются по делу.
Но если вопрос в том, как человек будет писать и поддерживать обычный продуктовый код, лучше всего на него отвечает проект, похожий на эту работу.
Давайте кандидатам реальные задачи
Приватный репозиторий для каждого кандидата, автоматическая проверка с ИИ и готовые вопросы для собеседования. Около 5 минут на один проект.
Частые вопросы
Что лучше при найме разработчика: тестовое задание или алгоритмические задачи?
Для большинства продуктовых ролей лучше тестовое задание в формате небольшого проекта. Алгоритмические задачи сейчас легко решаются с помощью ИИ и проверяют скорее подготовку к собеседованиям, чем рабочие навыки.
Сколько времени должно занимать тестовое задание для разработчика?
Один-три вечера работы. Дедлайн при этом можно дать в несколько дней, чтобы кандидат мог выполнить задание в удобное время.
Можно ли разрешать кандидату пользоваться ИИ в тестовом задании?
Да. В работе разработчики тоже пользуются нейросетями. Главное, чтобы задание оценивало решения, которые принимает сам кандидат: архитектуру, компромиссы, качество и тесты.
Как быстро проверить тестовое задание разработчика?
Автоматизировать рутину: сборку, запуск тестов и первичное ревью кода. С ИИ-ревью и ассистентом проверка одного проекта занимает около пяти минут, а слабые работы отсеиваются автоматически.
Нужен ли лайвкодинг, если есть тестовое задание?
Как отдельный фильтр обычно нет. Но разговор о решении, которое кандидат уже сделал, очень полезен: он показывает, понимает ли человек свой код и может ли объяснить принятые решения.
