Как НЕ нужно составлять описание вакансии для программиста: топ антисоветов I ITExpert

Топ 5 антисоветов: как не нужно составлять описание вакансий

ITExpert Блог Рекрутинг
Топ 5 антисоветов: как не нужно составлять описание вакансий

С опытом рекрутер быстро понимает, что сложно прокачаться в том, как подавать описание вакансий. Дело в том, что убрать «кофе и печенье» или «дружественную команду» из текста — это легко, а вот интересно и корректно расписать стек технологий и проект смогут не все. Однако разработчики обращают внимание именно на эту информацию.

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

Антисовет 1: указывайте базовые технологии

В требованиях вакансии не следует указывать базовые технологии, с которыми и так работают почти все разработчики. Среди них: Git, CSS, Jira, HTML, REST и так далее. В синиорной технической позиции они выглядят как «знание Google Docs» или «умение работать с ПК». Базовые технологии не передают суть проекта, а до ключевых кандидат может так и не дойти, так как длинное описание отталкивает.

Исключение: QA-позиции. Там опыт с REST может быть критичным из-за необходимости работать с API (это нужно не везде). Но если этот навык касается именно frontend/backend разработчиков, то лучше этого не указывать.

Пример Senior вакансии с базовыми требованиями

Антисовет 2: распыляйтесь на ненужные детали

Указывайте около 2–4 ключевых требований и 1–2 в nice-to-have. В противном случае кандидат может решить, что ваши требования исключительно высоки и он не подходит на вакансию (даже если он/она подходит). А вы так и не получите ответа.

Пример вакансии со слишком длинным списком требований

Сокращайте суть проекта до нескольких содержательных предложений. Обычно слишком длинное пустое описание отталкивает.

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

🟢 Хороший пример: Наш продукт — платформа из более 200 тыс. пользователей, помогающая финтех-компаниям быстро подключить готовое решение для выпуска карт. Предоставляем функции денежных переводов, мультивалютности, Buy Now и так далее. Сейчас расширяем команду, чтобы развивать новую фичу — Pay Later (BNPL).

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

Свяжитесь с нами уже сейчас
Заказать консультацию

Антисовет 3: указывайте взаимосвязанные технологии

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

К примеру, если QA специалист работал с Postman, тогда у него есть опыт тестирования Rest API. То же касается текстов вакансий из Angular и Typescript (Angular написан на базе Typescript).

Антисовет 4: используйте дешевые манипуляции

Не стоит манипулировать на вашей благодарности или действиях кандидата. Красные маркеры:

  • Заранее спасибо, что откликнулись.
  • Заранее спасибо за ответ/помощь.
  • Если вас не интересует, можете ли вы кого-нибудь порекомендовать?
  • Если хотите, обсудим ваши карьерные перспективы и не только:)

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

Антисовет 5: пишите больше очевидных вещей

Внезапно: в основном на работе разработчики пишут код. Поэтому указывать кодинг в разных формулировках в 5–7 строках обязанностей немного странно.

Хотите немного development’а в шести строках?

При этом есть позиции в IT, где обязательно нужно прописывать задания позиции. Например, в менеджменте (PM, Scrum Master, Team/Tech Lead, PO) это следует делать, поскольку обязанности в разных компаниях могут существенно отличаться. Это влияет на то, интересна ли и подходит ли ваша позиция кандидату. В этот список также отнесем маркетологов. Маркетолог без задач — как вакансия программиста без языка. Поэтому обязанности, цели и задачи должны быть в описании их вакансий.

Нюанс: если вы пишете описание вакансии для QA Auto — лучше укажите процент мануального тестирования. Обычно кандидаты об этом все равно переспросят.

Насколько полезным был этот пост?

Click on a star to rate it!

Средний рейтинг 5 / 5. Количество голосов: 2

Оценок пока нет! Будьте первым, кто оценит этот пост.

Поделиться с друзьями
Оставьте комментарий

up