Як написати технічну вакансію, якій повірять розробники

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

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

Погодьте роль до написання сторінки

Спочатку з’ясуйте, навіщо відкрито роль, які результати потрібні в перші місяці й за які рішення відповідатиме нова людина. Погодьте керівника, склад команди, бюджет, локаційні обмеження, форму співпраці та учасників відбору.

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

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

Оберіть зрозумілу назву

Назва має відображати основний вид роботи й рівень словами, які кандидат зустрічає на ринку. Внутрішні грейди й жартівливі титули слабко працюють у пошуку та створюють плутанину. «Backend Engineer, Payments» інформативніше за «Platform Ninja».

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

Відкрийте вакансію змістом роботи

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

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

Описуйте відповідальність через результати

Об’єднайте задачі в п’ять або шість напрямів. Використовуйте дієслова: проєктувати, підтримувати, мігрувати, аналізувати, розслідувати, документувати, співпрацювати. Додайте причину, чому ця робота потрібна.

«Писати якісний код» не дає критерію. «Проєктувати й підтримувати API для платіжного сценарію, включно з моніторингом та аналізом інцидентів» дозволяє кандидату оцінити досвід і підготувати приклади. Не приховуйте підтримку, customer issues чи технічний борг. Це може бути цікава інженерна робота, якщо її назвати чесно.

Розділіть вимоги й переваги

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

Усе бажане винесіть окремо й поясніть, чому це допоможе. Перевірте приховані припущення у вимогах до диплома, безперервного стажу, мови чи досвіду лише в одному типі компаній. Правила рівного ставлення залежать від країни; за правовими вимогами звертайтеся до профільного фахівця.

Покажіть технічне середовище в контексті

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

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

Чітко вкажіть оплату й умови

Публікуйте змістовний діапазон, якщо бюджет погоджено. Додайте валюту, суму до чи після оподаткування, період виплати та форму співпраці. Поясніть, чи змінюється оплата залежно від місця роботи. Надто широкий коридор переносить справжню розмову назад у приватний чат.

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

Окремо зафіксуйте віддалений, гібридний чи офісний формат, потрібний перетин робочого часу, тип зайнятості, спільні години, чергування, поїздки, обладнання та основні додаткові умови. Фраза «можна працювати віддалено» вводить в оману, якщо двічі на тиждень потрібен офіс.

Покажіть процес співбесід

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

Для take-home завдання вкажіть часову межу, приймайте неповне рішення з поясненими trade-offs і не використовуйте результат у продукті. Поясніть, хто допомагає з accessibility-запитами і коли очікувати наступну відповідь.

Не просіть зайві персональні дані до моменту, коли вони потрібні. Якщо профілі анонімні, опишіть, коли ім’я та контакти відкриваються роботодавцю.

Відредагуйте доказовість і структуру

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

Залиште один H1, короткі секції та описові H2. Використовуйте назву ролі й домен природно, а не повторюйте фразу заради пошуку. Видаліть перебільшення, внутрішні скорочення й речення, які підійшли б будь-якій компанії.

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

Перевірте вакансію перед публікацією

Фінальна версія повинна мати впізнавану назву й точний рівень, коротку причину відкриття ролі, результати та межі відповідальності. Обов’язкові здібності мають бути відокремлені від бажаних, а стек — пояснений через реальне використання. Додайте погоджену оплату, форму співпраці, місце роботи, часові обмеження, етапи інтерв’ю та власника відповіді.

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

У пошуку вакансій видно, як роль, зарплата, формат і компанія працюють разом. Перевірте власну сторінку так само: чи може підхожа людина зрозуміти роботу, умови й наступний крок без запитань про половину пропущених деталей?