Нужно ли фронтенд-разработчику сопроводительное письмо?

Честная отправная точка

Большинство откликов фронтенд-разработчиков проходят через системы отслеживания кандидатов — Greenhouse, Lever, Ashby, Workday — прежде чем их увидит человек. Во многих из этих систем поле для сопроводительного письма необязательно, и где оно необязательно, рекрутер, делающий первый просмотр сорока откликов на одну вакансию, читает резюме и ссылку на GitHub, а не письмо. Если вы откликнулись в крупную технологическую компанию и не получили ответа, письмо редко является причиной. Резюме не совпало с ключевыми словами, которые искал рекрутер или фильтр ATS, или у вакансии был внутренний кандидат, или позиция никогда по-настоящему не была открыта. Это не повод писать плохое письмо. Это повод не тратить на него три часа в надежде, что оно компенсирует резюме, которое не показывает стек в первой трети страницы.

Письмо действительно читают в более узких и специфичных случаях: стартапы и небольшие продуктовые команды, где руководитель по найму — часто технический лидер или старший разработчик, а не рекрутер — читает каждый отклик сам, потому что их двадцать, а не две тысячи. Рекомендательные каналы, когда кто-то пересылает ваш отклик напрямую команде. И поздние этапы отбора, когда вас осталось трое финалистов и кто-то читает всё, что вы отправили, потому что пытается выбрать между вами и кем-то ещё с похожим резюме. В таких ситуациях письмо действительно может повлиять на решение. При первичном отборе по ключевым словам в крупной компании оно обычно не может.

Что конкретно должно делать письмо

Уберите общие фразы — «Я увлечённый фронтенд-разработчик с вниманием к деталям» верно для каждого кандидата и ни на что не отвечает — и сопроводительное письмо фронтенд-разработчика действительно должно делать только две вещи.

Объяснить, почему именно этот продукт, а не просто этот стек. «Я пользовался приложением [компании], и то, что заставило меня откликнуться, это X» — это другое предложение, чем «Мне интересно работать с React». В каждом объявлении о вакансии фронтенд-разработчика упоминается фреймворк. Почти ни одно из них не получает письма, в котором упоминается что-то конкретное о самом интерфейсе — функция, которую вы заметили, элемент UX, который вы бы сделали иначе, проблема производительности, с которой вы столкнулись на их сайте, паттерн компонента, который вы узнали из их дизайн-системы, если она публична. Если вы не можете сказать ничего конкретного о продукте, стоит это заметить до того, как вы пишете письмо, а не после.

Показать, что вы можете владеть чем-то, а не только писать компоненты. Выше определённого уровня руководителя по найму не волнует, знаете ли вы JSX. Его волнует, можете ли вы провести функцию от файла в Figma до продакшена без того, чтобы кто-то вас вёл за руку — работали ли вы напрямую с дизайнерами и бэкенд-разработчиками, принимали решение об управлении состоянием или стратегии рендеринга, разбирались с проблемой совместимости браузеров или улучшали что-то измеримое, например Lighthouse score, размер бандла или Core Web Vitals. Один конкретный пример лучше списка прилагательных. «Переписал валидацию формы в checkout flow, что сократило одну категорию обращений в поддержку почти до нуля» говорит им больше, чем «сильные навыки решения проблем».

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

Что на самом деле игнорируется, и почему это всё ещё пишут

Несколько вещей постоянно встречаются в письмах фронтенд-разработчиков и редко помогают:

«Я увлечён чистым кодом и лучшими практиками» — каждый разработчик говорит это, и это невозможно проверить, поэтому это не имеет веса для руководителя по найму, сравнивающего кандидатов. Если вы хотите донести ту же мысль, назовите что-то конкретное: настройку линтинга или тестирования, которую вы внедрили, библиотеку компонентов, которую помогли стандартизировать, миграцию, которую возглавили (классовые компоненты на хуки, Redux на более лёгкую библиотеку состояний, JavaScript на TypeScript). Конкретика — единственное, что отделяет реальное утверждение от шаблона.

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

Общие похвалы компании — «Я всегда восхищался вашей инновационной культурой» — читаются как заполнитель, потому что были бы верны для любой компании, которую вы подставите в предложение. Если у вас нет чего-то конкретного, что можно сказать об их продукте, инженерном блоге, опенсорсной работе или дизайн-системе, часто лучше сказать меньше, чем писать абзац, который подошёл бы любому работодателю в секторе.

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

Где портфолио или GitHub делают работу письма лучше

Фронтенд — одна из немногих инженерных дисциплин, где вы обычно можете показать, а не рассказать — развёрнутый проект, профиль GitHub с реальной историей коммитов, CodePen, личный сайт, который сам по себе демонстрирует вашу работу с CSS и интерактивностью. Если у вас есть что-то из этого, задача письма меняется: ему не нужно убеждать читателя, что вы можете создавать вещи, потому что они могут пойти и посмотреть. Ему нужно указать им на правильную вещь и сказать, почему она релевантна. «Дашборд, на который дана ссылка ниже, использует тот же подход к графикам, который вам нужен для представления аналитики, упомянутого в объявлении» работает больше, чем три предложения о ваших навыках.

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

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

Что делать дальше

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

Если реальный блокировщик не в письме — если вы отправляете сильные отклики на вакансии, которые соответствуют вашему стеку и опыту, и всё равно ничего не слышите — более полезная диагностика обычно в резюме и соответствии между вашим опытом и тем, что конкретно просит объявление, поскольку именно на это фильтры ATS и первичное чтение рекрутеров на самом деле отсеивают. jobmarket.pro читает каждое объявление о вакансии полностью, говорит вам, где ваш опыт подходит, а где нет, и строит отклик из единого профиля, в который не может изобрести опыт, поэтому письмо и резюме согласованы с тем, что руководитель по найму действительно будет проверять.