З яких етапів має складатися співбесіда. Поради з власного досвіду

Я — Senior Software Developer та Team Lead в компанії Edvantis. За 6 років кар’єри розробника я побував по обидва боки «барикад»: і був кандидатом, і проводив співбесіди на продукти, де працював. Також я брав участь у розробці внутрішнього інструменту для рекрутингу, де ми оптимізовували процес найму нових працівників Edvantis.

У кожної компанії чи продукту різна кількість кіл пекла етапів співбесіди, які потрібно пройти для отримання оферу. Спробую поділитися своїм досвідом на дуже популярну зараз тему співбесід. Зосереджуся на технічній частині і, сподіваюсь, допоможу як молодим спеціалістам-кандидатам, так і експертам, які тільки починають інтерв’ювати кандидатів.

Переважно на кандидата чекає наступний шлях: контакт з рекрутером -> скринінг -> HR-інтерв’ю -> технічне інтерв’ю -> спілкування з представником замовника чи PM-ом -> Feedback (як останній етап співбесіди або ж відповідь листом/дзвінком). На всіх цих етапах вас супроводжуватиме рекрутер та інформуватиме про статус кожного з них.

Щоб мінімізувати витрати і час на сам процес, співбесіду часто розбивають на етапи по ~30 хвилин. На кожному етапі присутня людина, яка відповідає за свою частину співбесіди і допускає кандидата до наступного кроку. Навіть довгу технічну співбесіду можна розбити на 2-3 кроки по 30 хвилин: перевірка тестового завдання, усне спілкування, Live Coding тощо.

Можна ж навпаки — провести все одразу. Я дуже люблю Hiring Days, де всі етапи співбесіди втиснуто в короткий проміжок часу, зазвичай від 3 до 5 годин. Під час перерв між етапами можна випити кави зі своїми майбутніми колегами, поспілкуватися про продукт, досвід.

Вперше я спробував себе в такому форматі, коли проходив співбесіду на продукт однієї з великих українських ІТ-компаній. І на кандидата, і на наймачів тисне час, і це максимально наближає до робочих буднів (де треба встигнути все «на зараз»). Крім того, такі співбесіди чудово структуровані, від кандидата вимагають тільки тих знань, які дійсно потрібні для конкретної посади. Рішення ухвалюється максимум того ж дня, якщо ж сторони не підійшли одна одній — то одразу. За ваш витрачений час часто дають винагороду, сертифікат на якусь атракцію, курси на Udemy чи похід в ресторан :)

Більшість відкритих вакансій закривається за той один-два дні, у які проходять Hiring Days, і це супервигідно компаніям-наймачам. Важливо анонсувати таку подію за 2-4 тижні до початку, щоб отримати початкову базу кандидатів.

Попереднє спілкування з кандидатом

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

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

Коли всім все підходить, запрошують на перше очне інтерв’ю (або ж призначають відеоконференцію). Це поглиблене знайомство двох сторін, яке триває до 30 хвилин часу. Обидві сторони повинні підготуватися і ознайомитися з усією наявною інформацією (Google, CV, LinkedIn вам в допомогу), скласти список питань, які цікавлять, і відповіді на які дозволили б рухатись далі. Тут HR-спеціаліст (чи рекрутер) розповідає про компанію і продукт, на який наймають, а кандидат ділиться всією інформацією, яка відсутня в резюме.

Вже на цьому етапі кандидат може скласти перше враження про компанію, тому для компаній дуже важливий рівень рекрутерів/сорсерів/HR і те, як вони знайомлять кандидатів з майбутньою посадою і місцем роботи.

Для відсіювання, не варто починати ставити кандидату технічні питання або проводити «бліц-опитування» на тему ООП чи примітивів в TypeScript. Для цього є наступні етапи або окреме спілкування з технічним керівником.

Технічне інтерв’ю

Знайомство перед технічним інтерв’ю

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

Щоб зняти зайву напругу, люблю починати розмову з якогось смолтоку. Наприклад, якщо кандидат приїхав до вашого офісу на електросамокаті (або ж на відео в Гугл-мітс на фоні видно крутий велосипед), можна разом обговорити велоінфраструктуру міста :) Подальше спілкування проходитиме у позитивному руслі і вже не виглядатиме, як допит.

Короткий опис продукту

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

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

Технічна частина

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

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

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

Про резюме. Як інтерв’юер, обов’язково перевіряйте його, коли готуєтеся до співбесіди. Цим покажете, що вам щонайменше не байдужий співрозмовник, і вам дійсно цікаво дізнатися про його досвід. Одразу і порада для кандидатів — щоб зменшити кількість уточнюючих питань, намагайтеся у резюме описати якомога більше ваших обов’язків і досягнень, які б були корисними і на наступних посадах, перегляньте список мов, фреймворків та технологій, які знаєте — чи немає там чогось зайвого, допишіть актуальні для вас версії. Не соромтеся додавати усі сертифікації, які маєте або колись проходили, грамоти і дипломи з хакатонів, посилання на GitHub (якщо активно там щось додаєте). Якщо вважаєте цю інформацію зайвою в резюме, не забудьте розповісти про це усно.

Для кожної мови програмування, фреймворку чи технології вже давно є стандартні списки питань (навіть на DOU є така рубрика). Найімовірніше, яке б питання ви не поставили — воно там точно є, і всі кандидати вже завчили на них відповіді.

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

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

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

Live coding

