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