Тестовое задание: как сдавать и что важно

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

Коротко. Тестовое задание для джуна — часто главный шанс: оно позволяет обойти кандидатов с более красивым резюме. Оценивают не только «работает/не работает», а процесс: вопросы к задаче, структуру решения, README и то, как вы объясняете свои выборы. Разумный лимит бесплатного тестового — 4–8 часов работы; недельные «проекты под ключ» без оплаты — красный флаг. Место тестового в воронке — от отклика до оффера.

Делать ли тестовое: критерии

Делать	Отказаться / обсудить
Объём 2–8 часов, задача учебная/синтетическая	Объём 20+ часов «сделайте нам фичу» на реальном продукте
Чёткое ТЗ и срок, есть контакт для вопросов	ТЗ размытое, «на ваше усмотрение» без ответов на вопросы
После тестового обещано интервью с разбором	«Пришлите, мы посмотрим» без этапов и обратной связи
Вы джун и вам нужна практика собеса	Просят до любого разговора, вакансия без деталей — признак сбора бесплатной работы

Джуну стратегически выгодно делать почти все адекватные тестовые: каждое — тренировка + артефакт для портфолио (с разрешения — выложить на GitHub).

Что реально оценивают

Вопросы до старта. Кандидат, задавший 2–3 уточняющих вопроса, уже выделился: в реальной работе ТЗ всегда неполное. Молча угадывать — типичная ошибка джуна.
Соответствие ТЗ. Сделать ровно то, что просили. Недоделанное обязательное — минус; гора необязательных фич вместо обязательных — тоже минус («не умеет читать требования»).
Структуру и читаемость: наименования, разбиение на функции/файлы, отсутствие мёртвого кода. Джуновский код читают внимательнее сеньорского.
Обработку краёв: пустой ввод, ошибки сети, некорректные данные. Именно здесь 80% кандидатов сыпется.
README и подачу — см. ниже; решение без инструкции запуска часто не запускают вообще.

Процесс выполнения: от письма до сдачи

Подтвердите получение и срок: «Спасибо, беру. Пришлю до вечера четверга». Управляемость — редкое и заметное качество.
Задайте вопросы пакетом (не по одному): формат данных, что важнее — полнота или чистота, можно ли использовать библиотеку Х.
Скелет → ядро → края → полировка. Сначала минимальный работающий путь, потом обработка ошибок, в конце — рефакторинг и README. Если время кончается — лучше меньше фич, но аккуратно, чем всё и сыро.
Зафиксируйте компромиссы: всё, что упростили, — в README, в раздел «Что бы я улучшил». Это снимает половину претензий и превращает слабости в осознанные решения.
Сдайте до дедлайна коротким письмом: ссылка, как запустить, 2–3 главных решения. Опоздание без предупреждения оценивают строже, чем недоделанную фичу.

Специфика по ролям

Frontend: обязательно — точность по макету, адаптив, состояния загрузки/ошибки/пустоты; демо на Vercel/Netlify к решению.
Backend: README с примерами запросов (curl), валидация ввода, коды ответов, пара тестов на ключевую логику; docker-compose — жирный плюс.
QA: тестовое — обычно «протестируйте форму/приложение»: структурированные кейсы (классы эквивалентности, границы!), баг-репорты по шаблону, приоритеты. Оценивают систему мышления, а не количество багов — как оформлять правильно.
Аналитика: ноутбук с выводами текстом (не только код), проверка данных на дубли/NULL, график с подписями; ответ на вопрос бизнеса, а не «покрутил данные».
DevOps: IaC/пайплайн по ТЗ + схема в README; секреты — только через переменные окружения, захардкоженный токен = провал.

Оформление и сдача

Репозиторий на GitHub (приватный, если просили) с осмысленными коммитами — историю смотрят.
README: задача одним абзацем → запуск в 1–3 команды → решения и компромиссы → «что бы улучшил».
Код прогнан через линтер/форматтер; ни одного print/console.log из отладки.
Проверка на чистой машине или в чистом контейнере: «у меня работало» — не аргумент.

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

✅ Все обязательные пункты ТЗ выполнены (перечитайте ТЗ построчно).
✅ Запускается по README на чистом окружении.
✅ Крайние случаи: пустой ввод, ошибка сети, некорректные данные.
✅ Нет секретов и мусора в репозитории.
✅ Написан раздел «Что бы я улучшил».
✅ Письмо со сдачей: ссылка + запуск + 2–3 решения + готовность обсудить.

Частые вопросы

Сколько времени нормально тратить на тестовое?
Джуну — до 8 часов чистой работы. Если по ТЗ выходит больше — либо уточнить объём, либо предложить сделать часть, либо вежливо отказаться.

Платят ли за тестовые?
В РФ джуновские тестовые почти всегда бесплатные. Оплата встречается на мидл+ и в дизайне. Бесплатная «реальная задача из продакшена» на 3 дня — повод насторожиться.

Можно ли использовать ИИ (ChatGPT/Copilot)?
Если не запрещено — можно как инструмент, но вы обязаны понимать каждую строку: на разборе спросят «почему здесь так». Не можете объяснить — считайте, что списали.

Что делать после сдачи, если молчат?
Через 3–5 рабочих дней — вежливый follow-up. Ещё через неделю тишины — двигаетесь дальше; своё тестовое (если не под NDA) — в портфолио.

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