Как составить резюме на позицию frontend-разработчика

Что просматривают в первую очередь

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

Это значит, что расплывчатые формулировки в резюме — «работал с современными JavaScript-фреймворками», «опыт по всему стеку» — читаются как тревожный знак, а не как резюме. Это может означать что угодно: от полугода прохождения курса до пяти лет поддержки production-приложения. Называйте фреймворки: React, Vue, Angular, Svelte. Укажите, был ли это TypeScript или JavaScript, а если TypeScript — писали ли вы типы или унаследовали слабо типизированную кодовую базу, которую кто-то другой построил. Если в вакансии написано «React + TypeScript + GraphQL», ваше резюме должно использовать эту точную комбинацию ближе к началу, а не её пересказ. И те, кто бегло просматривает, и любая автоматическая проверка по ключевым словам ищут слова из объявления, а не синонимы к ним.

Строка стека и почему глубина важнее широты

Большинство frontend-резюме перечисляют инструменты плоским, недифференцированным блоком: React, Redux, Webpack, Sass, Jest, Git. Это почти ничего не говорит читателю о глубине опыта. Лучше добавить контекст: какой инструмент сборки (Webpack, Vite, esbuild), какой подход к тестированию (Jest и React Testing Library для модульных тестов, Cypress или Playwright для end-to-end), какое управление состоянием вы реально использовали и почему (Redux Toolkit против Zustand против просто Context в зависимости от размера задачи), какой мета-фреймворк, если был (Next.js, Remix, Nuxt).

Строка вроде «перевёл legacy-кодовую базу с классовыми компонентами на React 18 с хуками, убрал последние использования componentWillMount» говорит больше, чем три года «React» в списке навыков. Она показывает, что вы работали внутри существующей системы, а не только запускали новые. Если вы занимались CSS на какой-то глубине, укажите какой подход — CSS Modules, styled-components, Tailwind, BEM-конвенции на чистом Sass — потому что это представляет действительно разные рабочие практики, и менеджер по найму в проекте на Tailwind прочитает «CSS» и всё равно не узнает, будете ли вы продуктивны с первого дня.

Как подтверждается опыт в этой области

Во frontend, в отличие от большинства других инженерных дисциплин, значительную часть вашей работы можно просто посмотреть. Это меняет, что означает «доказательство» в резюме. Ссылка на профиль GitHub с реальной историей коммитов, ссылка на живой развёрнутый сайт, который вы построили, ссылка на pull request, которым вы гордитесь, ссылка на библиотеку компонентов или Storybook-инстанс — это делает больше работы, чем пункт списка, утверждающий то же самое. Если вы внесли вклад в open-source проект, назовите его и дайте ссылки на смёрдженные PR, а не только на проект.

Где работа под NDA и вы не можете дать ссылку на код, опишите задачу и результат, а не придумывайте цифру, чтобы заполнить пробел. «Уменьшил размер бандла на потоке оформления заказа через route-based code splitting» — это реальное, проверяемое на собеседовании утверждение. Конкретный процент, за который вы не можете поручиться под допросом, наносит больше ущерба, чем расплывчатая версия, потому что это первое, что интервьюер начнёт проверять.

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

Квалификации и что здесь не служит барьером

Для frontend-разработки нет лицензии или профессиональной регистрации. Диплом по computer science помогает на этапе выпускных программ крупных работодателей, где он иногда используется как начальный фильтр, но это не барьер в том смысле, в каком свидетельство о допуске — в юриспруденции или PIN — в медицине: множество работающих старших frontend-разработчиков — самоучки или прошли через буткемп. Если это ваша история, назовите буткемп и когорту, но не начинайте с этого. Начните с того, что вы выкатили после. Сертификат открыл вам дверь первой работы; он не работает на вас спустя три работы.

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

Что frontend-кандидаты регулярно упускают

Несколько вещей отсутствуют снова и снова, даже в резюме, которые в остальном хорошо составлены:

• Работа над доступностью. Если вы делали что-то в направлении соответствия WCAG, ARIA-атрибутов, клавиатурной навигации или тестирования скринридерами, скажите об этом конкретно — «привёл поток оформления заказа к WCAG 2.1 AA», а не оставляйте это, потому что кажется, что это малая часть работы. Некоторые менеджеры по найму теперь спрашивают об этом напрямую и видимо удивляются, когда кандидат делал эту работу, но никогда не упоминал её.
• Конкретика производительности. «Улучшил производительность» — это предложение, которое ничего не говорит читателю. Если вы работали над Core Web Vitals — LCP, INP, CLS — или двигали оценку Lighthouse, назовите метрику. Вам не нужен придуманный процент; назвать, над какой метрикой вы работали и что сделали для её улучшения, достаточно, чтобы утверждение стало проверяемым.
• Как вы работали с дизайном. Frontend находится на стыке дизайна и разработки, и то, как этот переход реально работал — рабочий процесс от Figma к компоненту, построение или поддержка дизайн-системы, работа внутри или построение Storybook-инстанса — регулярно отсутствует в резюме, хотя это часто большая часть реальной повседневной работы.
• Кроссбраузерная и адаптивная работа. Принимается как должное, редко указывается, и иногда это реальная причина, по которой нанимают кандидата — команда, которая только что пережила болезненный Safari-специфичный баг, хочет знать, что вы имели дело с этим классом проблем раньше.
• Code review и CI/CD-практика. То, были ли вы частью культуры PR-ревью, регулярно работали в паре или поддерживали покрытие тестами кодовой базы, говорит что-то об инженерной зрелости помимо «писал код», и это часто разница между резюме, которое читается как junior, и тем, которое читается как готовое к большей ответственности, независимо от указанных лет опыта.

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

Откройте реальное объявление о вакансии рядом с вашим резюме. Подгоните строку стека к его точной формулировке. Добавьте три ссылки ближе к началу: ваш GitHub, живой развёрнутый проект и один конкретный pull request или библиотеку компонентов, на которую вы можете указать. Вырежьте всё, что читается как истинное для любого разработчика, а не истинное для вас на этом стеке. Если вы делали работу по доступности или производительности, назовите метрику или стандарт, а не прилагательное.

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