На мою думку, кожна технічна співбесіда має складатися не тільки з усної, а й з письмової частини, і я маю на увазі не написання коду на аркуші, а короткий челендж (на кшталт задачок з Codewars) на 5-10 хвилин. Можна також підготувати міні-проєкт, де б кандидатам потрібно було додати функціонал, схожий з тим, що вже є чи планується на продукті. До доданого функціоналу завжди потрібно писати тести, в ідеалі — з тестів починати (TDD).

Під час Live coding ви просто і швидко дізнаєтесь про стиль написання коду, навички володіння IDE, знання синтаксису мови програмування, алгоритмів, структур даних та методів/методик, які використовує розробник під час написання коду.

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

Спілкуйтеся з кандидатом, відповідайте на запитання, коментуйте кожну дію. Нехай це буде той самий pair-programming, де ви разом вирішуєте конкретну робочу задачу.

Про тестові завдання

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

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

Де б я не використовував тестове — то це під час найму на Lead або Senior позицію. Щоб перевірити досвід такого розробника, треба більш складне та обширне завдання, на яке звісно потрібно більше часу/сил і тут (коли в Linkedin можна вибирати з-поміж кількох пропозицій) не всі готові погоджуватися на тестове завдання.

Найчастіше роботу над тестовим завданням (як і повсякденну роботу) потрібно винагороджувати. Якщо результат незадовільний — зробіть короткий code review і поділіться своїм відгуком/порадами з кандидатом.

Про PET-проєкти

Якщо ж у кандидата є свої PET-проєкти (навіть якщо це Junior, і це відносно свіжі лабораторки/курсові з програмування або числових обчислень) і стек співпадає чи схожий з тим, що використовується на вашому проєкті — їх теж можна використати на співбесіді як альтернативний варіант до тестового завдання.

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

Якщо PET-проєкт — це працюючий продукт, можна додатково поспілкуватися і про це: який досвід було використано для того, щоб запустити, які нові знання було отримано, як продукт допомагає користувачам.

Спілкування з замовником

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

Цей етап часто містить елементи «Culture fit», тут дізнаються цінності кандидата, і те, чи збігаються вони з цінностями компанії.

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

Feedback обох сторін

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

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

Висновок і поради

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

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

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

Насамкінець підсумую і залишу декілька порад для кандидатів:

• Оновіть своє резюме, опишіть свій досвід, приберіть все зайве і пункти, на які б ви не могли відповісти під час інтерв’ю.
• Дізнайтеся деталі про компанію і продукт до того, як почнете спілкування. Це можe бути Linkedin, сам сайт компанії, сторінка в соцмережах, статті про компанію в онлайн-виданнях, відгуки (навіть на «всім відомому ресурсі»). Інформацію про міжнародні компанії, стартапи чи робочі продукти можна знайти на ресурсах на кшталт Glassdoor.com. Якщо серед ваших друзів є ті, хто працював чи працює в компанії, запитайте про їхній досвід, що їм подобається і не подобається в компанії, як вони туди потрапили.
• Через хвилювання ви можете забути поставити якесь запитання, тому підготуйте їх окремо і поверніться до них наприкінці співбесіди.
• Попрактикуйтеся відповідати на прості питання щодо мов та інструментів, які ви знаєте (в мережі є багато платформ для перевірки знань).
• Попрактикуйтеся в навичках з програмування, розвʼязуйте алгоритмічні задачки на codewars.com чи leetcode.com. Якщо ви помітили, що вам тяжко даються деякі алгоритми чи структури даних — саме час підтягнути ці знання.
• Запитуйте і уточнюйте всі незрозумілі моменти. Ви виглядатимете не як студент, якому щось незрозуміло, а як спеціаліст, який збирає інформацію і поглиблено цікавиться темою.
• Завжди давайте ґрунтовну відповідь, покликаючись на те, як це працює, і як краще використовувати на практиці.
• Будьте чесними. Обманюючи на співбесіді, ви витрачаєте не тільки свій час, а й час інших людей. Якщо таким чином ви і пройдете співбесіду, то ймовірно не пройдете випробувальний період.
• Якщо чогось не знаєте, не соромтесь це визнавати. Ви можете знайти відповідь разом з інтервʼюером.
• Уявляйте, що ви вже працюєте у цій компанії. Спілкуйтеся з працівниками компанії, як зі своїми колегами.

Також з власного досвіду можу дати кілька порад інтервʼюерам:

• Підготуйте кандидата до співбесіди. Поділіться з ним інформацією про всі етапи, які знання перевірятимуть, і хто буде присутнім.
• Ознайомтесь з резюме кандидата заздалегідь і виокреміть ті моменти, які вам, як майбутньому керівнику, було б цікаво дізнатися. Спілкуйтеся тільки про той досвід, який буде корисним на вакантній посаді.
• Починайте з легших питань і піднімайте складність по ситуації.
• Не питайте в Junior-розробників, що зашифровано в абревіатурі SOLID, і що це означає.
• Якщо кандидату складно відповідати, підштовхуйте його до правильної відповіді уточнюючими запитаннями, або разом розмірковуйте про можливі рішення.
• Підготуйте кілька завдань для Live Coding, щоб дати конкретне вже за результатом усної частини технічної співбесіди. Завдання мають бути близькими до тих, що зустрічаються у вас на проєкті, і часу на їх виконання має бути не більше 20-30 хвилин.
• Під час співбесіди звертайте увагу на неточні відповіді кандидата. В кінці ви зможете дати feedback та поділитися своїми порадами для поглиблення знань.