Як ефективно проводити технічні співбесіди
Усі статті, обговорення, новини про Mobile — в одному місці. Підписуйтеся на телеграм-канал!
Привіт! Мене звати Андрій, я iOS Team Lead у стартап-студії Kiss My Apps, що спеціалізується на розробці mobile first продуктів. За понад 12 років досвіду в ІТ, працював на різних позиціях від Trainee до Tech/Team Lead у продуктових стартапах. Провів понад 50 технічних співбесід та навчаю цього інших.
Але так було не завжди, бо особисто я ненавидів проходити співбесіди, оскільки це був великий стрес. Багато негативного досвіду, неприємні враження та відчуття, як на допитах — це точно вплинуло на мій підхід до організації та проведення інтерв’ю.
Тому з радістю поділюся власним досвідом та корисними порадами для колег й HR-менеджерів, які планують проводити технічні інтерв’ю. Ця стаття також буде корисною для ІТ-спеціалістів, які готуються до таких співбесід.
Етапи співбесіди в IT-сфері
Хоч ми фокусуємося саме на технічних інтервʼю, важливо розглянути загальні етапи співбесіди. Для себе я виділяю наступні.
Створення списку «вітальних питань». Перший крок — це взагалі зрозуміти, хто саме нам потрібен. Який рівень кандидата, що він має обовʼязково знати та вміти, які до нього вимоги. Так можна дуже багатьох відсіяти ще навіть до співбесіди з рекрутером. Для цього робимо список «вітальних питань» до кандидата, які будуть уточнювати його вміння та знання, а не просто вимоги до вакансії.
Посилання на власний репозиторій та сторінки застосунків. Окрім вітальних питань, я завжди прошу рекрутерів запитати кандидата про посилання на власний репозиторій та, за можливості, посилання на сторінки застосунків, над якими він працював (якщо це не зазначено у CV). Хоча у багатьох кандидатів може не бути нічого у власному репозиторії або застосунки можуть бути під NDA, часто вони можуть поділитися результатами виконання тестових завдань для інших вакансій. Навіть відсутність репозиторію — це вже корисна інформація, яка надає додаткове розуміння про кандидата!
Технічні завдання. Насправді описані вище пункти — це здебільшого заміна технічним завданням. Іноді технічні завдання можуть бути must have, але я вважаю, що без нагальної необхідності їх краще не додавати. Це займає зайвий час як у кандидата, так і у компанії. До того ж якщо завдання надто великі, це може лише відвернути від вакансії, а маленькі будуть не більш інформативними, ніж звичайна розмова. Live coding, своєю чергою, лише додає напруги до і без того стресового процесу співбесіди. Далеко не кожен може адекватно й швидко мислити в таких умовах. У кандидатів займе менше часу детально описати рекрутеру свої знання певних технологій та досвід, і це дасть гарне розуміння їхніх навичок.
Ознайомлення з CV та перевірка вітальних питань. Тож нарешті переходжу до перевірки відповідей на «вітальні питання» та ознайомленням із CV та вирішую, чи кликати людину на співбесіду до рекрутера, чи одразу відмовляємо.
Співбесіда з рекрутером. Після цього — співбесіда з рекрутером, який вирішує, чи пускати кандидата до мене на інтерв’ю.
Як я оцінюю кандидатів на технічній співбесіді
Коли кандидат успішно пройшов співбесіду з рекрутером, готуємось до технічного інтерв’ю. На цьому етапі в нас вже є достатньо інформації, від якої буде залежати результат.
Я маю великий список заздалегідь підготовлених питань різної складності, що охоплюють різні технології та досвід. Ось що я намагаюся побачити та які питання для цього застосовую:
Теоретичні знання
По перше — банальні теоретичні питання, які зустрічаються на багатьох співбесідах: SOLID, architecture та design-патерни тощо. По друге — питання про різні технології, фреймворки, сервіси та інструменти. Що воно є та для чого, які потреби закриває і які вимоги додає.
Практичні навички
Це найбільша частина, де питання стосуються розуміння, як щось працює, та з якими проблемами можна зіткнутися при використанні. Ці питання повʼязані з тими, що у теоретичному блоці, але в практичній сфері. Наприклад, краще зберігати інформацію, які є основні відмінності між різними видами InAppPurchases, коли краще використовувати певну архітектуру, який design-патерн є сенс використати у такій-то ситуації.
Soft skills та hard skills
Я надаю перевагу більшій персоналізованості процесу, тому завжди маю особистий підхід до кожного кандидата, базуючись на отриманій інформації. Окрім перевірки hard skills, я також роблю великий акцент на soft skills, які має людина. Найважливіші для мене — бізнес-орієнтованість, комунікативність, самостійність, жага до самовдосконалення, ставлення до процесів. Саме ці якості допомагають мені зрозуміти, які цінності кандидат принесе в компанію та як увіллється в наш колектив.
Про що я запитую на технічних співбесідах
Зазвичай я поділяю питання на три блоки:
Досвід
Співбесіда — це завжди достатньо нервова подія, тому я намагаюсь не починати з конкретних питань, які можуть одразу викликати стрес. Це може негативно вплинути на подальший хід діалогу. Натомість я даю співрозмовнику можливість самостійно розповісти про свій досвід: з чим він працював, які технології використовував, з якими складнощами стикався та яких успіхів досяг. На цьому етапі я збираю додаткову інформацію для перевірки практичних знань і звертаю увагу на те, що саме розповідає співрозмовник. Наприклад, що він згадує в першу чергу, про що ділиться детальніше, що йому найбільше подобається, та що він вважає досягненням, а що — проблемою.
Також я порівнюю інформацію у CV зі сказаним на співбесіді. Часто в резюме інформація мінімізована, а на інтерв’ю виявляються додаткові знання та навички, не зазначені в ньому. Або навпаки, у CV написано багато, а на співбесіді стає зрозуміло, що деякі речі сильно прикрашені, і багато з підготованих питань можна виключити.
Практика
Поступово я переходжу до практичної частини. Ставлю уточнювальні запитання та перевіряю глибину практичного досвіду, який дійсно має співрозмовник і який цікавить нас. Перевіряючи наскільки добре людина розуміє те, з чим працювала, можна почути відповіді на кшталт «це для задачі не було потрібно» або «ніби читав у вільний час, але не памʼятаю». Це свідчить про те, що розробник можливо й здатен швидко виконувати поставлені задачі, але не завжди цікавиться покращенням своїх знань.
На цьому етапі я також можу зрозуміти, чи людина активно самовдосконалюється, цікавиться, як усе працює «під капотом», і поглиблює свої теоретичні знання. Якщо це так, я більше зосереджуюсь на практичних питаннях. Після оцінки практичних знань, переходжу до теоретичних питань.
Теорія
Лише наприкінці я переходжу до перевірки теоретичних знань. Перевірка завченої теорії на співбесіді здається мені марною тратою часу. Неодноразово було таке, що я ходив на співбесіди, де годину ганяли по теорії, запитували про всі можливі патерни та ставили купу питань з оптимізацій. Чув про такий досвід й в інших спеціалістів: хтось проходив, або сам проводив так співбесіди, але в результаті нічого з запитаного ніколи не використовувалось у роботі. Тож який тоді був сенс таких розмов?
Однак варто зазначити, що лише практика без теоретичних знань також не дозволить фахівцю ефективно зростати далі. Тож теорія важлива, але лише та, що закріплена практичним досвідом.
Висновки після співбесіди
Нарешті переходимо до найголовнішого — висновку. Одразу найважливіша порада — протягом усієї співбесіди памʼятати, навіщо вона взагалі проводиться, та оцінювати кандидата. Фіксувати якісь проміжні результати та враження. В мене на початку саме в цьому була головна проблема. Здавалось, вже ідеально підготував питання, якісно провів співбесіду, але кандидат, на жаль, впорався погано — відмовляємо.
А потім кандидат питає, чому саме він не пройшов, що не сподобалося та потрібно покращити. Або ж інші люди, які брали участь у його співбесіді та яким він за іншими параметрам дуже сподобався, потребують детальний фідбек. Просто «надто слабкий» або «погано відповідав» — це не висновок. Мають бути чіткі очікування від кандидата, та чіткі висновки за цими очікуваннями.
Наразі я складаю свій висновок за наступним шаблоном:
- Теоретичні знання.
- Практичні навички.
- Soft Skills.
- Розвиток та перспектива.
- Висновок.
Підсумок
1. Потрібно зрозуміти, хто нам потрібен та як це визначити, тобто обрати питання. Не просто взяти «100 найкращих питань для співбесід», а обрати такі, відповіді на які нададуть інформацію, чи підходить кандидат саме для ваших вимог.
2. Намагайтесь не змарнувати співбесіду — залежно від кандидата, його характеру та стану, підлаштовуємо хід співбесіди так, щоб отримати необхідні відповіді. А не просто завалити його і сказати, що він не проходить.
3. Завжди памʼятаємо, що потрібно зробити висновок наприкінці. Дивимось, на що вже отримали відповіді, а на чому потрібно зупинитися та зосередити увагу. Робимо нотатки, проміжні висновки.
Та й загалом, проводити співбесіду — це не тільки про те, що та у якому порядку питати. Щонайменше будьте ввічливими, посміхайтесь! Зрозуміло, що робочий тиждень міг бути важким, а співбесіди іноді проходять ввечері. Але під час цієї розмови ви є представником компанії. Багато разів у мене було так: приходив на співбесіду, де спілкуватись доводилось з людьми з камʼяними обличчями. Могли навіть закочувати очі, якщо щось не подобалось у відповідях. Не робіть так.
Також я вважаю, що співбесіда має бути корисною для обох сторін, навіть якщо подальша співпраця не складеться. Тому якщо кандидат не знає відповіді на моє питання — я самостійно розповідаю правильну відповідь, та підказую, куди ще можна поглибитись в цій темі. Навіть ті, хто одразу відповідає на питання «нічого про це не чув», можуть щось в процесі моєї відповіді доповнити, чи навіть згадати та самостійно дати відповідь на питання.
Коли людина має приємне враження від співбесіди, навіть якщо не пройшла її — вона може через деякий час повернутися на іншу вакансію, або запропонувати її більш досвідченому знайомому. Та навпаки, одна людина (тобто ви, невдоволений та втомлений) може повністю зіпсувати враження про компанію та втратити кандидата мрії. Сподіваюсь, ця стаття допоможе вам знаходити та не втрачати таких людей!
22 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів