Тестовое задание при найме: делать ли, как оценить объём и что смотрят проверяющие

Коротко

Тестовое задание (take-home assignment) — это задача, которую вы делаете дома в своём темпе и отправляете ссылкой на репозиторий. Для одних это шанс показать себя без стресса лайв-кодинга, для других — неоплачиваемая работа на выходные. Обе точки зрения справедливы, поэтому начнём с решения, браться ли вообще.

Стоит ли делать тестовое

Универсального ответа нет. Есть несколько вопросов, которые стоит задать себе и рекрутеру до того, как открывать редактор.

Когда стоит

• Компания вам действительно интересна. Несколько вечеров ради работы мечты — разумная инвестиция. Ради десятого отклика «на всякий случай» — нет.
• Задача похожа на реальную работу. Небольшой сервис, интеграция с API, экран приложения — это честная проверка. Вы заодно узнаете, с чем придётся работать.
• Тестовое заменяет часть этапов. Иногда компания предлагает выбор: тестовое или алгоритмическая секция. Если вы сильнее в продуктовом коде, чем в задачах на время, это хороший обмен.
• Вы плохо проходите лайв-кодинг. Тестовое показывает, как вы пишете код без таймера и наблюдателя, — для многих это ближе к реальной работе.

Когда стоит задуматься

• Объём на неделю, а не на вечер. Если по вашей оценке нужно 20+ часов, это повод обсудить, а не молча сидеть ночами.
• Тестовое дают до первого разговора. Вы ещё не знаете ни вилку, ни команду, ни задачи, а уже должны вложить выходные. Разумно сначала поговорить с рекрутером.
• Задача подозрительно похожа на кусок их продукта. «Сверстайте нам лендинг по макету» или «напишите парсер вот этого сайта» — классический признак того, что тестовое используют как бесплатную работу.
• Непонятно, что будет после. Если рекрутер не может сказать, кто проверит, в какие сроки и какой этап следующий, высок риск, что решение просто потеряется.

Что спросить у рекрутера

Подскажите, пожалуйста: сколько времени вы закладываете на задание? Кто его будет проверять и когда ждать обратную связь? Что происходит на следующем этапе — будем ли обсуждать решение?

Ответы на эти вопросы говорят о компании не меньше, чем само задание. Если на вопрос о сроках проверки отвечают «как получится», учтите это.

Как вежливо отказаться или договориться

Отказ от тестового — не катастрофа. Многие компании готовы заменить его на другой формат:

Мне интересна позиция, но сейчас у меня несколько процессов и не получится выделить два-три вечера. Могу показать открытый проект с похожей задачей или пройти техническое интервью вместо задания. Такой вариант возможен?

Если у вас есть публичный репозиторий, близкий по смыслу, это сильный аргумент. Если нет — можно попросить урезанную версию задания или продлённый срок.

Как оценить объём

Работодатели часто пишут «задание на 3–4 часа». На практике это время, за которое его сделал бы автор, хорошо знающий и задачу, и свой стек. Ваша реальная оценка почти всегда выше.

Разбейте задание на шаги

Выпишите всё, что нужно сделать, включая то, что в тексте задания не сказано прямо:

1. Поднять проект: сборка, линтер, зависимости.
2. Основная бизнес-логика.
3. Ввод-вывод: API, CLI, UI — что требуется.
4. Обработка ошибок и крайних случаев.
5. Тесты.
6. README и инструкции по запуску.
7. Финальная проверка с чистого клона.

Оцените каждый шаг отдельно и умножьте сумму на полтора-два: на незнакомом API, странной ошибке сборки или переписывании первого подхода всегда теряется время. Если итог сильно больше заявленного, уточните у рекрутера, что важнее, или сократите объём осознанно.

Найдите обязательное и необязательное

В хорошем задании явно сказано, что обязательно, а что — плюс. Если не сказано, спросите. Вопрос по заданию — нормальная часть процесса, а не признак слабости. Тот же навык нужен на техническом интервью: уточнить требования до того, как писать код.

Типичные вопросы:

• Какие версии языка и фреймворка допустимы?
• Нужно ли хранилище или достаточно памяти процесса?
• Насколько важен UI, если задание фронтендовое?
• Можно ли использовать сторонние библиотеки?
• Как отправить решение: публичный репозиторий, приватный с доступом, архив?

Что смотрят проверяющие

Конкретный чек-лист у каждой компании свой, но общие пункты повторяются почти везде. Важно понимать порядок: проверяющий открывает репозиторий и за первые минуты решает, стоит ли читать код внимательно.

1. Запускается ли проект

Первое, что делает проверяющий, — пытается запустить проект по README. Если не получилось, дальше многое не важно. Поэтому:

