Тестовое задание при найме
Тестовое задание — практическая проверка навыков между скринингом HR и финальным оффером. Работодатель смотрит, как вы решаете задачу, оформляете результат и объясняете решения. Формат зависит от роли — у разработчика чаще код, у аналитика — SQL и гипотезы, у QA — сценарии и баг-репорты.
Тестовое — это срез инженерной культуры — читаемость, границы задачи, честность в README и готовность обсудить trade-off на следующем раунде.
Материал дополняет подготовку к техническому собеседованию, воронку HR, портфолио и образовательные траектории. Краткий чек-лист — шпаргалка.
Где применяют компании дают тестовое
Резюме и короткое интервью показывают заявленный стек. Тестовое подтверждает практику:
- умение довести задачу до рабочего состояния;
- писать понятный код или отчёт;
- задавать уточняющие вопросы;
- укладываться в срок.
Типичные критерии оценки:
| Критерий | Что имеют в виду проверяющие |
|---|---|
| Соответствие ТЗ | Сделаны обязательные пункты; опциональные — по силам и с пометкой в README |
| Качество решения | Структура проекта, именование, обработка ошибок и краевых случаев |
| Процесс | Коммиты, тесты, инструкция запуска, .env.example без секретов |
| Мышление | Комментарий "что бы улучшил в проде", альтернативы, ограничения |
| Коммуникация | Письмо с сопровождением: что сделано, что сознательно отложено |
На аутсорсе часто дают задачу из реального стека заказчика — мини-API, ревью модуля, правка уязвимости. В продуктовых компаниях — стажёрские или изолированные кейсы без доступа к продакшену.
Форматы проверки
Один и тот же отбор может сочетать несколько этапов.
Live coding
Кандидат пишет или дополняет код в реальном времени: shared editor, IDE с демонстрацией экрана. Проверяют ход мыслей, базовый синтаксис, умение объяснять вслух. Обычно 30–60 минут, задача проще, чем полноценный take-home.
Как готовиться: решать задачи на доске или в редакторе без автодополнения; проговаривать шаги; повторить основы из статьи про техническое интервью.
Take-home (домашнее задание)
Задачу выносят на 2 часа — 5 рабочих дней. Ожидают репозиторий, архив или ссылку на деплой. Это основной формат для junior и middle в разработке, аналитике и DevOps.
Как готовиться: заранее иметь шаблон репозитория (README, линтер, CI по желанию); отработать 2–3 учебных проекта того же типа, что в вакансии (см. ниже).
Парное программирование
Интервьюер и кандидат вместе дописывают фичу или чинят баг. Важны диалог, вопросы к постановке и аккуратные мелкие коммиты по ходу.
Кейсы без "большого репозитория"
| Роль | Типичное содержание |
|---|---|
| Аналитик / data | SQL-запросы, разбор метрик, гипотеза A/B, краткий отчёт или ноутбук |
| QA | Тест-план, чек-лист, баг-репорты, иногда автотест на API или UI |
| DevOps / SRE | Dockerfile, compose, pipeline, скрипт деплоя или диагностики |
| Техписатель | Фрагмент документации по вымышленному API |
Подробнее про роли — в специализациях; про грейды и стажировки — в этапах роста.
Чем тестовое отличается от пет-проекта
| Пет-проект / портфолио | Тестовое при найме | |
|---|---|---|
| Цель | Рост, эксперимент, витрина навыков | Проверка под конкретную вакансию |
| Срок | Без жёсткого дедлайна | Фиксированный (часто 3–7 дней) |
| Объём | Вы сами задаёте scope | Scope задаёт работодатель |
| Публикация | Открытый GitHub, статьи | Часто NDA на формулировку; код — только ревьюерам |
Удачное тестовое можно переработать в портфолио — обезличить бренд, переименовать репозиторий, дописать тесты и описать архитектуру — по правилам из статьи про портфолио.
Как готовиться до отклика
Публичные "утёкшие" формулировки заданий в сети полезны как ориентир сложности и стека. Имеет смысл прочитать условие, оценить часы, сделать свою реализацию с нуля. Готовые решения с агрегаторов редко выдерживают углублённый разбор на follow-up: вопросы про архитектуру, тесты и компромиссы выдают чужой след.
Учебные "типы" задач под вакансию
Соберите 2–3 проекта, близких к тексту вакансии:
| Тип вакансии | Учебный аналог (свой код) |
|---|---|
| Backend API | CRUD + авторизация + PostgreSQL + OpenAPI или README с примерами curl |
| Frontend | SPA по макету (или упрощённому wireframe), роутинг, форма, работа с API |
| Full-stack | Тонкий backend + фронт + деплой на бесплатный хостинг |
| Аналитика | Датасет (open data) + SQL + 3–5 слайдов выводов |
| QA manual | Тест-план к демо-приложению + 5 оформленных баг-репортов |
| QA auto | 10–20 автотестов API (pytest, Jest, Playwright — по стеку вакансии) |
| DevOps | Dockerfile + docker compose + простой CI (lint/test) |
Связь с карьерным планом: краткосрочная цель "за 6 месяцев — проект в портфолио под стек вакансии" совпадает с подготовкой к take-home.
Техническая база
Параллельно держите в тонусе то, что спрашивают на техническом интервью — Git, HTTP, SQL, основы ООП, один фреймворк из вакансии. Take-home проверяет сборку целого, live coding — скорость на фрагменте.
Перед тем как согласиться
Задайте рекрутеру или тимлиду уточняющие вопросы (можно письменно):
- Срок — календарные дни или рабочие; можно ли короткое продление при болезни.
- Ожидаемые трудозатраты — "2–4 часа" или "полноценный мини-проект на выходные".
- Формат сдачи — GitHub (приватный invite), архив, деплой.
- Стек — обязательный и желательный; можно ли заменить близким аналогом.
- Обратная связь — при отказе дадут ли разбор (часто только у сильных кандидатов).
Для junior разумный объём take-home — порядка 3–8 часов чистого времени.
Задание на 20+ часов без оплаты — повод обсудить сокращение scope или отказ.
Ваше время — ресурс; его можно вложить в пет-проект с открытым итогом в портфолио.
Красные флаги (когда вежливо отказаться)
| Сигнал | Почему это риск |
|---|---|
| "Сделайте полноценный модуль нашего продукта" | Бесплатная разработка под видом теста |
| Нет срока и критериев приёмки | Бесконечные правки |
| Только закрытый доступ, без договора о данных | Серая зона с интеллектуальной собственностью |
| Десятки кандидатов на одну "идею стартапа" | Конкурс идей без оплаты |
| Угроза "без тестового в базу не попадёте" при сотнях откликов | Давление на рынке с перегретым junior-сегментом |
Отказ — нормальная часть соискательской симметрии: вы тоже оцениваете работодателя. Кратко объясните причину ("объём выходит за разумные 8 часов") и предложите альтернативу — ссылку на близкий проект в портфолио или live coding.
Как выполнять take-home
1. Прочитать ТЗ дважды
Выделите must have и nice to have. Если формулировка размыта — один короткий список вопросов рекрутеру; это плюс, а не слабость.
2. Ограничить scope
Лучше сделать меньше, но стабильно — авторизация работает, пустые списки обработаны, README честен. В конце README — блок "Сделано / Отложено / Нужно ещё N часов для …".
3. Оформить как production-lite
Минимум для разработки:
/README.md — что это, как запустить, переменные окружения
/.env.example — без реальных ключей
/requirements или package.json — зафиксированные версии
/tests/ — хотя бы smoke по критичному пути
Для аналитики — воспроизводимый ноутбук или SQL-файл + results/ или скриншоты. Для QA — таблица сценариев и шаблон баг-репорта.
4. Коммиты
Несколько осмысленных коммитов ("init", "auth", "tests") показывают процесс лучше, чем один "final".
5. Сопроводительное письмо
На 5–10 предложений:
- ссылка на репозиторий или деплой;
- что реализовано из ТЗ;
- известные ограничения;
- сколько времени ушло (по желанию);
- готовность разобрать на созвоне.
Чек-лист перед отправкой
Полный чек-лист с вопросами рекрутеру, красными флагами и шаблоном письма — в шпаргалке. Перед отправкой пройдите его целиком; здесь — только напоминание о главном — запуск по README с нуля, секреты вне репозитория, честный блок "Сделано / Отложено" в README, готовность дописать решение на follow-up.
После отправки
- Соблюдайте обещанный срок; при задержке — предупредите заранее.
- На техническом интервью будьте готовы живьём менять код из тестового — добавить поле, починить тест, объяснить выбор БД.
- При отказе запросите feedback одним предложением; часть компаний ответит — это материал для следующего цикла.
- Поведение после этапов — в статье про HR.
Этика и честность
- Сдавайте свой код и тексты; ИИ допустим как помощник, если вы понимаете каждую строку и готовы переписать по запросу.
- Устаревшие публичные задания (другой год, другой фреймворк) — только для тренировки; на реальном отборе условие будет свежее.
- Узнаваемое тестовое из открытых списков в портфолио лучше обезличить — своё название, свой README, без формулировки "задание компании X".
Плагиат и "скачанное решение" бьют по репутации сильнее, чем слабый, но честный MVP.
Кратко по ролям
Разработчик (backend / frontend / mobile)
Чаще всего — REST или GraphQL, форма, список, авторизация, деплой по желанию. Смотрят на структуру папок, тесты, обработку ошибок. Mobile — экраны, навигация, работа с API, иногда offline-кэш.
Аналитик и data
Акцент на SQL, здравый смысл в метриках, оформление выводов. Продуктовый аналитик — гипотеза, дерево метрик, интерпретация, а не только "запрос выполнился".
QA
Manual — структура тест-дизайна. Automation — стабильные селекторы, Page Object или аналог, отчёт о прогоне. Иногда дают сломанное приложение — цель найти критичные дефекты.
DevOps / платформа
Идемпотентность скриптов, безопасность образов (не root без нужды), логи и healthcheck. Документируйте, как проверить результат ревьюеру за 10 минут.
Связь с портфолио и рынком
Сильное take-home закрывает дыру "нет коммерческого опыта" рядом с пет-проектами. На перегретом junior-рынке (проблемы рынка труда) качественное тестовое иногда важнее ещё одного сертификата — особенно в аутсорсе и небольших продуктах.
Руководителю, который назначает тестовые, полезен взгляд из найма в команде — разумный scope, оплата при большом объёме, единые критерии оценки.
Что запомнить
- Тестовое проверяет процесс и результат, а не только синтаксис.
- Готовьтесь типами задач под вакансию, своими проектами в портфолио.
- Уточняйте срок и объём до старта; отказ при злоупотреблении — норма.
- README, тесты и честный список "не вошло в scope" часто решают так же, как фича.
- На follow-up вас попросят объяснить и дописать сданное — к этому готовьтесь сразу.