Тестовое задание в IT: как выполнить его хорошо

Коротко: что от вас ждут

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

1. Прочитайте требования дважды

• Выделите обязательные требования и желательные («будет плюсом»).
• Отметьте ограничения: язык, фреймворк, формат сдачи, срок.
• Если что-то неясно — задайте вопрос. Это не слабость, а нормальная рабочая практика. Если ответа нет, выберите разумное допущение и запишите его в README.

2. Ограничьте время

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

1. Минимальная рабочая версия всех обязательных требований.
2. Тесты на ключевую логику.
3. README.
4. Улучшения и «плюсы» — только если осталось время.

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

3. Сигналы качества кода

Проверяющий за несколько минут формирует впечатление. Помогают:

• Понятная структура проекта и осмысленные имена.
• Разделение ответственности: бизнес-логика отдельно от ввода-вывода и фреймворка.
• Обработка ошибок и валидация входных данных.
• Тесты на основные сценарии и граничные случаи.
• Аккуратная история Git: небольшие коммиты с понятными сообщениями.
• Единый стиль: линтер и форматтер, без закомментированного кода и отладочных выводов.
• Без лишнего: не тащите тяжелые зависимости и сложную архитектуру ради маленькой задачи.
• Без секретов в репозитории: ключи и пароли — через переменные окружения и пример файла .env.example.

4. README и коммуникация

README — это ваш голос, когда вас нет рядом. Минимальный набор:

# Название проекта

## Как запустить
Команды для установки и запуска, требования к окружению.

## Как запустить тесты
Одна команда.

## Решения и допущения
Почему выбран такой подход, что допущено при неясных требованиях.

## Что бы улучшил
Что не успел и как бы сделал при большем времени.

Проверьте, что проект запускается с нуля по вашей инструкции — например, в чистой папке после клонирования. Отправляя результат, напишите короткое сопроводительное письмо: что сделано, сколько времени заняло, где посмотреть.

5. Когда тестовое разумно не делать

Отказаться — нормально, если:

• задание явно больше разумного объема и требует многих дней работы без оплаты;
• оно похоже на реальную задачу компании, которую потом могут использовать без вас;
• требований нет, а на вопросы не отвечают;
• у вас уже есть открытый код, решающий похожую задачу, — можно предложить его вместо тестового;
• компания не готова давать обратную связь даже на большое задание.

Отказывайтесь вежливо и с альтернативой: предложите показать портфолио, разобрать ваш код на созвоне или выполнить сокращенную версию.

Частые ошибки

• Не прочитать требования и сделать не то.
• Потратить все время на «плюсы», не доделав обязательное.
• Сдать проект, который не запускается по инструкции.
• Отправить без README и без единого теста.
• Молча просрочить срок вместо того, чтобы заранее предупредить.