Как написать вакансию, которая привлечёт сильных IT-специалистов
Большинство компаний тратят недели — а иногда и месяцы — на поиск IT-специалистов. Они оплачивают доступ к джоб-бордам, задействуют свои контакты, подключают рекрутинговые агентства. А потом за двадцать минут кое-как собирают описание вакансии и удивляются, почему качество откликов не соответствует вложенным усилиям.
Вакансия — это не административная формальность. Это первое, что кандидат читает о вашей компании. Для опытного разработчика она работает как фильтр: он решает, стоит ли вообще тратить на вас время. Если вакансия написана плохо — никакой рекрутинговый бюджет не спасёт воронку.
Этот материал написан с позиции рекрутеров, которые разобрали тысячи IT-откликов и поговорили с сотнями разработчиков о том, почему они откликаются — или нет. Здесь собраны практические советы, заточенные именно под найм в IT, а не переработанные HR-шаблоны из смежных отраслей.
Почему большинство IT-вакансий не работают
Типичное описание вакансии в IT написано для компании, а не для кандидата. Оно начинается с трех абзацев о миссии и ценностях, перечисляет двадцать требований, половина из которых — необязательные, описывает роль настолько размыто, что под неё подойдут четыре разные позиции. И ни слова о зарплате.
Опытные разработчики видели тысячи таких объявлений. За тридцать секунд они понимают: написано это вдумчиво или скопировано из шаблона трёхлетней давности. Это хорошо понимают те, кто занимается управлением персоналом в IT-компаниях на постоянной основе: качество вакансии считывается кандидатом как сигнал о том, насколько серьёзно компания относится к найму в целом.
Типичные ошибки предсказуемы. Расплывчатые обязанности — кандидат не понимает, чем именно ему придётся заниматься. Раздутые требования — список из пятнадцати пунктов, который в реальности не нужен ни на одной позиции. Отсутствие зарплатной вилки — это уже не просто минус, а красный флаг: либо в компании нет порядка, либо планируют торговаться в пользу работодателя.
При этом написать хорошую вакансию — не значит написать литературный шедевр. Достаточно быть конкретным, честным и выстроить текст так, как это удобно человеку, который читает десятки таких объявлений в неделю.
Начинайте со стека, а не с истории компании
Если и есть что-то одно, что опытный разработчик ищет в первую очередь, — это технологический стек. Не видение компании. Не корпоративные ценности. Стек.
Это логично: навыки разработчика, его опыт и удовольствие от работы напрямую связаны с тем, на чём он пишет. React или Angular, PostgreSQL или MongoDB, монолит или микросервисы — эти детали определяют, стоит ли читать дальше. Стек, спрятанный в четвёртый абзац или вовсе отсутствующий, гарантирует, что значительная часть подходящих кандидатов до него не доберётся.
Перечислите стек конкретно и близко к началу: языки, фреймворки, базы данных, инфраструктура, ключевые инструменты. Если есть легаси-система — упомяните об этом честно. Если вы активно мигрируете на новый стек, это тоже стоит написать: для многих это дополнительный повод откликнуться.
Избегайте громких расплывчатых формулировок: «используем передовые технологии, включая AI и blockchain» — это совсем не информативно. «Мы строим пайплайн обработки данных на Python в AWS, используя Airflow для оркестрации и dbt для трансформации данных.» — гораздо лучше.
Опишите ежедневные обязанности
Раздел с обязанностями — место, где большинство вакансий окончательно ломается. «Участвовать в разработке и поддержке масштабируемых систем». «Взаимодействовать с командами продукта и дизайна». Эти формулировки подходят для любой инженерной роли в любой компании — и именно поэтому они ни о чем не говорят.
Кандидат хочет знать: что я буду делать? С кем работать? Какие задачи решать и насколько самостоятельно?
Попробуйте описать конкретный вызов, с которым столкнётся человек на этой позиции. Например: бэкенд-команда сейчас переносит монолитный платёжный сервис на микросервисы — новый разработчик возьмёт в ownership два из них, от проектирования до деплоя. Одно такое предложение даёт кандидату больше, чем шесть абстрактных пунктов.
Укажите структуру команды: сколько инженеров, как организована работа, есть ли выделенный QA или тестирование на разработчиках, как принимаются продуктовые решения. Опытные кандидаты хотят заранее понимать с чем придется иметь дело.
Требования: разделяйте обязательное и желательное
Исследование, опубликованное в Harvard Business Review, показало: кандидаты — особенно женщины — значительно реже откликаются, если не соответствуют хотя бы одному из заявленных требований, даже если роль этого на самом деле не требует. Список из пятнадцати пунктов сигнализирует не о высокой планке, а о том, что никто внутри толком не подумал, что реально нужно для этой работы.
Самый рабочий подход — явно разделить требования на два уровня. Первый: то, без чего человек объективно не справится с работой. Второй: то, что будет плюсом, но не является обязательным — навыки, которые хороший кандидат освоит в процессе.
Будьте честны при описании требований. Если справиться с этой ролью можно с четырьмя годами опыта, а не с семью — напишите четыре. Если GraphQL — это то, чему команда может научить за первый месяц, ему не место в обязательных требованиях. Завышенные требования отфильтровывают именно тех кандидатов, которые могли бы стать отличным дополнением вашей команды.
Когда речь идёт об уровне специалиста, важно быть конкретным. «Мидл» в разных компаниях означает разное. Гораздо полезнее указать чёткий диапазон — например, от трёх до пяти лет коммерческого опыта разработки, желательно с опытом работы хотя бы с одной масштабируемой продакшн-системой — чем ограничиваться ярлыком.
Тот же принцип действует и при найме на senior- и руководящие позиции: несоответствие ожиданий, например на уровне Tech Lead, — одна из самых частых причин, почему такие поиски затягиваются значительно дольше, чем планировалось.
Говорите о деньгах открыто
Указывать зарплату в вакансии перестало быть опцией — в IT это уже базовое ожидание. Активные кандидаты просматривают десятки вакансий в неделю. Те, где нет вилки, просто пропускают — не потому что компания плохая, а потому что оценивать предложения с открытой цифрой быстрее и проще.
Типичное возражение: указать диапазон значит зафиксировать ожидания или открыть пространство для торга. На практике всё наоборот. Чёткая вилка убирает из воронки тех, чьи ожидания изначально не совпадают, — и экономит время обеим сторонам. По данным Stack Overflow Developer Survey, зарплата стабильно входит в топ-2 факторов, которые разработчики учитывают при выборе работы. Открытость здесь — признак осознанности, а не слабость переговорной позиции.
Называть точную цифру не обязательно. Достаточно диапазона — даже широкого. Если вилка сильно зависит от уровня кандидата, так и напишите.
Продавайте вакансию, а не только компанию
Многие вакансии тратят больше слов на описание компании, чем на объяснение того, чем интересна сама позиция. Это упущенная возможность. Кандидат может загуглить вас, почитать блог, заглянуть на страницу в LinkedIn. Есть подробные данные о том, как кандидаты изучают работодателей перед тем, как откликнуться, — и большая часть этого исследования происходит за вне описания вакансии. Чего они там не найдут — так это ответа на вопрос, почему именно эта позиция стоит их внимания. Это и должна объяснять вакансия.
Это не значит писать маркетинговый текст. Это значит быть конкретными. Команда достаточно небольшая, чтобы новый человек реально влиял на технические решения? Есть понятный путь до сеньора или лида в обозримые сроки? Задача нетривиальная, такого нет в большинстве компаний?
Удалёнка или гибрид, обучение, конференции, компенсация оборудования — всё это уместно. Но работает, только когда написано конкретно. «Оплачиваем одну конференцию в год и выделяем €1 000 на обучение» убедительнее, чем «мы инвестируем в ваш рост». Один честный абзац о том, как реально устроена работа в команде, сделает больше, чем отполированный список бенефитов.
Структура вакансии: рабочий шаблон
Ниже — не жёсткая схема, а ориентир. Именно эти блоки встречаются в вакансиях, которые стабильно дают сильный входящий поток.
О роли (3–5 предложений)
Чем занимается команда, что возьмёт в ownership новый человек, какие приоритеты на старте.
Технологический стек
Языки, фреймворки, базы данных, инфраструктура, инструменты. Отдельно — что основное, что второстепенное.
Чем вы будете заниматься
Конкретика по задачам, взаимодействию внутри команды, зоне ответственности. Три конкретных предложения лучше десяти абстрактных пунктов.
Что мы ищем
Обязательные требования — желательно не больше пяти. Желательные — с явной пометкой «будет плюсом».
Что мы предлагаем
Зарплатная вилка. Формат работы: офис/гибрид/удалёнка. Конкретные, проверяемые условия. Возможности для роста.
О команде (опционально, но работает)
Три-четыре предложения о том, сколько людей в команде, как организован процесс и что на практике означает «хорошо вписаться» — без абстрактных ценностей.
FAQ
Указывать ли зарплату, если бюджет ещё не утверждён?
Если точную вилку назвать пока невозможно, лучше написать «по результатам собеседования, конкурентно», чем молчать совсем. Но по возможности — определитесь с диапазоном до публикации. Опытные кандидаты часто уточняют деньги ещё до первого звонка, и «мы ещё не решили» — слабая позиция для старта переговоров.
Стоит ли использовать шаблоны вакансий?
Шаблоны полезны как стартовая структура, а не как готовый текст. Они помогают не пропустить важные разделы. Но есть риск, что при простом копировании текст получится слишком шаблонным. Поэтому каждый раздел нужно править, чтобы он отражал конкретную реальность этой роли и этой компании.
Как длинный список требований влияет на отклики?
Исследования показывают: кандидаты, значительно реже откликаются, если не соответствуют хотя бы одному из перечисленных пунктов — даже если большинство требований номинальные. Короткий обязательный список с явным разделением на must и nice-to-have заметно влияет на объём и разнообразие входящего потока.
Какая самая частая ошибка при написании IT-вакансии?
Писать требования раньше, чем сформулированы обязанности. Когда понятно, что человек будет делать, — понятно, что ему для этого нужно. Большинство раздутых или несогласованных списков требований появляются именно потому, что их составляют в отрыве от реального содержания роли.
Важен ли employer brand в тексте вакансии?
Да, но здесь всё работает иначе, чем многие компании предполагают. Длинные рассуждения о ценностях и культуре обычно пролистывают или вовсе игнорируют. Зато конкретные детали — размер инженерной команды, как проходят код-ревью, как устроены дежурства — читаются внимательно. Настоящая конкретика убеждает больше, чем гладкая общая риторика.
Заключение
Хорошая вакансия не гарантирует хорошего найма. Но плохая вакансия незаметно отсекает именно тех кандидатов, с которыми вы не успеете даже поговорить. Востребованные разработчики не находятся в отчаянном поиске — они оценивают вас так же внимательно, как вы оцениваете их. И начинается эта оценка с текста вакансии.
Чтобы написать хорошее объявление, не нужны маркетинговые навыки. Нужно достаточно хорошо понимать роль, чтобы описать её точно, и достаточно уважать кандидата, чтобы не тратить его время на воду. Конкретный стек, честный скоуп, прозрачная зарплата, реальный рассказ о команде — этого уже достаточно, чтобы выделиться на фоне большинства.
Компании, у которых разрыв между теми, кто откликнулся, и теми, кто реально подходит, остаётся стабильно большим, нередко обнаруживают: проблема начинается именно здесь. Те, кто предпочитает делегировать весь процесс — от составления вакансии до выхода кандидата на работу — специалистам с рыночной экспертизой, обращаются за профессиональным IT-рекрутингом и получают готовый результат, а не учатся на ошибках.
Пишите вакансию так, будто вам важно, кто её прочитает. Этого уже достаточно, чтобы быть лучше большинства конкурентов.
Мы здесь, чтобы помочь
Если вы свяжетесь с нами по электронной почте, мы гарантируем, что вы получите ответ от нас в течение 2 (двух) часов в любой рабочий день и в течение 6 (шести) часов в любой другой день (праздничные дни и т. д.).