Тестовое задание при найме

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Всем

Тестовое задание — практическая проверка навыков между скринингом 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 — скорость на фрагменте.

---

Перед тем как согласиться

Задайте рекрутеру или тимлиду уточняющие вопросы (можно письменно):

1. Срок — календарные дни или рабочие; можно ли короткое продление при болезни.
2. Ожидаемые трудозатраты — «2–4 часа» или «полноценный мини-проект на выходные».
3. Формат сдачи — GitHub (приватный invite), архив, деплой.
4. Стек — обязательный и желательный; можно ли заменить близким аналогом.
5. Обратная связь — при отказе дадут ли разбор (часто только у сильных кандидатов).

Ориентир по времени

Для 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, оплата при большом объёме, единые критерии оценки.

---

Что запомнить

1. Тестовое проверяет процесс и результат, а не только синтаксис.
2. Готовьтесь типами задач под вакансию, своими проектами в портфолио.
3. Уточняйте срок и объём до старта; отказ при злоупотреблении — норма.
4. README, тесты и честный список «не вошло в scope» часто решают так же, как фича.
5. На follow-up вас попросят объяснить и дописать сданное — к этому готовьтесь сразу.

---