Домашка для фронтендера: испытание или издевательство?

Домашние задания – теперь это не только про школу. Если вы frontend-разработчик в поиске работы, будьте готовы: скорее всего, вас попросят сделать тестовое задание на дому. Для одних кандидатов это шанс блеснуть навыками, для других – ненавистный этап отбора.

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

Представьте типичную ситуацию: вы откликнулись на вакансию фронтендера, прошли первичный отбор резюме, и вдруг вам прилетает внушительное задание – например, за несколько дней создать полноценное SPA-приложение с нуля, да еще и учесть все нюансы вёрстки, API и браузерной совместимости. Кажется, неплохой способ проверить себя? Возможно. Но что, если такое задание получают десятки кандидатов, а шансы на оффер призрачно малы?

Один разработчик поделился шоком от современного найма: «долго, муторно, бессмысленно» – так он описывает свой опыт поиска работы фронтенд-разработчиком. В ИТ-сфере тестовое задание нередко превращается в мини-проект, отнимающий уйму времени. Кандидаты жалуются, что иногда чувствуют себя участниками какого-то марафона бесплатного труда, результат которого даже не гарантирует обратной связи, не говоря уже о трудоустройстве (источник habr.com).

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

Почему же компании до сих пор раздают домашние задания, словно это обязательный этап любого собеседования? Работодатели объясняют: резюме и портфолио – вещь хорошая, но хочется увидеть навыки в деле. Бывает, что блестящее портфолио – не более чем результат работы команды, а реальных скиллов там кот наплакал (источник spectrumdata.ru). «Тестовое задание позволяет оценить кандидата даже с большим портфолио», – отмечает один руководитель (источник t-j.ru).

Действительно, за красивыми примерами кода на GitHub может скрываться вклад другого человека или упрощенный учебный проект. А тестовая задача ставит всех в равные условия и показывает, как разработчик решает новую для него проблему здесь и сейчас. К тому же, для новичков выполнение тестового – шанс пополнить портфолио реальным проектом и получить ценный фидбэк от опытных коллег. Многие джуны именно через такие задачи набивают руку и даже если не получают работу, то оставляют себе в актив выполненное приложение.

Однако оборотная сторона у тестовых заданий весьма ощутимая. Во-первых, далеко не всегда затраченное время себя оправдывает. Часто кандидат тратит на задачу дни, а то и недели, а взамен – тишина. Классика жанра: «Работодатель ушёл в игнор, тестовое выполнил, но никто ничего не прислал». По сути, компания просто перестает выходить на связь после получения результата. Комментарий одного разработчика на форуме красноречив: «Самое плохое – выполненное тестовое без обратной связи.

Вы потратили своё время… а работодатель просто сливается». Во-вторых, объем «домашки» порой совершенно неадекватен. В сообществе негласно считается, что проверять навыки можно задачей на 4–8 часов работы, но никак не на несколько дней. «Тестовое задание объемом более дня выполнять невыгодно», – еще в 2014 году предупреждал автор на Хабре. Его доводы понятны: такие марафоны не гарантируют оправдания потраченного времени, требуют непропорционально больших усилий и часто сопряжены с банальной невежливостью – вам могут даже не сообщить результат.

Отдельная тема – недобросовестные работодатели. Случается, за красивым формулировкой тестового скрывается попытка получить от соискателей бесплатную работу на свой продукт. Например, компания просит разработать модуль для своего реального веб-сервиса под видом проверки навыков. Или дает задание настолько сложное и близкое к боевым задачам, что возникает вопрос – а не хотят ли они решить свои проблемы чужими силами? Эксперты советуют насторожиться, если тестовое чересчур объемное и напрямую связано с основным продуктом компании (источник vc.ru).

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

Конечно, сами кандидаты не остаются в стороне от проблемы. В сети полно историй отчаяния: когда у тебя на руках сразу пять-шесть тестовых заданий от разных компаний – хоть разорвись. «Делать одно, но качественно – шанс 50/50, что труд не уйдет в пустоту. Делать все подряд вполсилы – тоже 50/50. А ведь цель – найти работу, а не выполнить все тестовые», – пишет один из соискателей.

Люди сравнивают эту ситуацию с абсурдными примерами из жизни. Мол, представьте, что при найме плиточника вы попросите его бесплатно выложить вам ванную «для проверки навыков», или придя в ресторан – требуете у шеф-повара приготовить пробное блюдо, которое вы не оплатите, если не понравится. Звучит нелепо, но именно так и выглядит поток объемных неоплачиваемых тестовых заданий. Один разработчик сравнил это с онлайн-знакомствами: «Ты пишешь девушке, а она сразу кидает реквизиты карты: сначала заплати, а потом, может, с тобой схожу» – примерно такую же эмоцию испытывают кандидаты, получая огромную «домашку» от компании без гарантий.

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

Действительно, испытательный срок никто не отменял: компании могут расстаться с новичком, если он не подходит, так зачем предварительные бесплатные проверки? Более того, есть мнение, что сама необходимость тестового – маркер некомпетентности интервьюера. «Для меня просьба сделать задание – плохой знак: значит, интервьюер не умеет оценивать кандидата вживую», – отмечает другой специалист. Вместо этого он предлагает решать мини-задачи прямо на собеседовании или разбирать конкретные кейсы устно – это экономит время всем.

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

