Hiring Guides

Як написати опис вакансії, що привертає правильних кандидатів

Vadym Lobariev·5 хв читання·22 трав. 2026 р.

Вадим Лобарєв, засновник MindHunt — рекрутинг технічних спеціалістів по Європі та Україні з 2011 року


Опис вакансії — зазвичай перше, що кандидат бачить про вашу компанію. Він визначає, хто подає заявку, хто себе виключає і скільки часу займає пошук.

За моїм досвідом, значна кількість пошуків, що затягуються або дають неправильних кандидатів, починається з проблеми опису вакансії — а не браку талантів. Ось чотири паттерни, що я бачу найчастіше.


Паттерн 1: Автор не розуміє домен

Це поширеніше, ніж мало б бути, і дає описи вакансій від заплутаних до відверто оманливих.

Нещодавній приклад: опис вакансії для AI-ролі, де автор використовував "агент" і "LLM" як взаємозамінні — ніби це різні слова для одного й того самого. Це не так. LLM — це мовна модель. Агент — це система, що використовує LLM для виконання дій, прийняття рішень і виконання завдань. Змішування їх сигналізує технічно грамотному кандидату, що компанія не розуміє, що будує.

Інший приклад: опис вакансії, що вимагав "досвіду перевірки та тестування коду, написаного AI", із приміткою, що "ми шукаємо справжніх розробників, а не тих, хто покладається на AI."

Залишивши осторонь дискусію про AI-інструменти — примітка про тестування AI-коду виявляє нерозуміння того, навіщо взагалі існує QA. Якби досвідчені розробники писали ідеальний код з першого разу, QA-інженери не були б професією. Тестування — це не відповідь на AI. Це відповідь на те, що весь код має помилки, незалежно від того, хто або що його написав.

Опис вакансії, написаний кимось, хто не розуміє домен, відштовхне кандидатів, яких ви хочете — тих, хто достатньо знає, щоб помітити плутанину — і приверне тих, хто не бачить різниці.

Виправлення: Попросіть когось з доменною експертизою переглянути опис перед публікацією. Не переписати — просто відзначити технічно неточні або оманливі частини.


Паттерн 2: Забагато вимог відштовхує правильних кандидатів

Існує поширена думка, що вичерпний список вимог — це форма точності. На практиці — навпаки.

Ось чому: кандидати самостійно кваліфікують себе. Читаючи опис вакансії, вони вирішують, чи подавати заявку. Якщо список довгий і конкретний, багато кандидатів, що були б відмінними, виключать себе через дві-три вимоги — навіть якщо ці вимоги є предметом обговорення, і навіть якщо hiring manager охоче обговорив би їх.

Стандартне припущення: вимоги — це вимоги. Якщо компанія мала на увазі переваги — опис вакансії мав би це говорити.

Список з п'ятнадцяти вимог для ролі старшого розробника як правило дає два результати: невелику кількість заявок від людей, що технічно відповідають всьому (які можуть бути надмірно кваліфікованими), і велику кількість незаявок від людей, що є правильними кандидатами, але вирішили, що їх не розглядатимуть.

Виправлення: Розділіть справді необхідні навички від бажаних. Будьте явними: "Необхідно: X, Y, Z. Бажано, але не обов'язково: A, B." Це дозволяє відповідним кандидатам подавати заявку.


Паттерн 3: Кілька авторів, суперечливе бачення

Це організаційна проблема, що дає найбільш заплутані описи вакансій.

Відкривається роль. Кілька стейкхолдерів мають думки: CTO хоче сильні навички написання коду, team lead вважає, що розуміння коду є достатнім, HR хоче когось, хто підходить до культури. Ніхто не погоджується, що є реальними вимогами. Отриманий опис — комітетний документ, що намагається задовольнити всіх і в підсумку заплутує всіх.

Кандидат читає і не розуміє, яка насправді роль. Рекрутер не може ефективно проводити скринінг, тому що немає чіткого стандарту. Команда на інтерв'ю ставить різні питання і приходить до різних висновків.

Одна особливо поширена версія: "Необхідні сильні навички написання коду" проти "Розуміння коду — достатньо, вони будуть керувати іншими." Це справді різні ролі. Технічний лід на управлінській траєкторії — це не те саме, що hands-on інженер, що пише значний обсяг коду.

Виправлення: Одна людина є власником брифу. Інші стейкхолдери мають внесок, але одна людина приймає фінальне рішення щодо того, що є необхідним, що бажаним, і що роль насправді передбачає. Якщо є реальна незгода щодо того, якою має бути роль — це розмова до початку пошуку, а не під час.


Паттерн 4: Впертість перед обличчям експертизи

Четвертий паттерн найважче вирішити, тому що він стосується ставлення, а не процесу.

Компанія отримує зворотний зв'язок від рекрутера, технічного радника або досвідчених кандидатів, що опис вакансії є нереалістичним, заплутаним або невідповідним ринку. Відповідь — захищати опис, а не переглядати його.

"Ми знаємо, що нам потрібно." "Наші вимоги — це наші вимоги." "Ми просто продовжимо шукати."

Коли кілька досвідчених людей незалежно піднімають одне й те саме занепокоєння — варто поставитись до цього серйозно.

Кандидати, яких ви хочете, теж оцінюють вас. Опис вакансії, що сигналізує внутрішню плутанину щодо ролі або нерозуміння домену, впливає на те, як сильні кандидати сприймають можливість.

Виправлення: Ставтесь до зворотного зв'язку щодо опису вакансії так само, як до зворотного зв'язку щодо продукту. Перевіряйте, обговорюйте, і оновлюйте, якщо докази це підтверджують. Відкритість до експертизи в областях за межами вашої власної — не слабкість. Це те, як рішення покращуються.


Як виглядає хороший опис вакансії

Конкретний щодо проблеми, а не лише завдання. "Нам потрібен хтось, хто керуватиме міграцією нашої legacy API-інфраструктури до мікросервісної архітектури протягом 12 місяців" — корисніше за "відповідальний за розробку API."

Чесний щодо вимог. Необхідне — це необхідне. Бажане — це бажане. Не перераховуйте вісім "необхідних" навичок, коли чотири є справді необхідними.

Один автор або чіткий власник. Одна людина відповідальна за фінальну версію. Інші можуть переглянути — але бриф має чіткого власника.

Перевірений кимось з доменною експертизою. Особливо для технічних ролей, де опис включає специфічні технології, архітектури або практики.

Продає роль, а не лише перераховує. Чому хороший кандидат хотів би цю роль? Що вони будуватимуть? Як виглядає команда? Що цікавого в цій конкретній проблемі?


У MindHunt ми переглядаємо описи вакансій як частину кожного пошукового брифу — не для переписування, а щоб відзначити проблеми до того, як вони вплинуть на пул кандидатів. Якщо хочете другу думку щодо опису до початку пошуку — зв'яжіться з нами.


Читайте також: Процес ІТ-рекрутингу: що йде не так · 7 секретів успішного ІТ-рекрутингу · Технічний рекрутинг: практичний гід

V

Автор

Vadym Lobariev

MindHunt — AI-рекрутингова агенція для засновників, C-level та менеджерів з найму, які втомилися від «публікуй і сподівайся». Ми виконуємо перевірений процес пошуку для ваших найважливіших вакансій і показуємо роботу щотижня — щоб ви наймали з впевненістю, а не з надією.