Як провести співбесіду з розробником

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

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

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

Попередній досвід інтерв’ю

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

Також були спроби робити тестові завдання і просити кандидатів вирішити їх до інтерв’ю. Були також варіанти, коли я кандидату під час співбесіди давав лист з задачками по ключовим особливостям javascript і дивився як він відповідає.

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

Отже підсумки моїх попередніх потуг — знання теорії і вміння відповідати на питання на справді не так важливо, як це здавалося. Набагато важливіше:

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

Крутий виходить список. І яке ж таке задати питання, щоб перевірити наявність цих компетенцій?

Що робити, якщо людина не виправдала сподівання?

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

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

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

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

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

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

Поточне бачення процесу співбесіди

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

Тим не менш хочу поділитися тим алгоритмом який наразі працює для мене.

Вакансія

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

В вакансії треба заповнити наступні розділи:

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

Перегляд резюме

На етапі перегляду резюме слід звернути увагу:

• які бібліотеки/технології/мови використовував кандидат. Чим саме він займався на кожному місці роботи. Це в купі дасть можливість оцінити наскільки серйозні завдання в нього були (але це не точно).
• скільки всього років працює кандидат? Скільки часу пройшло після закінчення університету і яка там була спеціальність? Якщо між початком роботи і універом пройшло багато часу, то тут питання “чому?“.
• чи були великі перерви між змінами роботи? Якщо перерви були, то це має насторожити. Може кандидат не дуже надійний і не впевнений в обраній професії.
• скільки місяців затримувався кандидат на кожному місці роботи? Чи були періоди, коли кандидат працював параллельно на декількох роботах? Якщо кандидат працював по 1-2 місяці на одному місці, це прям дуже стрьомно. Пів року ще більш-менш, але в ідеалі від одного року. За коротший період людина не встигне навіть розібратись з проектом, тому на новий досвід особливо розраховувати не варто.

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

Спосіб пофіксити криві резюме

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

Наприклад, кандидат вказав такий великий список технологій, що це викликає сумніви. І тут питання: це він написав стек проекту чи він дійсно працював з GraphQL? А під “працював” мається на увазі розгортання бекенду і вирішення купи проблем при використанні цієї технології? Або написання окремих простих запитів чи взагалі бездумне копіювання готового запиту з таски в код фронтенда?

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

Щоб не ламати голову над такими філософськими питаннями, можна зробити декілька простих питань і попросити рекрутера задавати їх кожному кандидату. Наприклад, ось такі:

• якщо на github є цікаві проекти. Можна посилання на конкретний проект і супер короткий опис, що цікавого в тому проекті (можна навіть посилання на найцікавіший файл)?
• по яким технологіям з CV ви відчуваєте, що готові відповідати на питання і маєте досвід більше ніж мінімальний (можете розказати про плюси/мінуси і як взагалі працює технологія/ліба)?
• чи зможете ви відповісти на питання що таке event bubbling і навіщо це потрібно?

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

Підготовка питань на співбесіду

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

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

Отже, натхнення щодо питань для співбесіди можна брати з наступних джерел:

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

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

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

Окремо хочу наголосити: не треба питати про теми, з якими кандидату не доведеться працювати. Замикання це, звісно, крута тема, але, в сучасному js де існують const і let, без її розуміння можна жити. Співбесіда дуже коротка і краще витратити час на щось більш практичне.

Структура співбесіди

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

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

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

Під час співбесіди треба контролювати час і вчасно переходити до наступної групи запитань.

Слід враховувати, що на співбесіді є вступ і завершальна частина. Отже на активну бесіду залишається щось типу 40хв. Відповідно слід розраховувати на 3-4 групи питань приблизно по 10хв кожна.

Документ для обліку результатів співбесід

Перед початком циклу співбесід є сенс підготувати гугл табличку в якій буде колонка з іменем кандидата, посиланням на деталі кандидата, а далі необхідна кількість колонок для оцінювання компетенцій, наприклад: react, mobx, css modules, perf optimization, soft skills.

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

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

В якості оцінок я використовую “0” або “1”. Інколи можу написати “0.5”. Крім того я виставляю ”-” у випадку, якщо взагалі не вистачило часу на питання по темі.

Чим менша градація оцінок, тим легше потім порівнювати. Якщо ви плануєте в кінці просто взяти людину у якої максимальна сума балів, то тоді можна хоч в 100 бальній системі оцінювати. У випадку ж якщо рішення вибирається аналізуючи, то порівняти 0 і 1 значно легше ніж 42 та 53.

Приклад підготовки до співбесіди

В попередніх розділах були викладені усі думки на тему. Тепер спробую розібрати описаний підхід на прикладі реального кейсу.

Вакансія на Junior/middle Frontend Developer

Вимоги до кандидата:

