В этом длиииииинном посте расскажу, почему я делаю тестовые лучше большинства, а также дам советы, как проходить этот этап быстро и максимально эффективно. Тема достаточно большая, поэтому будет разбита на 3 части. Это первая и начну ее я, пожалуй, не с советов: "Делай так, спина болеть не будет", а с лирического вступления, которое, на самом деле, важнее, чем какие-либо пункты.

Задача-минимум — выполнить его и надеяться, что тебя пригласят на следующий этап.

Задача-максимум — сделать так, чтобы проверяющий подумал: "Интересно, интересно… Кто там? Андрей Шпилевский? Надо глянуть в LinkedIn, что за человек. Эй, Лёха! Смотри, какое тестовое один из кандидатов прислал…"

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

  - будет сам проводить техническое собеседование

  - будет вторым присутствующим специалистом на собеседовании

  - будет передавать интервьюеру фидбэк по твоему тестовому

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

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

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

Это было около двух лет назад (а пишу об этом я сейчас, что уже, на мой взгляд, о многом говорит). Я искал фронтенд-разработчиков в Ташкенте. Тестовое было достаточно простым: нужно было сделать небольшой проект, используя публичный API — swapi.dev (если кто не знает, там много эндпоинтов для получения информации о различных сущностях из вселенной Star Wars). По дизайну требований не было никаких. «Просто покажи, что можешь/хочешь» — основная идея тестового.

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

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

    1. Кто делал тестовое и как его зовут (за кодом стоял человек).

    2. Краткую информацию о нём.

    3. Почему он хочет работать в нашей компании.

И после этой презентации я с воодушевлением перешёл к поиску его профиля в LinkedIn, а уже только потом — к проверке кода. Это буквально был глоток свежего воздуха среди остальных, похожих друг на друга, обезличенных тестовых заданий. Код, в свою очередь, ничем примечательным, не отличался, однако я хотел провести встречу с ним больше, чем с другими кандидатами, и практически уже был готов взять его в команду. Да, звучит эмоционально. Но эмоции — это нормально для людей, и кандидату в данной ситуации нужно было вызвать их ровно так, как это делают маркетологи, блогеры, писатели и т. д.

К сожалению, дело до технического собеседования так и не дошло. Он успел согласиться на оффер другой компании до того, как я успел с ним пообщаться. Надеюсь, его забрал Lucasfilm⚔️.

Я, как лид, как человек, который много коммуницирует с бизнесом, имею понимание, зачем мы, программисты, пишем код. И подобный подход (можно ли это назвать «продуктовым»... хз, с натяжкой) к решению задач мне импонирует. Человек пишет код, а еще креативит и презентует себя и проект — всё! Срабатывает «эффект ореола», и этот человек становится ещё и интересным собеседником, и с хорошими софтами, и отличным мужем…

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

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

И этот подход/процесс далее я буду упоминать как «упаковка тестового».

Вроде банально, но почему-то мало кто это делает, хотя усилий для этого нужно совсем немного, а времени — ну маааксимум час.

• Доступность твоего решения. В этом случае техспециалист может даже не скачивать твой проект — он посмотрит, потыкает UI и заглянет в твой код на GitHub.

• Упрощение проверки. У проверяющего не возникнет нюансов с окружением: разные версии Node.js, Angular, зависимости и т. д. Есть люди, которые не смогут запустить проект в течение 5 минут и просто перейдут к следующему тестовому.

• Демонстрация твоих, пусть и базовых, навыков в CI/CD. Если говорить коротко — просто меньше барьеров.

Просто добавь мета-теги.

“Бред же?” — спросишь ты меня, уважаемый читатель.

Отвечу:

Если мы говорим про рынок найма в СНГ, то практически вся переписка с рекрутерами у меня была и остается в Telegram. И выполненное тестовое рекрутер, скорее всего, тоже отправит техническому специалисту не по почте, а через Telegram или другой мессенджер — не суть важно.

Важно то, что первый контакт будет таким:

А без мета тегов вот так:

Рекрутер вряд ли обратит на это внимание, но вот специалист — обязательно. И твои мета-теги скажут ему: "Он шарит за SEO. Он внимателен к деталям".

А среди прочих вкладок с тестовыми твоих конкурентов, среди бесчисленных дефолтных тайтлов и Angular-фавиконов будет это:

Кстати, поменяй favicon, просто, для полноты картины.

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

Теперь самое интересное — презентуем себя и свою работу. Что должно быть в этой презентации:

• Имя и фамилия. Пусть проверяющий привыкает к фамилии будущего сотрудника.

• Фото. Можно добавить, если оно хорошего качества, нейтральное и вписывается в UI. Если тебе не 50 лет (эйджизм), то фото поможет создать ассоциацию с хорошей работой. На собеседовании техспециалист увидит тебя не в первый раз, а впечатление уже будет положительным.

• Ссылки (информация о вас, контакты). Указываем ссылки на LinkedIn, Telegram, GitHub, почту и, главное, на твое CV. Но важно не пихать все подряд. Например, если LinkedIn не оформлен должным образом — лучше не добавлять (но лучше его дооформить).

• Название компании. Просто показываем индивидуальный подход.

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

• Даты и сроки тестового. Указываем дату постановки задачи (когда рекрутер скинул тестовое), сроки выполнения и дату сдачи.

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

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

• Ссылка на репозиторий. Если надо объяснять, то не надо объяснять.

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

При этом и на главной странице, и на странице описания должна быть кнопка “Перейти к решению”.

• Сделай один стартовый проект для всех будущих тестовых. Это ускорит их выполнение, так как там уже будут настроены Prettier, ESLint, NgRx и другие вещи. Можно дополнять его на постоянной основе, и каждое следующее тестовое будет лучше предыдущего.

• Храним тестовые в GitHub + в задеплоенном виде. Если попросят выполнить тестовое, которое ты уже делал — предложи скинуть готовый вариант. Соглашаются 50/50, но если соглашаются — это супер. Во первых - ты экономишь время. Во вторых - быстро переходишь к следующему этапу.

• Когда накопилось 10+ образцовых тестовых, можно просто перестать их делать. У меня в планах сделать один сайт с собранными тестовыми и отправлять его рекрутерам вместо выполнения нового. Не все согласятся, но мне все и нужны. Данный подход подойдет тем, кто не страдает недостатком предложений и в этом случае цель просто сэкономить время.

Хорошо сделанное тестовое — это 100% от того, что от тебя ожидают. Если ты “упакуешь” плохо решенное тестовое, это чуть поможет, но не сильно. Однако хорошее тестовое + “упаковка” — это уже 105, 110, а может и 150 процентов (хотя посчитать точно невозможно — всё индивидуально).

✅ “Упаковка” тестового повышает шансы.

✅ Готовый стартовый проект экономит тебе время.