• Проверьте запуск на чистом клоне: git clone во временную папку, установка зависимостей, запуск.
• Зафиксируйте версии: lock-файл, версия языка, при необходимости Dockerfile или docker-compose.yml.
• Не оставляйте зависимостей от своего окружения: абсолютных путей, локальной базы с данными, переменных среды без примера.

2. README

README — первое, что читают, и часто единственное, что читают внимательно. Хороший README к тестовому короткий и отвечает на четыре вопроса:

## Как запустить

docker compose up --build

# API на http://localhost:8080, документация на /docs

## Как запустить тесты

make test

## Что сделано

- Создание, просмотр и отмена заказов
- Валидация входных данных, ошибки в едином формате
- Тесты на бизнес-логику и основные эндпоинты

## Решения и компромиссы

- Хранилище в памяти: в задании не требовалась персистентность.
  В проде заменил бы на PostgreSQL, интерфейс репозитория уже выделен.
- Нет авторизации: вне рамок задания.
- Не успел: пагинация списка заказов. Сделал бы через cursor-based,
  чтобы не было пропусков при вставках.

Раздел про компромиссы — самый ценный. Он показывает, что вы видите систему шире задания и сознательно выбираете, что не делать. «Не успел, но сделал бы так» читается гораздо лучше, чем молчаливая дыра.

3. Решена ли основная задача

Звучит очевидно, но кандидаты регулярно тратят время на красивую архитектуру и не доделывают главный сценарий. Проверьте каждое требование из задания по списку. Если что-то сознательно не сделано, напишите об этом в README.

4. Тесты

Почти любой проверяющий посмотрит, есть ли тесты. Важно не покрытие в процентах, а то, что тесты проверяют:

• Основную бизнес-логику, а не геттеры.
• Крайние случаи: пустой ввод, граничные значения, ошибки.
• Хотя бы один интеграционный сценарий: запрос к API, полный путь через приложение.

Несколько осмысленных тестов лучше сотни сгенерированных. Если тесты на что-то не написаны, объясните почему: «UI проверял вручную, автотесты на компоненты не писал из-за ограничения по времени».

5. Структура и читаемость

Проверяющий хочет понять, как вы организуете код, который будут читать другие. Смотрят на:

• Разделение ответственности. Бизнес-логика отдельно от HTTP-слоя и хранилища. Это не значит «тащите чистую архитектуру с пятью слоями в задачу на 300 строк», это значит, что логику можно протестировать без поднятия сервера.
• Имена. Переменные и функции объясняют, что делают.
• Обработку ошибок. Нет проглоченных исключений и catch с пустым телом.
• Отсутствие мусора. Закомментированный код, отладочные print, пустые файлы из шаблона — уберите.

Переусложнение — такая же ошибка, как хаос. Фабрика фабрик в небольшом CRUD показывает не опыт, а неумение выбирать инструмент под задачу. Принципы вроде SOLID хороши, когда решают проблему, а не когда применяются ради галочки.

6. История коммитов

Многие проверяющие открывают git log. Один коммит «done» с тремя тысячами строк ничего не говорит о том, как вы работаете. Серия небольших коммитов показывает процесс:

$ git log --oneline
a3f9c21 Add README with run instructions and trade-offs
7d2e8b4 Handle validation errors in a single error format
c41a0f6 Add order cancellation with tests
9b7e3d2 Add order creation and listing endpoints
2f1c8a9 Add domain model and in-memory repository
e0d4b17 Set up project, linter and test runner

Не нужно искусственно дробить работу, но и squash всего в один коммит перед отправкой — плохая идея. Если хотите освежить команды, есть отдельная статья про git-команды.

7. Мелочи, которые замечают

• Секреты и токены в репозитории — серьёзный минус, даже тестовые.
• Пример конфигурации (.env.example) вместо реального .env.
• Работающий линтер и форматирование: код в одном стиле.
• .gitignore: в репозитории нет node_modules, __pycache__ и файлов IDE.

Как не утонуть

Самая частая история с тестовым: кандидат садится «на пару часов», а через три вечера всё ещё переписывает архитектуру. Несколько правил, которые помогают.

Сначала рабочий минимум

Сделайте самую простую версию, которая решает основную задачу и запускается. Закоммитьте её. Только потом улучшайте: тесты, обработка ошибок, рефакторинг, приятные мелочи. Если время закончится в любой момент, у вас будет что отправить.

Поставьте лимит времени

Решите заранее, сколько часов готовы потратить, и запишите. Когда лимит подходит к концу, останавливайтесь и переходите к README и проверке запуска. Незаконченные пункты — в раздел компромиссов.

