Тестовое задание 🧪

Тестовое задание (англ. test assignment) — это задача, которая проверяет ваши практические навыки после отклика на предложение о работе. Обычно с тестовыми заданиями сталкиваются разработчики, дизайнеры, QA-специалисты, аналитики, проджект- и контент-менеджеры, а также маркетологи.

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

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

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

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

Сложные тестовые задания закрепляют ваши навыки, а ещё, в каких-то случаях, учат чему-то новому и полезному. Бывают интересные задания, которые не стыдно показать другим. Можете добавить их в ваше портфолио.

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

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

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

В каких-то компаниях тестовые могут проверять и автоматически. К примеру, у Revolut есть платформа, на которой кандидаты решают несколько алгоритмических задач, и их решение проверяется автоматически.

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

Дальше сконцентрируемся на тестовых для разработчиков.

Тестовые задания бывают разными по объёму, форме и наполнению.

Какие навыки проверяют:

• Комплекс навыков. Например, только то, насколько хорошо вы знакомы с алгоритмами, или навыки вёрстки и написания скриптов.
• Ограниченное количество навыков. Например, умение настраивать CI/CD (Continuous Integration и Continuous Delivery/Deployment).

По продолжительности и объёму:

• Одно короткое задание, которое проверяет комплекс навыков.
• Набор задач с ограниченным временем выполнения.
• Большое задание на несколько часов, которое проверяет один или несколько навыков.

По форме тестовые могут быть абсолютно разными. Вас могут попросить исправить ошибку в готовом коде или написать его с нуля, сверстать целую страницу или отдельный элемент, решить алгоритмическую задачу, написать тесты для готового элемента, настроить сборку проекта и даже написать эссе. Может быть несколько вариантов эссе, например: «Почему я так люблю Rust» или «Как выглядит ваш фреймворк мечты». Это обычно суровое техническое эссе с диаграмками и всякими примерами кода.

Полина Гуртовая

Старайтесь, чтобы выполненное тестовое задание выглядело как настоящий проект. Это оставит о вас хорошее впечатление у того, кто его проверяет.

Внимательно прочитайте текст задания и условия его выполнения. Если что-то непонятно, уточните это сразу же. Не тяните до последнего. Также обратите внимание на то, в каком формате ждут тестовое и как его нужно отправить. Обычно выполненные задания для разработчиков лучше выкладывать на GitHub, но некоторые работодатели могу попросить прислать архив по почте или залить его на облачный сервис.

Теперь перейдём к тому, как выполнять тестовые.

Во время выполнения задания можете пользоваться любыми справочниками, документацией, форумами, GitHub Copilot и ChatGPT, но старайтесь не копировать бездумно готовые решения. Внимательно читайте любые примеры кода, прежде чем решить использовать их у себя в проекте. Вас могут спросить, почему приняли такое решение, и тут легко попасть в неловкую ситуацию, если не знаете, почему написали такой код 😅

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

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

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

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

Опишите проект в README.md. Это лицо вашего тестового. В файле опишите следующее:

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

Постарайтесь, чтобы проект было можно запустить одной командой. Можете добавить нужные скрипты в package.json, создать мейкфайл (англ. makefile) или даже использовать несколько Docker-контейнеров для локальной разработки. В этом случае используйте docker-compose или другую удобную систему.

В package.json, кроме скриптов для запуска проекта, хорошо указать ещё:

• автора;
• версию проекта, может быть вечной 0.1.0;
• лицензию;
• ссылку на GitHub;
• правильное значение в поле private — true означает, что это закрытый репозиторий. По умолчанию все репозитории открытые.

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

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

Перед отправкой тестового проверьте всё внимательно. Спросите себя — достигнута ли поставленная цель? Нажимаются ли кнопки, правильные ли ссылки? Работает ли регистрация? Сохраняются ли данные?

Всё хорошо? Тогда напишите сообщение человеку, который ожидает тестовое, приложите ссылку или файл к сообщению или письму, и жмите кнопку отправить!

• Сверстать посадочную страницу.
• Сверстать модальное окно.
• Реализовать JavaScript-функцию, которая делает запрос и выводит данные в виде таблицы.
• Cоздать список дел на React.
• Создать приложение для управления иерархией вложенных страниц с React, Next.js и TypeScript.

Репозитории по хештегу test-assignment.