Тестовое задание: как сделать, сдать и защитить

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

1. 1

   Получение задания

   Рекрутер присылает текст или ссылку на репозиторий, называет срок и формат сдачи.

2. 2

   Уточнение условий

   Вы задаёте вопросы по неясным местам и договариваетесь о сроке, если он не подходит.

3. 3

   Работа

   Делаете минимальную рабочую версию, потом улучшаете. Коммитите по шагам, а не одним куском.

4. 4

   Сдача

   Отправляете ссылку на репозиторий с README. Коротко пишете, что сделано и что нет.

5. 5

   Проверка

   Инженеры смотрят код по своему чек-листу. Обычно это занимает от пары дней до недели.

6. 6

   Защита

   На отдельном звонке вас просят объяснить решения, иногда доработать что-то при них. Подробнее в разделе лайвкодинг.

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

Хорошее тестовое делается за вечер или выходной. Если по ощущениям нужно больше двух полных дней, это повод обсудить объём. Время, которое вы тратите, никто не видит. Видят результат и то, как вы о нём рассказываете.

Поставьте себе лимит и следите за ним. Лучше сдать аккуратные 80% с честным списком «что бы я доделал», чем все 100% с кашей в коде.

Вопросы до старта показывают зрелость. Задавайте их одним письмом, а не по одному в день. Если ответа нет, сами примите решение и запишите его в README.

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

У проверяющих почти всегда есть чек-лист. Он похож от компании к компании. Вот что в нём обычно стоит и как это выглядит хорошо и плохо.

Сложная архитектура «на вырост» обычно не плюс. Проверяющие ищут простое решение, которое легко менять. Лишние слои и паттерны ради паттернов читаются как неумение выбирать.

README это ваш голос, когда вас нет рядом. Многие проверяющие начинают с него и по нему решают, насколько внимательно читать код.

1. Как запустить: команды установки, запуска и тестов
2. Что сделано: список функций по пунктам задания
3. Решения: почему выбрали этот подход и библиотеки
4. Компромиссы: что упростили и почему
5. Что бы доделал: 3-5 пунктов при наличии времени

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

История коммитов тоже читается. Маленькие осмысленные коммиты показывают, как вы работаете в команде. Освежите основы в уроке Git.

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

• Предложите показать свой проект на GitHub вместо задания
• Попросите сократить объём до ключевой части
• Предложите лайвкодинг на час вместо недели работы
• Для большого задания спросите про оплату

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

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

• Merge или rebase: что выбратьИнструменты
• Самый интересный проектО себе и поведенческое
• Чем rebase отличается от mergeИнструменты
• Самая сложная техническая задачаО себе и поведенческое
• Когда нельзя делать rebaseИнструменты
• Результат проектаО себе и поведенческое
• Как отменить коммит в общей веткеИнструменты
• Порядок рассказа о проектеО себе и поведенческое
• Чем отменить измененияИнструменты
• «Мы» или «я»О себе и поведенческое
• Обновить ветку через rebaseИнструменты
• Расскажите о своём пет-проектеО себе и поведенческое

• Начать без уточнений и сделать не то, что просили
• Тратить неделю на задание, которое рассчитано на вечер
• Сдать без README и инструкции запуска
• Оставить закомментированный код, console.log и TODO без объяснений
• Один коммит на всё решение
• Усложнить архитектуру слоями «как в большом проекте»
• Не перечитать свой код перед защитой
• Молча не сдать и пропасть вместо честного отказа

• Задал уточняющие вопросы одним письмом
• Определил лимит времени и что отрежу при нехватке
• Сделал рабочую версию, потом улучшил
• Написал тесты на ключевую логику и краевые случаи
• Обработал пустые данные и ошибки
• Убрал отладочный и мёртвый код
• Написал README: запуск, решения, компромиссы, что доделать
• Проверил запуск с нуля на чистой копии репозитория
• Перечитал код за день до защиты
• Подготовил ответы на «почему так» и «что бы изменил»

• Уроки треков роли закрывают пробелы, которые всплывают в тестовом: тесты, Git, структура кода
• Задачи с автопроверкой приучают писать код, который проходит скрытые краевые случаи
• Устные вопросы с чек-листом тезисов тренируют защиту: «почему так», «что изменить»
• Лестница стресса: шаг «Вслух» записывает голос на устройстве, слышно, где вы путаетесь в объяснении
• Живой мок по ссылке: друг задаёт вопросы по вашему решению, как на защите
• Трекер собесов: отмечайте этап тестового, а после защиты заполните анкету, слабые темы уйдут в план повторений