Не учите новый стек ради тестового

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

Исключение — если стек жёстко задан и вы его не знаете. Тогда честно оцените, стоит ли позиция такой инвестиции, и скажите рекрутеру, что знакомы с технологией поверхностно.

Не полируйте бесконечно

Идеального решения не бывает. Проверяющий видит десятки работ, и разница между «хорошо» и «идеально» для него часто незаметна, а для вас это ещё два вечера. Тот же принцип работает и на очных секциях — о распределении времени есть статья про тайм-менеджмент на собеседовании.

Следите за собой

Если вы параллельно в нескольких процессах, тестовые быстро съедают все вечера и выходные. Это прямой путь к выгоранию от поиска работы. Лучше взять меньше заданий и сделать их нормально.

Про AI-ассистенты

Политика компаний здесь разная: где-то использование ассистентов разрешено, где-то нет, где-то об этом молчат. Если в задании ничего не сказано, уточните. И в любом случае исходите из того, что на следующем этапе вас попросят объяснить каждую строчку: код, который вы не понимаете, станет проблемой именно там.

Перед отправкой: чек-лист

• Проект запускается с чистого клона строго по README.
• Все обязательные требования выполнены или явно описаны как не сделанные.
• Тесты проходят одной командой.
• В README есть запуск, тесты, что сделано и компромиссы.
• Нет секретов, мусора и отладочного вывода.
• История коммитов читается.
• Репозиторий доступен проверяющему: проверьте ссылку из окна инкогнито или попросите подтвердить доступ.

В письме с решением хватит пары строк: ссылка, сколько примерно времени потратили, на что обратить внимание. Время указывать полезно: «сделал за 5 часов, не успел пагинацию» помогает проверяющему правильно оценить результат.

Обсуждение на следующем этапе

Во многих компаниях после тестового идёт встреча, где решение разбирают вместе с вами. Это не формальность: часто именно здесь принимается решение.

Что обычно спрашивают

• Почему так? Почему такая структура, такая библиотека, такой формат хранения.
• Что бы вы изменили? С большим временем, в продакшене, под нагрузкой.
• Как это масштабировать? Что сломается при росте данных или пользователей. Здесь пригодятся основы системного дизайна.
• Расширьте вживую. Добавить поле, новый эндпоинт, исправить баг, найденный проверяющим.
• Где слабые места? Лучше назвать их самому, чем ждать, пока найдут.

Как подготовиться

1. Перечитайте своё решение за день до встречи. За неделю детали забываются, и «почему я так сделал» становится настоящим вопросом.
2. Составьте список слабых мест и того, как бы вы их исправили.
3. Подготовьте окружение: проект открыт, запускается, тесты проходят. Если попросят что-то поменять вживую, не придётся пятнадцать минут вспоминать команды.
4. Продумайте пару сценариев расширения: если бы данных было в тысячу раз больше, если бы нужна была авторизация, если бы два пользователя меняли один объект одновременно.

Как вести разговор

Защищать решение не значит упрямо доказывать, что оно идеально. Хорошая позиция — «я выбрал так по таким причинам, вот альтернатива и её плюсы». Если проверяющий предлагает другой вариант и он действительно лучше, согласитесь и объясните, почему не увидели его сразу. Умение принимать замечания ценится не меньше, чем сам код.

Когда в процессе разговора вас просят что-то изменить, думайте вслух: проговаривайте, что собираетесь сделать и зачем. Как это делать без потери темпа, разобрано в статье про рассуждения вслух на интервью. Дополнительные вопросы проверяющего по сути похожи на follow-up вопросы после алгоритмической задачи: вас проверяют на глубину понимания, а не ловят на ошибках.

Если отказали после тестового

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

Если обратной связи нет, перечитайте решение сами через неделю свежим взглядом. Часто слабые места становятся видны сразу. О том, как не воспринимать отказ лично и извлечь из него пользу, есть отдельная статья про работу с отказами.

И сохраните решение. Хорошее тестовое — готовый проект для портфолио (если условия компании не запрещают его публиковать) и пример кода для следующих работодателей.

Итог

• Прежде чем браться, узнайте объём, сроки проверки и следующий этап.
• Оценивайте объём по шагам и с запасом; если он неадекватный — договаривайтесь.
• Проверяющий начинает с запуска по README: проект должен стартовать с чистого клона.
• Тесты на главное, понятная структура, осмысленные коммиты и честный раздел компромиссов отличают сильное решение.
• Сначала рабочий минимум, потом улучшения, и жёсткий лимит времени.
• К обсуждению готовьтесь как к отдельной секции: перечитайте код, назовите слабые места сами, продумайте расширения.