• 2,5+ роки комерційного досвіду інженера-програміста.
• Досвід роботи з JavaScript, React, React router. Досвід роботи з бібліотеками UI (Antd, Material UI, Semantic UI та іншими).
• Досвід роботи з MobX або Redux.
• Впевнені знання CSS.
• Добре розуміння асинхронної логіки та методів перетворення/нормалізації даних (Array.map, Array.reduce, Set, Map, групування, індексування, та інших).
• Досвід роботи з Git.

Буде плюсом:

• Досвід роботи з TypeScript, Webpack, WebSockets.

Стек наших проектів:

• React
• React router
• MobX
• AntD
• SCSS, css modules
• axios
• WebSocket

Ваші завдання:

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

Питання

Я одразу розбив питання на декілька груп.

Знайомство

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

• що робив на минулій роботі? Яка таска найбільше запам’яталась?
• чому пішов з минулого місця?
• що шукаєш на новому місці?

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

Що мені треба від кандидата?

Є такі великі хотілки (місцями на перспективу, бо ми ж шукаємо junior/middle):

• кандидат повинен вміти самостійно навчатись.
• проявляти ініціативу і пропонувати технічні вдосконалення проекту.
• вміти аналізувати проблеми (баги) і знаходити їх причини.

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

• чи пишеш ти код в вільний від роботи час? Якщо б в тебе був час, який застосунок ти б розробив? (пет проекти це гарне джерело нового досвіду, а також дає надію, що людина буде проявляти ініціативу)
• як ти вчився програмувати? Де наразі дізнаєшся нову інформацію?
• уяви, що ти перший день на проекті, не знаєш де що знаходиться і тобі приходить завдання виправити багу через яку замість відображення попапа, в консоль прилітає Uncaught promise rejection. Які є способи знайти проблемний файл на проекті? (було б круто, якщо б кандидат згадав про використання дебагера)
• який твій алгоритм дій, якщо прийде баг репорт, що у певної частини користувачів не завантажується частина сайта, але при цьому ніхто не знає як це відтворити?

Теоретичні питання (Hard skills)

Загалом сюди можна набрати питання знайдені в гуглі. Деякі питання можна перефразувати у питання на розмірковування.

Наприклад замість питання “що таке event bubbling?” можна задати задачку типу “як заімплементити закриття попапу за кліком по підложці, якщо попап рендериться всередині div підложки?” (тут челендж якраз в тому, що клік по самому попапу не повинен проходити на підложку, а для цього треба використовувати, наприклад, stopPropagation).

• Що таке event bubbling? (мега просте запитання, але чомусь далеко не всі, хто називають себе фронтендами, можуть на нього відповісти)
• Що таке область видимості?
• Чому говорять, що об’єкт передається в функцію за посиланням? Що це означає?
• Чи гарантується, що setTimeout виповниться чітко через вказаний проміжок часу? (це питання плавно переходить до розмови про event loop)
• Навіщо потрібні Promise? Що буде, якщо в промісі виникне помилка?
• Питання по git. Який флоу був в попередніх компаніях? Як редагувати коміт (amend)? Що таке merge, rebase, cherry-pick?

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

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

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

Другий момент пов’язаний з нашим проектом — це необхідність рендерити настільки довгі списки, що ця проблема може вирішитись лише через віртуалізацію (react-window etc).

• як би ти вирішив наступне завдання? Бекенд передає тобі список об’єктів у кожного з яких є поле group. Тобі треба розбити ці об’єкти на окремі списки під кожне значення group (а ля таби). При цьому тобі невідомо які саме будуть назви груп. (ідеальне рішення, якщо кандидат запропонує як це зробити за один обхід вихідного масиву).
• Як оптимізувати рендеринг довгих списків? (чи знає кандидат про віртуалізацію списків і чи зможе вигадати схожий підхід, якщо йому допомогти?).

Колонки для таблиці оцінювання

Тут все просто. У нас вже є текст вакансії та перелік питань, тому можемо сформувати колонки для таблиці:

• React
• React router
• State management
• MobX
• AntD
• SCSS
• css modules
• axios
• typescript
• WebSocket
• event bubbling
• setTimeout
• data grouping
• list optimization
• git

Я зробив по колонці для кожного пункту стека. Окрім MobX додав окрему колонку чи працював кандидат хоча б з якоюсь лібою для зберігання стейту (Redux). Також додав по колонці для деяких ключових питань.

Структура співбесіди

В розділі “Питання” в нас сформувалось 4 групи. Пропоную до них и прив’язатись. Якраз по 10хв на кожну группу і по 10хв на вступ і завершення співбесіди. При цьому треба розуміти, що розділ з питаннями з реального досвіду проекту, може забрати дуже багато часу, тому є сенс не дуже розтягувати розділи, що залишились.

Висновки

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

Питання мають змушувати кандидата пофантазувати над вирішенням певної задачі або порівнянням плюсів і мінусів різних підходів. Суха відповідь на питання по теорії з підручника не дасть об’єктивно оцінити навички кандидата.

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

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