Как выполнить и отправить тестовое задание работодателю: инструкция для начинающего разработчика

Хорошее тестовое задание удобно проверить без переписки «а как это запустить?». Работодателю нужны понятный результат, воспроизводимый запуск и честное описание ограничений. Кандидату — ограниченная по объёму задача, на которой можно показать работу с требованиями, кодом и проверкой.

Ниже — авторская инструкция для начинающего разработчика. Примером будет условная утилита, которая читает CSV с расходами и выводит сумму по категориям. Это не задание конкретной компании и не универсальный стандарт найма: критерии реального отбора нужно выяснить у его организатора.

До начала оцените задачу и границы работы

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

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

Не считайте любое большое задание обманом, а любое короткое — качественным отбором. Уточните ожидаемые затраты времени и способ оценки. Если в ваши планы работа не помещается, сообщите об этом до обещания срока, а не после исчезновения из переписки.

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

В условной CSV-задаче известно: столбцы date, category, amount; группировка по category; результат — итог по каждой категории. Пока этого недостаточно для уверенной реализации. Нужны ответы о разделителе, десятичной записи, пустых строках и ошибочных значениях.

Пример короткого сообщения: «Правильно ли понимаю, что вход — CSV UTF-8 с запятой, amount записывается через точку, а отрицательные суммы допустимы как возвраты? Если встречается неверная сумма, ожидается ошибка всего файла или пропуск строки? Результат отправить приватным репозиторием со ссылкой на конкретную версию?»

Не задавайте вопрос о каждой мелочи, которую можно разумно решить самому. Сначала уточните развилки, меняющие поведение. Если ответа до начала работы нет, запишите допущение в README: «При неверной сумме обработка завершается с сообщением о номере строки». Такое решение становится явным и проверяемым.

Условие примера	Ожидаемый результат после согласования
Две строки «Еда»: 100.50 и 49.50	Одна итоговая категория с суммой 150.00
Пустой файл с корректной строкой заголовков	Пустой результат без выдуманных категорий
Значение amount равно abc	Понятная ошибка с местом проблемы
Одинаковая категория встречается не подряд	Группировка охватывает весь файл
Нет обязательного столбца	Сообщение о структуре входа вместо случайного исключения

Это авторские критерии для конкретной учебной утилиты. В реальном тестовом ожидаемое поведение берётся из условия и уточнений; например, отрицательные суммы нельзя поддерживать или запрещать только потому, что так сделал наш пример.

Распределите время между реализацией и сдачей

Авторский план для доступных трёх часов: первые 20 минут — требования и простой каркас, следующие 90 — рабочий основной сценарий, затем 40 — ошибки и проверки, последние 30 — чистый запуск, README и отправка. Это вариант личного планирования, не норматив длительности тестовых.

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

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

Упакуйте проект для другого человека

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

Авторская компактная структура нашей утилиты: README.md, исходный файл или пакет, tests, examples с маленькими синтетическими CSV и файл зависимостей, если они действительно нужны. Не создавайте пустые каталоги ради впечатления. Секреты, персональные данные и рабочие выгрузки в примеры не входят.

# Сводка расходов
Назначение: сумма amount по category из CSV.
Среда: укажите реально использованную версию Python.
Установка: укажите зависимости либо их отсутствие.
Запуск: приведите точную команду из корня проекта.
Пример: examples/expenses.csv и ожидаемый результат.
Проверка: команда запуска тестов.
Допущения: кодировка, разделитель, обработка ошибок.
Ограничения: что не реализовано и почему.

Этот шаблон требует заполнения, а не отправки слов «укажите версию». Команда должна совпадать с настоящими именами файлов и аргументами вашего решения. Скриншот удачного запуска полезен как дополнение, но не заменяет инструкцию.

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

Проверьте сдачу как получатель

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

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

Посмотрите diff и список файлов перед отправкой. Удалите временные выгрузки и проверьте отсутствие токенов. При этом полезные тесты и небольшой пример должны остаться. Комментарии объясняют неочевидное решение, а не пересказывают каждую строку кода.

Выберите формат и подтвердите доступ

Отправляйте тот формат, о котором договорились: репозиторий, архив или специальную форму. Для приватного репозитория проверьте предоставление доступа нужному получателю. Публичный вариант открывает код всем посетителям GitHub; не делайте условие компании публичным автоматически.

Ссылка должна вести на окончательную версию. Можно указать commit, если проверяющему так удобно. В архиве используйте понятное имя и не включайте установленное окружение, если его специально не запросили. После упаковки проверьте содержимое самого архива, а не только исходной папки.

Пример сопроводительного текста: «Отправляю решение CSV-задачи: ссылка. Запуск и проверки описаны в README. Реализованы группировка и сообщения об ошибках входа. Допущение: некорректная сумма останавливает обработку. Проверил на приложенных синтетических примерах; ограничение по очень большим файлам отдельно не исследовал».

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