Вакансия разработчика должна объяснять будущую работу, а не демонстрировать количество технологий, которые удалось вспомнить команде на встрече.
Ниже — структура текста, правила разделения must-have и nice-to-have, описание грейда, команды, legacy, условий и проверка вакансии перед публикацией.
Почему список технологий не заменяет профиль роли
Длинный перечень инструментов часто появляется из нескольких источников: текущего стека, планов на будущее, пожеланий разных интервьюеров и технологий, которые кандидат увидит один раз в год.
В результате вакансия не показывает главную работу. Сильный разработчик видит риск размытых ожиданий, а рекрутер получает отклики по словам, но не по уровню задачи.
Начните с результата, а не со стека
Первый блок вакансии должен отвечать на вопрос, какой результат человек создаст в ближайшие месяцы. Например: запустит новый сервис, стабилизирует критичный контур, разделит монолит или возьмёт ownership мобильного приложения.
Результат помогает определить уровень, опыт и критичные технологии. Без него список требований неизбежно разрастается.
Опишите продуктовый контекст
Разработчику нужен контекст: кто пользователи, на какой стадии продукт, какие ограничения по нагрузке, безопасности, интеграциям и срокам. Не обязательно раскрывать конфиденциальные детали, но задача должна быть понятной.
Фраза «высоконагруженный продукт» мало полезна без объяснения, какие технические решения и ответственность действительно ждут человека.
Разделите стек на обязательный и обучаемый
Must-have — это то, без чего человек не сможет войти в роль в разумный срок. Nice-to-have — опыт, который ускорит старт, но может быть освоен или компенсирован соседней компетенцией.
Если технология используется только в небольшом модуле, не делайте её фильтром для всей вакансии. Укажите контекст использования и ожидаемую глубину.
- Основной язык и уровень владения.
- Ключевой фреймворк.
- Критичная база данных или платформа.
- Обязательный production-опыт.
- Технологии, которым можно научиться после выхода.
Как описать уровень разработчика
Грейд лучше показывать через самостоятельность и масштаб решений. Middle работает в понятной зоне, Senior проектирует решения и управляет рисками, Lead отвечает ещё и за качество работы команды или техническое направление.
Количество лет само по себе не определяет уровень. В вакансии полезнее назвать тип решений, объём ownership и ожидаемое взаимодействие.
Команда и процесс разработки
Укажите состав команды, кому подчиняется роль, кто принимает архитектурные решения, как устроены code review, релизы, on-call и планирование.
Кандидат должен понимать, входит ли он в зрелую инженерную среду или будет строить часть процессов с нуля. Оба варианта могут быть привлекательны, если описаны честно.
Для ролей на стыке development, product и digital можно использовать подбор IT и digital-специалистов с отдельной проверкой смежной экспертизы.
Технический долг и legacy
Не скрывайте legacy под словами «динамичная среда». Объясните, какая доля работы связана с поддержкой, миграцией, рефакторингом и новой разработкой.
Сильный инженер не обязательно боится старого кода. Он избегает ситуации, где технический долг существует, но компания отрицает его и не даёт полномочий на изменения.
Условия, которые должны быть видны сразу
Формат, локация, часовой пояс, диапазон, тип договора и ключевые этапы интервью лучше указывать до первого разговора. Скрытые условия увеличивают нерелевантную воронку.
Если возможны несколько форматов, обозначьте границы. «Удалённо» не должно внезапно означать обязательные встречи в офисе каждую неделю.
Как писать обязанности
Обязанности должны описывать повторяющуюся работу и ответственность, а не все возможные задачи отдела. Используйте конкретные глаголы и объединяйте связанные пункты.
Пять-семь содержательных обязанностей обычно полезнее двадцати одинаковых формулировок про участие, взаимодействие и выполнение поручений.
- Проектировать и развивать конкретный контур.
- Принимать технические решения в заданной зоне.
- Участвовать в code review.
- Работать с продуктом и аналитикой.
- Поддерживать качество и эксплуатацию.
Как писать требования
Каждое требование должно иметь связь с задачей. Если вы не можете объяснить, где и как компетенция проверяется в работе, уберите её из must-have.
Не смешивайте личные качества с технологическим списком. Самостоятельность и коммуникацию лучше раскрывать через контекст роли и интервью.
Что убрать из текста
Уберите штампы, которые не дают информации: молодая команда, печеньки, дружная семья, интересные задачи и конкурентная зарплата без диапазона.
Также стоит убрать требования, которые формально звучат солидно, но не влияют на результат: знание всех облаков, всех баз данных и всех архитектурных подходов одновременно.
Как проверить вакансию до публикации
Покажите текст действующему разработчику похожего уровня и попросите пересказать роль. Если человек не понимает приоритет, будущую работу или уровень полномочий, кандидат тоже не поймёт.
После первых откликов анализируйте не количество, а релевантность. Нерелевантная воронка часто указывает на неясный title, смешанный scope или слишком широкий стек.
Экспертный подбор программистов начинается с калибровки профиля, чтобы рынок видел реальную роль, а не сборник пожеланий.
Типичные ошибки работодателя
Главная ошибка — пытаться застраховаться от неверного найма количеством требований. Это не улучшает оценку, а уменьшает рынок и создаёт ложное ощущение точности.
Вторая ошибка — писать вакансию как внутреннюю должностную инструкцию, не объясняя, почему сильному кандидату стоит обсуждать роль.
- Смешать две-три роли.
- Скопировать стек всей компании.
- Не назвать главную задачу.
- Спрятать условия.
- Использовать несовпадающий title.
- Добавить требования без способа проверки.
Чек-лист хорошей вакансии
Перед публикацией убедитесь, что текст можно прочитать за несколько минут и понять продукт, задачу, уровень, критичный стек, команду, формат и этапы.
Вакансия не обязана нравиться всем. Она должна быть понятна релевантным кандидатам и честно отсеивать тех, кому не подходит контекст.
- Понятный title.
- Один главный outcome.
- Короткий продуктовый контекст.
- Must-have отделён от nice-to-have.
- Команда и reporting line.
- Диапазон и формат.
- Прозрачные этапы.
Системный поиск разработчиков работает лучше, когда вакансия связана со scorecard и каждым этапом оценки.
Как вакансия влияет на дальнейший отбор
Хорошо составленный текст становится основой scorecard. Каждое критичное требование получает свой вопрос или кейс, а интервьюеры не проверяют случайные темы.
Так компания сокращает дублирование этапов и повышает качество обратной связи.
Частые вопросы
Сколько технологий оставлять в must-have?
Только те, без которых человек не сможет войти в роль в разумный срок. Остальное переносите в nice-to-have или контекст стека.
Нужно ли указывать зарплатный диапазон?
Да, если это возможно в вашей модели. Диапазон снижает количество заведомо несовпадающих процессов.
Можно ли использовать внутренний title?
Можно, если он понятен рынку. Иначе добавьте внешний эквивалент и объясните уровень.
Стоит ли писать про технический долг?
Да, без раскрытия конфиденциальных деталей. Важно честно показать долю поддержки, миграции и новой разработки.
Кто должен утверждать текст вакансии?
Hiring manager и рекрутер, а при возможности — действующий специалист сопоставимого уровня.
Вывод
Сильная вакансия сокращает нерелевантную воронку и даёт основу для структурированного интервью. Она не обещает идеальную работу, а честно показывает задачу и условия.
Если вам нужен подбор разработчиков, передайте вакансию IT and Digital — первые релевантные кандидаты покажем в течение 2 дней.