Кандидати готові змиритися з тим, що ви шукаєте JS-ниндзю або бога бекенд. Але вони навряд чи вам пробачать, якщо ви настільки ж «творчо» підійдете до опису вакансії. На які пункти звернути увагу, якщо ви складаєте вакансію для IT-фахівця?
Технології. жага подробиць
Дайте зрозуміти, з чим доведеться зіткнутися фахівця. Мова не тільки про вимоги до кандидата, щоб він зміг справлятися з поставленими завданнями, а й про те, щоб він відразу представляв всю картину розробки цілком. Наприклад, у нас в роботі була вакансія teamlead-розробника.
Вимоги були такими:
Але при цьому важлива додаткова інформація: який використовується підхід до розробки, додаткові інструменти. У даній вакансії було:
- стек технологій: React, Node.js, Webpack, ES6, Git;
- процес розробки будується на методології Agile;
- інструменти, що полегшують нашу роботу: Jira, Jenkins, Graphite, Sentry, Slack.
У додатковій інформації можна вказати, з якими фахівцями треба буде працювати і скільки їх. Наприклад: «У команду з чотирьох JS-розробників ми шукаємо тімліда, щоб разом з верстальниками, бекенд-розробниками, тестувальниками, продуктовими менеджерами і дизайнерами робити найзручніший портал».
Завдання. Що там з кодом?
Здається, ну що ще треба? Ми ж всі необхідні технології згадали і навіть більше. І завдання одне: кодіть, кодіть і ще раз кодіть. Але є й інші важливі речі, про які варто розповісти в описі вакансії.
«Обережно, багато легаси!», «Вміти розбиратися в чужому коді», «Головне завдання - рефакторинг року» - ось кілька способів попередити кандидата, що належить працювати не з нуля, а часто з кодом, який писали під керівництвом кількох тімліда протягом декількох років. А зараз можна зустрітися і з десятирічним кодом, який вимагає, щоб його переписали. Чи не кожен розробник на таке підпишеться.
Кілька слів про тестування. Вважається хорошим тоном, якщо розробник робить unit-тестування свого коду. Але не у всіх компаніях це прийнято, так як забирає більше часу. Зазвичай ця історія відбувається у великих проектах. У маленьких же компаніях і стартапи все доводиться робити самому. Тому обов'язково вкажіть, чи буде тестування і якого роду.
Умови роботи. Знову «гнучкий графік»
- Змушують працювати понаднормово?
- Тисне керівництво по строками та обсягами робіт?
- Чи є строгий графік роботи?
Питання поставлено жорстко - і не всі компанії готові відповісти на них. Але є способи залишити і кандидата з відповіддю, і компанію з чесним робочим пропозицією.
Змушують працювати понаднормово? Якщо у вас в компанії часті переробки, варто чесно розповісти про це в умовах роботи. Немає сенсу приховувати це навіть до співбесіди, інакше ви і кандидати, які не готові до 11-годинному робочому дню, витратите час на непотрібні зустрічі. Знаємо компанію, яка говорить про подібну тенденції в жартівливій формі «Умови. Гнучкий графік роботи. Хочете - працюйте 10 годин, хочете - 15 :) ».
Тисне керівництво по строками та обсягами робіт? Як найкраще відповісти на питання? Написати, на якій стадії знаходиться проект. Якщо стадія зростання, вкажіть, що у вас жорсткі терміни, великі обсяги робіт і часте тестування версій. Якщо у вас стабільна компанія, але належить масштабний редизайн, теж не приховуйте. Кандидати, які не можуть багато часу проводити на роботі, лише витратять свій час, приїхавши в компанію для співбесіди.
Чи є чіткий графік роботи і наскільки строго ставляться до його недотримання? «Гнучкий графік роботи», який так люблять вказувати компанії в умовах роботи, часто означає різні речі: або це можливість зрушувати початок робочого дня на свій розсуд - з 9 до 11, або це можливість працювати з дому, або це історія про те, що «неважливо, скільки ти був в офісі, головне, що ти зробив». Будьте гранично точні у формулюваннях, не користуйтеся штампами тільки для того, щоб вони були.
Якщо є необхідність в строгому графіку, то важливо це аргументувати. Наприклад, у нас є в роботі вакансії, де необхідно працювати з 12 до 21, - це було пов'язано з робочим графіком клієнтів з країн з іншими часовими поясами.
Як правильно складати вакансію для IT-фахівця і що потрібно вказати:
- Технології, які використовують в компанії.
- Навантаженість проекту (обсяг трафіку, функціонал, навантаження на сховище або на базу даних).
- Методологія розробки: іноді бувають принципові розбіжності в цьому питанні.
- Завдання для фахівця в рамках плану розвитку продукту - «писати код» не підійде.
- Можливості для професійного розвитку: книги, конференції (відвідування і самостійні виступи), курси.
- Команда: скільки людина, яка спеціалізація у кожного, хто керівник (і чи є він).
- Рівень стабільності проекту: тривалість, інвестиції, посилання на інтерв'ю з інвесторами та засновниками, щоб кандидат краще розумів картину.
- Умови роботи: такі, які є. Щоб кандидати були готові до всього і не йшли з компанії після двох днів роботи. Печеньки не втримають в офісі.