Во-первых, минимизировать объём. Золотое правило: тестовое задание для фронтендера должно укладываться в несколько часов активной работы, максимум в один выходной день. В сообществе разработчиков выработались ориентиры: на алгоритмическую задачу – до 2 часов, на небольшое задание по конкретному фреймворку – до 8 часов (источник dou.ua).

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

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

Если важен опыт интеграции с API – поручите написать скрипт, который получает данные с условного REST-сервиса и отображает список. Главное – задание должно быть приближено к реальным задачам, но без избыточных деталей. Хорошая тестовая задача – как пристрелочный выстрел: небольшая, но точно отражающая повседневную работу.

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

Куда лучше предоставить четкое ТЗ: описать функциональность, обозначить входные данные или макет дизайна, ожидания по результату. Исследования показывают, что многие плохие задания грешат именно отсутствием конкретики: требования умещаются в пару строчек (источник smyachenkov.com). Хорошее же задание содержит подробное описание целей, возможно, скетчи интерфейса или примеры API-ответов – словом, все, что позволит кандидату сосредоточиться на решении, а не на догадках. Например, если нужен фронтенд для работы с REST API, дайте спецификацию этого API; если проверяете знание React – можно даже предоставить заготовку проекта с настроенным build-скриптом, чтобы не тратить время на конфигурацию Webpack.

Минимум шаблонной работы. Представьте, кандидат получает задание “сделать SPA-приложение” – и первый час-два уходит просто на то, чтобы настроить среду, выбрать шаблон, подключить библиотеки. Это рутинные шаги, которые никак не проверяют интеллектуальные способности, зато съедают время. Поэтому эксперты советуют по возможности дать кандидату стартовый шаблон или скелет проекта.

Например, если нужен интерфейс для заметок – можно заранее сгенерировать приложение на Create React App или Vite, и вписать задание: «реализовать такие-то компоненты, такой-то функционал». Тогда претендент покажет умение писать конкретный код, а не конфигурировать сборщик. В тестовых ценится сфокусированность: проверяем знание конкретного фреймворка или умение верстать адаптивный дизайн – значит, остальное должно быть уже разрулено, чтобы не размазывать задачу на десятки файлов boilerplate-кода.

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

С другой – чрезмерные ограничения превращают тестовое в академическое упражнение. Если в боевой работе вы все равно используете, скажем, Redux или Axios, нет большого смысла запрещать их в тестовом. И уж точно не стоит придираться к тому, какую версию библиотеки взял кандидат – были случаи, когда отзыв звучал абсурдно: «использовал устаревшую версию, вышедшую месяц назад». Помните, цель – увидеть умение думать и кодить, а не проверить экстрасенсорные способности по угадыванию ваших скрытых предпочтений в техстеке.

Дайте достаточно времени и гибкий дедлайн. Хорошее тестовое задание – короткое по объему, но не обязательно по сроку сдачи. Кандидату может понадобиться распределить эти 4–8 часов на несколько вечеров после работы. Поэтому адекватный срок исполнения – несколько дней или даже неделя.

Наниматель, который просит “сделать к завтра до утра”, показывает непонимание: у людей есть текущие дела, да и вообще-то они не обязаны мгновенно бросаться выполнять незапланированную работу. Более того, слишком спешный дедлайн – один из признаков сомнительного работодателя, как мы уже отмечали. Гораздо лучше предоставить разумный запас времени и оговорить возможность попросить об отсрочке, если есть уважительная причина. Такой подход покажет уважение к человеку и его времени – поверьте, это заметят.

Не злоупотребляйте тестовыми на ранних этапах. В практике некоторых компаний встречается массовая рассылка тестовых заданий всем откликнувшимся – еще до какого-либо общения. Это делается ради экономии времени HR: мол, пусть сперва все желающие решат задачку, а мы уже из них отберем, с кем говорить. Для кандидатского опыта такой метод губителен. Получить в ответ на отклик сразу ссылку на задачник, не обменявшись ни словом с живым человеком – неприятно.

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

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

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

Скажем, просят реализовать фрагмент из уже существующего кейса компании, а затем обязательно показывают, как эту задачу решили внутри команды. В таком случае даже без оффера кандидат что-то узнает нового и прокачается. В любом случае, если вы не готовы никак компенсировать усилия, то хотя бы скажите спасибо и дайте обратную связь. Абсолютный минимум – сообщить результат, а лучше кратко указать, где были ошибки и чего не хватило. Это по-человечески правильно и к тому же улучшает имидж компании на рынке. Ведь среди разработчиков сарафанное радио работает отлично: одного «кинете» без ответа – десять других узнают об этом на профильном форуме.

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

Некоторые компании вообще не дают тестовые сильным разработчикам, ограничиваясь разбором кода из их GitHub и парой задач на собеседовании. Серьезный специалист может счесть унизительным необходимость тратить вечер на типовой «todo-list на React», когда у него за плечами сложные проекты. И правда, если человек разрабатывал, к примеру, администрируемые панели с ролевым доступом и сложной бизнес-логикой, проверить его знание можно более точечно – обсудив архитектурные решения, попросив набросать псевдокод решения конкретной проблемы, наконец, созвонившись для пары live-coding задач. Хороший техник-лид всегда найдет способ оценить уровень коллеги без бесполезной волокиты. А тестовое – это инструмент, который нужно применять там, где он действительно информативен.

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

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

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