Тестовые задания в IT: давать или не давать, вот в чем вопрос

Наём IT-специалистов, как правило, включает в себя несколько этапов, среди которых часто бывают тестовые задания. В этой статье мы поговорим о том, кандидатам каких профилей стоит давать тестовые задания, какие они должны быть, а кому давать их бесполезно или даже вредно.

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

Примеры:

- Опишите форму регистрации на сайте: какие шаги должен пройти пользователь, какие поля заполнить, какие требования к этим полям, какие должны показываться диалоги, какие должны исполняться сценарии и т.п.

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

Оформление: от менеджера ожидают презентацию с изображениями/скриншотами/набросками и, самое главное, с хорошим описанием алгоритма, с хорошо проработанным представлением о показателях конверсии и целевых метриках.

Время на выполнение: обычно задание занимает 1–2 вечера (3–4 часа в совокупности), не больше. С учетом того, что кандидаты, как правило, работают, сроки ставят на неделю (однако бывают и исключения).

Защита: после выполнения кандидат защищает тестовое задание, в том числе отвечает на вопросы, которых не было в задании изначально. Благодаря этим вопросам становится понятно, сам кандидат его делал или нет. Проверять самостоятельность выполнения можно также через «почему»: почему ты выбрал именно такое решение, почему ты показал вариант А, а не вариант В, какой может быть вариант В (если кандидат не пытается рассуждать на эту тему, то, вероятнее всего, он получит отказ).

Пример: обычно дают задание спроектировать архитектуру для высоконагруженного сервиса (приложение с бэком, бэк для обработки данных без фронта, распределенная база данных, система хранения файлов), обязательно озвучивают требования. Такое задание хорошо давать, т.к. сразу можно проверить, что команда «на одной волне» с кандидатом в плане технологического стека, и что кандидат не предлагает решения, которые не соответствуют нормам бизнеса или конкретного проекта.

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

Время на выполнение: обычно задание занимает 2–3 часа, иногда его дают в режиме реального времени (например, на секции по архитектуре).

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

Вместо тестового задания: можно попросить показать из портфолио то, что делал разработчик, на одном из этапов собеседований, потому что давать тестовое задание в формате «сделать приложение» некорректно (оно слишком объемное, а если попросить сделать часть, то получить полную информацию о том, насколько компетентен специалист, не выйдет).

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

Live-кодинг: во многих компаниях эта секция – обязательная, и на ней, как правило, дают базовые алгоритмические задачи (например, удаление повторяющихся пробелов в строке, замена смайликов на юникод-смайлики, сжатие массива и т.п.). Такая секция занимает около часа или чуть больше, и по ее итогам в совокупности с изучение портфолио кандидата можно дать оценку его квалификации.

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

Кроме того, как правило, фронтенд-разработчик приступает к интерфейсу после проработки дизайна, а в случае тестового задания неочевидно, где он этот дизайн возьмёт.

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

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

Live-кодинг: очень редко проводят, но как правило, на секции дают задачи на базовые алгоритмы, но менее сложные, чем у mobile- и backend-разработчиков. Это связано с тем, что frontend-разработчики часто пользуются фреймворками, а вот сложными алгоритмами – не так часто. Этот этап нужен, чтобы проверить, как кандидат думает и рассуждает.

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

Live-кодинг: из-за того, что в случае с backend-разработчиками тестовые задания практически неприменимы, проводят 1–2 сложных этапа с кодом. Для разработчиков высокого уровня иногда дополнительно проводят теоретическую секцию с архитектурой – на ней дают что-то похожее на задание, которое делает DevOps, но с уклоном в разработку (акцент на общие компоненты, сервисы, алгоритмы, связи между ними). Пример задачи: спроектировать базу данных запчастей для автомобилей и API для поиска детали в этой базе данных.

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

Оформление: от кандидата будут ждать описание, что он будет тестировать автоматически, что – руками, попросят описать сценарии тестирования и ожидаемое поведение.

Время на выполнение: обычно задание занимает 2–3 часа.

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

Live-кодинг: для автоматизаторов может быть дополнительная секция с Python и/или JS, если кандидат заявляет, что использует их в работе, и/или если вакансия предполагает их использование.

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

Этапы собеседований: как правило, проводят этап с менеджером продукта, секцию по юзабилити и пользовательскому опыту, задают вопросы по портфолио, проверяют софт-скиллы и мэтч с командой.