Отже, ви визначили компанії, в яких хочете працювати, написали класне резюме, де відобразили лише релевантну для роботодавця інформацію і бінго! З вами готові продовжити спілкування! Залишається дізнатися, як же пройти всі кола співбесід, складаючи на роботодавця виключно позитивне враження.
У цій статті — досвід Дениса Шаматажи, Product/Project Manager-а, який за 5 років встиг побувати як на боці пошукача роботи, так і провести сотні співбесід у якості менеджера. Зі статті ви дізнаєтеся про те: які запитання ставлять на ознайомчій, технічнічній і фінальній співбесідах, які тестові завдання бувають, у чому полягає основна мета кожного з них і яких відповідей від вас чекають.
Перше, що вам варто розуміти — той факт, що співбесіди бувають абсолютно різні. Одного разу мене взяли на роботу відразу після єдиної двогодинної розмови із СЕО. Ми зідзвонилися, поговорили на загальні теми. Наприклад, про Scrum:
CEO: Як ти ставишся до SCRUM?
Я: Погано до SCRUM ставлюся, мені він не подобається.
CEO: О, мені теж. А ти з Америкою працював?
Я: Працював, так.
У схожому ключі поговорили ще дві години, наступного дня я вже вийшов на роботу, і проєкт закінчив на відмінно. Але цей випадок — швидше, виняток, ніж правило.
Давайте пройдемося по етапах співбесід у загальних рисах. Як правило, етапи, які ми можемо проходити — це:
- ознайомче з рекрутерами;
- тестове завдання;
- технічна(і) співбесіда(и);
- фінальне інтерв’ю.
ОЗНАЙОМЧЕ З РЕКРУТЕРОМ
Цей етап дуже відрізняється, залежно від компанії. У нас, наприклад, рекрутери відкидають людей, які не зовсім підходять. Ми з рекрутером дивимося на цінник, який хочуть кандидати, навички, наскільки кандидат відповідає нашим вимогам, після чого у мене десь близько половини людей із djinni.co не проходять цей етап. Тут ще багато чого залежить від майданчиків, із яких прийшли кандидати. Наприклад, якщо я розміщую вакансію на своїй facebook-сторінці, до співбесіди доходить величезний відсоток людей.
НЕВІДПОВІДНІСТЬ ВАКАНСІЇ
Ми відсіюємо людей, які планують перейти на позицію frontend developer з customer support-a без жодних пояснень у супровідному листі. Людина просто вирішила стати фронтендом і подалася до нас. Якщо в супровідному листі грамотно розписано, що у вас є досвід і ви розробляли, але комерційно працювали лише як customer support, а неяк РМ, це аргументована причина. Але, тим не менш, дуже часто відсіюються ті люди, які взагалі ніяк не відповідають вакансії.
НЕВІДПОВІДНІСТЬ ЗП
Далі, наприклад, досить часто відсіюються люди, цінник яких схожий на наведений нижче.
Якщо компанія має у своєму розпорядженні бюджет у $2500, а людина подається на $7500, то вам немає, про що розмовляти. Також зустрічається зворотний випадок, коли людина подається на $250, і каже «Господи, будь ласка, нехай буде $150, тільки візьміть мене».
Кандидати без досвіду не беруть до уваги, що компанія намагається вирішити зовсім іншу проблему. В команду потрібна людина, яка допоможе вирішувати завдання, а не той, хто буде на підхваті за $150, так що кандидатів із сильною невідповідністю до вакансії ми теж намагаємося не пропускати до наступного етапу.
Ще один тип поганих резюме — коли здобувач намагається потрапити в усе, що завгодно, тобто пише «Я — customer support, account manager, project manager, product manager, scrum master» — це теж даремно.
Таких людей ми одразу відсіюємо, і їх в Україні, в Росії та и Індії дуже багато. Тому що найчастіше я не можу зрозуміти, наскільки ця людина реаліст і захоче з нами довго розвиватися.
Розповсюджений запит роботодавців — це менеджер із розумінням QA, який зуміє налаштувати процес тестування. Навчитися підтримувати якість навіть без тестувальника допоможе курс Quality time.
ОЗНАЙОМЧЕ З РЕКРУТЕРОМ: ЩО РОБИТИ, ЩОБ НЕ ПРОВАЛИТИСЯ?
Рекрутерам, напевно є, чим доповнити список, я ж поділюся речами, на які сам звертаю увагу в першу чергу.
Не йти, якщо зарплатні очікування і вимоги не відповідають. Я не завжди полюбляю, коли ти розглядаєш кандидата на середню позицію, а він каже: «Слухай, я взагалі джун, мені просто було цікаво», або щось на зразок цього.
Дізнатися про компанію і продукти. У мене часто бували ситуації, коли технічно людина підходить, але на питання СЕО: «Що ти знаєш про наш проєкт?» відповіла: «Ну, я знаю, що у вас готель». А у нас от зовсім не готель. Наскільки ви зрозуміли, фінальну співбесіду кандидат не пройшов.
Намагайтеся дізнатися хоча у загальних рисах, де ви будете проходити співбесіду. Це здається теж очевидним, але просто в якийсь момент рекрутери самі пишуть: «Слухай, не хочеш до нас на співбесіду?». Ти погоджуєшся, а на другому етапі питають: «А що ти знаєш про наш продукт?», після якого можна дійсно впасти в ступор.
Проявляйте інтерес, ставте питання. Я люблю ставити питання і сам позитивно дивлюся на людей, які під час співбесіди ставлять багато запитань. Це означає, що їм цікаво і вони навіть можуть відмовитися, тому що якась із ваших відповідей не сильно відповідає їх уявленням про ідеальну роботу.
Показуйте нематеріальну мотивацію. Не варто одразу в лоб питати: «Скільки ви готові мені заплатити?» Із приводу грошей можете уточнити наприкінці співбесіди: «Підкажіть, будь ласка, яку орієнтовно зарплатну мітку ви розглядаєте?».
ТЕСТОВЕ ЗАВДАННЯ
Є багато різноманітних тестових завдань. Зазвичай цей етап, на моїй практиці, проходить 3% людей. Мета тестового: показати ваш технічний рівень, лаконічність і те, як ви вирішуєте проблему.
Більшість junior PM роблять на тестовому одну й ту ж саму помилку: намагаючись показати, наскільки класно вирішують завдання, розписують прості завдання на 4 сторінки.
Коли я був зовсім юним, зробив тестове завдання на 9 сторінок. Це було у 2013, я розписав все докладно, вирішив проблему дуже здорово, мене запитали: «Ти ж проблему вирішуєш, а не доповідь пишеш».
І, відповідно, ваше завдання — вирішити проблему, а не оформити гарно і тому подібне. Існує максимальна кількість різноманітних тестових завдань, я покажу три групи, з якими стикався найчастіше.
1. ТЕСТОВЕ — СПРОБА ЗРОЗУМІТИ, ЯК ВИ ВИРІШУЄТЕ ЗАДАЧУ
Це реальне тестове на позицію PM, яке у мене було. Воно складалося з 20 пунктів, і відбір проходила одна люда, відповіді якої максимально влаштовували роботодавця.
Зверніть увагу на 17 пункт. «Викладіть куди-небудь код “Hello, world” на третьому Пітоні».
Хтось починає розгортати Heroku, демонструючи, як класно вміє справлятися з технологією. Насправді, можна було просто в коментарях до цієї частини тестового скинути код “Hello, world!” і витратити на завдання 2 хвилини. Менеджеру, який наймає фахівця, важливо розуміти, що PM не витратить 15 годин на рішення якого дурнуватого завдання, якщо того ж ефекту можна досягти за 15 хвилин.
Ви показуєте, наскільки швидко і лаконічно можете вирішити цю проблему. Тому що найчастіше, потрапляючи у подібний проєкт, ви, не знаючи чого-небудь, повинні вирішувати проблеми швидко, але при цьому вдумливо, а не будувати величезні палаци.
Для початку, можна загугли, як вирішуються подібні завдання. Тут не потрібен технічний бекграунд, набагато важливіше вміння максимально швидко розбиратися в проблемі. Якщо ви не можете розібратися самостійно, шукайте знайомого програміста, який допоможе.
Технічна освіта повинна бути, але якщо її немає, абсолютно не страшно. Майте на увазі, що без технічного бекграунду потрібно бути готовими до 2 проблем:
- Ви ніколи не можете естімувати завдання самостійно, тому що починаєте плутатися в цифрах, не знаєте, наскільки складна ця задача і які є підводні камені.
- Вас можуть обманювати на естімейті. Припустимо, якийсь розробник заестімейтить завдання за два тижні. Ви повірите, прийдете до боса і скажете про 2 тижні, а він може відповісти, що таке завдання робиться за 3 години. У підсумку виявиться, що розробник хотів максимально спокійно зробити задачу без зайвого пінгу з вашого боку.
2. ТЕСТОВЕ — ВИРІШЕННЯ НАЯВНОЇ ПРОБЛЕМИ
На останніх проєктах, де я працював, це дуже поширена практика, коли роботодавець говорить: «У нас зараз нікому описати задачу. А давайте ми дамо її в якості тестового і подивимося, хто та як її вирішить!». Це теж дуже розповсюджена тема, і я її, чесно кажучи, не сильно полюбляю. Керівництво компанії у виграші: отримують безкоштовне вирішення своєї проблеми і можливість оцінити, хто з претендентів впорався краще за інших. У західній практиці подібні тестові найчастіше оплачуються.
Якщо у вас є доступ до продукту, можете подивитися, як реалізовані схожі модулі в інших місцях сайту або програми, і спробувати пройтися по всіх кейсах, тобто, з усіх шляхів, як ви можете пробитися до цього вирішення задачі, подивитися всілякі граничні ситуації, де і як може статися.
Якщо у вас немає доступу до продукту, тоді просто шукайте максимально схожий продукт і намагайтеся розібратися з цим завданням у ньому. Описуєте, знаходите приклади і так далі. Такі рішення не повинні займати у вас дуже багато часу. Бажано вмістити тестове в п’ять хвилин читання роботодавця.
3. КЛАСИЧНЕ ТЕСТОВЕ
Є продукт, скажи скільки і як ти його зробиш.
У нас є мобільний застосунок банку, у нього є РМ, арт-директор, дизайнер тощо. Скільки часу займе реалізація, у скільки вона обійдеться замовнику, і як ти цей скоуп поділиш?
Як вирішувати цю проблему? Найчастіше я раджу заестімейтити iOS застосунок. Вам дають приклад програми і кажуть: «Ось, банк Х. Скільки часу займе реалізація перших 3 сторінок?»
Як найлегше вирішити цю задачу: ви просто знаходите знайомого iOS розробника або будь-яку інформацію на Glassdoor, як завгодно. Але бажано знайти людину, з якою ви якось взаємодієте, і попросіть її заестімейтити.
Якщо говорити максимально поверхнево, можете просто помножити це число на 2–2,5 у якості ризику і, відповідно, видайте рішення. Тут головне, щоб ви не просто показали ваше рішення, але й описали, на підставі чого воно приймалося. Наприклад: «Мені знадобиться 250 годин, того і того, ось стільки грошей, ось діаграма». І далі вже вказати пояснення, які включають ризики. Хороше вирішення задачі:
- має лаконічну структуру рішення;
- чітко відповідає на поставлене запитання;
- має окремий розгорнутий алгоритм рішення у вигляді невеликої післямови, в якій ви пояснюєте кожен пункт (можна на безліч сторінок).
Якщо в деяких пунктах ви не впевнені, краще їх не вказувати. Намагайтеся зробити так, щоб перевірка зайняла 2–3 хвилини, після яких людина розуміє все, що ви хотіли сказати.
ТЕХНІЧНА СПІВБЕСІДА
Півтора роки тому я проходив співбесіду в московську компанію і провалився на питаннях про backend і протоколи, які взаємодіють на рівні клієнт-сервера. Хоча брали мене на мобільний проєкт.
Я люблю іноді проходити такі співбесіди, тому що вони дають розвиток і розуміння тем, які ви точно не знаєте. Тому що іноді є відчуття, ніби ви вже все вивчили, пройшли якийсь якісний курс, а потім приходите на якусь співбесіду, і вас запитують: «Розшифруй-но мені SOLID, поясни, що означає кожна буква». Ви говорите: «Я не знаю», і вам відповідають: «Все, спасибі, до побачення».
Ви йдете і думаєте, що курс безглуздий і нічого хорошого вам не дав. Насправді, ні. На кожному проєкті є свої болі, і про ці болі вас можуть запитати, вони жодним чином не стосуватимуться проєктного менеджменту. Не бійтеся цього. Якщо у вас запитують якесь безглуздя, не звертайте на це увагу.
Технічна співбесіду і та її частина, яка стосується технічних питань, зазвичай декомпозується на кілька окремих груп:
Hard skills питання: про SCRUM, Kanban тощо.
Soft skills питання: як ви вирішуєте цю проблему, в яких ситуаціях опинялися, аж ніби розробник не має значення.
Ситуативні питання: «ось два скоупи, на одному — через день клієнт почне лаятися, а на іншому — розробники заблоковані. Який із них ти візьмеш у роботу в першу чергу?».
ТЕХНІЧНІ ПИТАННЯ
Сюди входять питання, які перевіряють вашу технічну грамотність. Їх досить багато, і найчастіше вони залежать від технологічного стеку.
Такі теми може розібрати навіть звичайний просунутий користувач мережі. Вам, швидше за все, потрібно зрозуміти, як працюють бази даних, що таке SQL, як ним користуватися. Бажано хоча б на рівні розуміння розібрати якусь мову програмування. Я раджу прочитати Python The Hard Way.
Це не найбільш пріоритетне, що може бути, але якщо підсумувати, з того, що було в моєму досвіді, найпоширеніші питання мені задавали ось за цими дев’ятьма пунктами.
Особливу увагу приділіть git, github, bitbusket, тому що з цим ви будете дуже часто стикатися. Для початку потрібно ознайомитися хоча б поверхово.
Ці питання вирішуються двома способами.
Перший спосіб — постійно моніторити будь-які технічні блоги, підписатися на habr.com, vc.ru, читати TechCrunch. Просто майте розуміння того, на якому рівні зараз знаходиться ринок, якщо вам це цікаво. Якщо ж це абсолютно не цікаво, тоді чесно дайте собі відповідь на питання, яка у вас мотивація бути проєктним менеджером?
Другий момент — пройдіть якийсь курс про те, як влаштований інтернет і клієнт-сервер.
ПОВЕДІНКОВІ ПИТАННЯ
Теж досить розповсюджена тема. Пропоную подивитися приклад, може, це не дуже очевидно. Вас можуть поставити в якусь ситуацію і з якої потрібно вийти.
Тут навіть не завжди йдеться про наявність або відсутність у вас технічного або менеджерського досвіду. Тут немає правильної відповіді.
Бажано звертати увагу на схожі питання, які вам ставлять. Припустимо, на одній співбесіді вас запитали: «Коли ти востаннє опинявся у надстресовій ситуації, як ти її вирішував?». Після співбесіди ви просто виписуєте всі пов’язані питання і думаєте, як би відповідали на них, спираючись на ваш досвід.
Якщо досвіду немає, можете сказати, що його немає. Якщо було щось схоже, то розкажіть про щось схоже. Тут головне — завжди відповідати на чітко поставлене питання чіткою відповіддю, не треба розтікатися мислію по древу. Намагайтеся просто підготуватися до таких питань. Їх не так багато, і будь-який досвідчений рекрутер, мені здається, ставить завжди 10–15 схожих запитань.
ОЦІНОЧНІ ПИТАННЯ
Новачкам такі питання навряд чи будуть ставити на співбесідах. Ви, напевно, завжди бачили ці статті з кричущими заголовками «15 речей, які запитують працівники у Майкрософт».
Або коли говорять: «Ось у Google запитують, скільки шкарпеток може поміститися в одну машину?» Це, насправді, дуже класне питання. Я майже впевнений, що мало хто розуміє, чому ставлять ці дурні питання.
Давайте розберемо приклад:
СКІЛЬКИ ТЕНІСНИХ М’ЯЧІВ ПОМІСТИТЬСЯ У КВАРТИРІ?
До речі, на одній зі співбесід я відповідав на таке питання, так що пропоную готовий алгоритм рішення і попутно розповім, навіщо це все.
ПЕРШИЙ КРОК — УТОЧНИТИ ВСІ МОМЕНТИ.
Це дозволяє зрозуміти, наскільки РМ зосереджений на деталях. Наприклад:
- Це типова або специфічна квартира?
- Яка квадратура у цієї квартири?
- Які меблі?
- Який розмір стель?
Ви уточнюєте, щоб змоделювати ситуацію, в якій перебуваєте. Тому що в роботі вам можуть поставити якесь схожий питання, типу: «Скільки лідів у нас може поміститися в цій таблиці?». Однак на співбесіді вам точно не поставлять такого питання. А от якесь таке оціночне — запросто.
Ми оцінюємо і моделюємо ситуацію. Можемо проговорити це усно, письмово, але, бажано, розпитати роботодавця про всі деталі, які він, швидше за все, від вас приховав.
КРОК 2. СКЛАСТИ СПИСОК ВІДОМИХ АРГУМЕНТІВ.
Подивіться, яка середня площа квартири, висота стель, скільки місця займають меблі. Множимо квадратуру на розмір стель, отримуємо обсяг квартири в кубічних метрах, після чого віднімаємо від загального обсягу приблизний обсяг меблів. Потім обчисліть обсяг одного тенісного м’ячика, і відповідь готова.
Ніхто не очікує від вас стовідсоткової точності, набагато цікавіше спостерігати за ходом ваших думок.
Далі ви розписуєте формулу і говорите: «Мені здається, що стільки-то тенісних м’ячів поміститься у вашій квартирі». Проблема вирішена.
Здається, що такі завдання — максимальний абсурд, але, тим не менш, ці питання дуже класно пояснюють головне:
- Наскільки добре ви вмієте розібратися в ситуації, яку ви абсолютно не розумієте.
- Як ви працюєте з приблизною точністю. Якщо у підсумку з’ясується, що правильна відповідь не 200, а 300 м’ячів, то, насправді, ви вже класно впоралися. Якщо ж правильна відповідь буде на 12,5 тисяч більше, значить, швидше за все, ви чогось не врахували.
ПИТАННЯ НА ПРІОРИТЕТ
Я знаю, що у Booking (сервіс для бронювання готелів, я думаю, ви знаєте про таку компанію) на співбесідах ставлять багато питань на пріоритет. Що в їх основі?
«Ви приходите вранці на роботу або прокинулися на роботі поза контекстом, і ось у вас є 5 завдань, які потрібно вирішити».
І тепер найсмішніше — найкраще недосвідченість проджект менеджера ілюструє відповідь, яку він дає без уточнення деталей.
Crash на головній сторінці сайту схожий на найважливішу проблему, яка може статися. Однак може бути така ситуація, що до вас через головну сторінку сайту ніхто не приходить.
Ми навіть не знаємо, який у нас проєкт. Уявімо, що ми продаємо книги, а ви не уточнили цього. Можливо, на сторінку книг всі переходять зі сторінок блогерів або всі з реклами в Google і не потрапляють на головну сторінку, а потрапляють одразу на сторінку товару, і для них головна сторінка не має жодного значення.
А може навпаки, головна сторінка — це найважливіше, що є, тоді вона точно стане першою за пріоритетом.
Daily scrum починається через 10 хвилин. Це питання — спроба зрозуміти, наскільки добре ви розумієте SCRUM, тому що, в scrum-і кажуть, що не можна переносити жодні Daily мітинги, і всі ритуали повинні мати чітку структуру, час і тривалість.
Front і back не можуть зрозуміти, що робити за таском. А який статус у цього таску: critical або low priority? А якщо це medium таск, тоді давайте його вирішимо на daily scrum-і, тоді потрібно його поставити після Daily scrum.
Документація на сьогодні. Коли її потрібно здати? Сьогодні або завтра? Якщо по цій документації розробники почнуть працювати завтра, тоді ви можете написати її о 7 вечора. Якщо на сьогодні, значить, потрібно враховувати цей момент у постановці пріоритетів.
Потрібно розкручувати всі пункти до того моменту, поки ви не зрозумієте їх пріоритезацію. Якщо ж ви запропонуєте варіант без уточнень, найчастіше такий підхід вже негативно на вас позначиться, навіть якщо рішення буде точнісінько правильним.
ФІНАЛЬНЕ ІНТЕРВ’Ю
Фінальну співбесіду в невеликих компаніях найчастіше проводить віце-президент, СЕО, PMO або інша особа, до якої ви йдете у підпорядкуванні глобально. Вона, в першу чергу, повинна визначити ваш психотип: що ви за людина, що вас мотивує, дратує, які у вас є проблеми, які ваші об’єктивно слабкі сторони, як ви працюєте над ними, які у вас є об’єктивно сильні сторони.
Можливо, у вас є щось сильне, що при цьому не є вашим профільним завданням, але ви можете з цим допомогти. Можливо, ви добре займаєтеся рекрутингом людей, а може, класно розповідаєте лекції або ведете блог.
Також керівник визначає вашу сумісність із культурою компанії. Тобто людина може пройти технічну співбесіду, співбесіду з рекрутером, приватне тестове завдання, але ви приходите і розумієте, що вона не підходить вам, і при цьому вона зовсім непогана.
СЕО може зрозуміти, що в маленькому стартапі ця людина не принесе тієї цінності, яку може принести посередня особа, однак із сильною культурною складовою, умовно кажучи.
Існує класна компанія Ultimate Guitar, я просто мрію коли-небудь із ними попрацювати, тому що я дуже сильно повернутий на музиці. До них складно потрапити, не захоплюючись музикою. Але, при цьому, це не заважає пройти тестове завдання.
РОБІТЬ СТАВКУ НА SOFT SKILLS
Не перебивайте, не відповідайте на питання розмивчасто тощо. Скоріш за все з вами обговорять точки зростання і вашого розвитку в компанії. Найчастіше фінальна співбесіда — це дуже поверхнева спроба зрозуміти, наскільки людина відповідатиме рисам, культурі і психотипу того оточення, в яке ви плануєте її помістити.
Існує також інший варіант, коли фінальна співбесіда — це просто спроба зібрати воєдино все те, що було виконано до цього. У мене бували випадки, коли я проходив тестове, технічне, друге технічне, а потім на фінальному тобі дають три результати ось цих точок і вердикт. Виявляється, ти просто проходив три співбесіди паралельно. І потім результати трьох співбесід тобі дають і роблять висновок: «Слухай, напевно, ти проходиш».
ВИСНОВКИ
- Намагайтеся, щоб ваш цінник і навички відповідали вимогам компанії, в яку ви подаєте резюме.
- Якщо вирішили змінити сферу діяльності, намагайтеся вказувати всі нюанси в супровідному листі.
- Дослідіть компанію та продукти, які вона надає.
- Ставте питання, проявляйте нематеріальну мотивацію.
- При виконанні тестового завдання будьте лаконічні. Не розписуйте на 4 сторінки те, що можна вмістити у 2 абзацах.
- Розберіться у технічних деталях, хоча б поверхово.
- Завжди ставте уточнюючі питання, особливо, коли справа стосується завдань на оцінку і пріоритезацію.