Блог

Як на співбесіді перевіряють навички програмування: готуємося до технічного інтерв'ю

Як правило, щоб оцінити рівень знань та навичок, розробникам на одному з етапів співбесіди дають тестове завдання — написати код. Однак інколи достатньо розмови з технічним експертом. Як лише «‎зі слів» можуть визначити ваші сильні та слабкі сторони в роботі з кодом — дізнайтеся в статті. Ці поради також стануть у пригоді кандидатам на вакансії в NIX.

Чому процес співбесіди важливіший, ніж результат тестового

Зазвичай тестове виконують вдома і надсилають на перевірку технічним експертам. Але чи дійсно кандидат писав цей код самостійно? Може, йому допоміг друг-розробник чи ChatGPT? У розмові з кандидатом буде помітно, якщо він працював не сам, у відповідях людина «‎плаватиме». А той же штучний інтелект подекуди пише код, який потім не працює. Розробнику все одно доведеться вручну перевірити його та виправити помилки. Наскільки це справді була самостійна робота, достеменно ми не дізнаємося.

Можна вдатися до live coding під час співбесіди. Але, на мою думку, це теж не найкращий спосіб оцінити навички. Уявіть ситуацію: ви прийшли на співбесіду, очевидно, що хвилюєтеся, можуть думки й слова плутатись, а тут від вас ще й вимагають написати код. При цьому незнайомі люди дивитимуться, як ви це робите. Стрес та й годі, і в такій атмосфері скласти повноцінне уявлення про кандидата доволі складно. Ба більше: навіть досвідченому розробнику буває некомфортно шерити екран, і це може вплинути на результат роботи не найкращим чином.

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

Як оцінити код без тестового завдання

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

При знайомстві з репозиторієм я звертаю увагу на такі моменти:

  • Мови програмування. Добре, коли є проєкти на різних мовах, бо це показує,  наскільки розробник занурений у програмування. Володіння кількома мовами програмування — поширена практика серед девелоперів, бо вони кайфують від цього, їм подобається процес написання коду. До того ж кожна нова мова — це ще одна зона росту.
  • Оформлення. Завжди цікаво, як оформлено не лише код, а й проєкт в цілому. Значення має все: від наявності тестів до README-файлу та коментарів у коді.
  • Чистота коду. Логічність і читабельність передусім, адже з кодом працюватимуть й інші розробники. «‎Простирадло» на тисячу рядків відразу хочеться закрити — це вже мінус кандидату. А от коли в коді простежується структура, все по файлах, методи підписані, зрозуміло, що і як працює, значить, кандидат із досвідом та піклується про якість свого коду.
  • Коментарі. Якісний код не потребує пояснень, та бувають неочевидні моменти, наприклад, робота зі складними структурами даних. У такому разі коментарі підсвітять нюанси: як працює функціонал, як формується масив тощо. З одного боку, це дає розуміння, чому робота з елементами побудована саме таким чином. З іншого боку,  допоможе новачкам на проєкті та й автору кода впродовж роботи. Буває так, що за кілька місяців вже й сам забуваєш, чому так усе побудував. Для мене ж наявність коментарів показує: кандидат розуміє, що це місце в коді складне, і враховуючи можливі питання колег, зважає на необхідність уточнень.
  • Кодстайл. Я звертаю увагу на рекомендовані кодстайли, вони є для всього: і для CMS на кшталт WordPress або Magento, і для окремих фреймворків по типу React та Laravel. В їхній документації вказано, як оформлювати код. Дотримання вимог при написанні будь-яких розширень для системи спрощує командну роботу. Якщо розробник дотримується певного кодстайлу, це знову ж таки показник високого рівня знань.

Що підтверджує практичні знання девелопера

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

Виділю найбільш значущі для мене напрямки розмови:

  • Загально про досвід розробки. Наприклад, можу запитати, чим кандидат пишається у своїй кар’єрі, а потім уточнити, які труднощі виникали на цих етапах роботи й що допомогло з ними впоратися. Як ти зробив цю фічу? Чому саме так? Чому не обрав інше, аналогічне рішення? Як обійшов обмеження? Відповіді показують, як людина загалом розуміє програмування.
  • Маркери за профілем роботи. Розпитувати про рідкісні технології можна, але це дає доволі обмеженні знання про досвід кандидата. Я більше про те, що мають знати 90% розробників, якщо вони самі розбиралися в технології, а не на пару з ChatGPT. У кожній системі є «болячки». Наприклад, в документації може бути не деталізовано відмінності в завантаженні одного продукту та колекції продуктів, на прикладі Magento. Є декілька методів із різними показниками продуктивності залежно від умови завдання. Тож можна спитати, як би кандидат виконав такий функціонал, а головне — чому саме так. Якщо людина розбиралася з цим функціоналом, то має знати про уповільнення системи за певних обставин та способи розв’язання цієї проблеми.
  • Високорівневі питання. Починаю з простого, але якщо розробник впевнено відповідає про розробку окремих фіч, підвищую складність питань. Намагаюся побачити, наскільки кандидат розуміє систему в комплексі: як вона працює, як її використовувати. Поцікавлюся, як він реалізує функціонал на рівні архітектури, планування, інтеграцій, інструментів тощо.

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

Що ще має значення

  • Стиль розмови. Звертаю увагу, як саме людина пояснює свої ідеї, дії. Особливо цікаво, коли кандидат не знає відповіді, але готовий розмірковувати, накидати варіанти рішень уголос. Важливі логічність, послідовність, уміння застосовувати доречну термінологію.
  • Софт скіли. Ввічливість у розмові — ясна річ. Важливі й реакції на питання, на які кандидат не знає відповіді. Я можу підказати і дивитимуся, як далі співрозмовник дійде до правильного рішення або ні, таке теж буває. В такому разі це показує здатність визнавати пробіли в знаннях і водночас демонструє готовність до навчання. Нестачу досвіду можна покрити на практиці. Я ж оцінюю потенціал до розвитку.
  • Чи слідкує кандидат за сучасними технологіями. Інколи в обговоренні девелопер може посилатися на дослідження або статті, які читав по темі, це дуже хороший знак. Особливо, якщо звучать актуальні приклади, які я ще не зустрічав. За таке завжди подякую.
  • Креативність. Часом кандидат може запропонувати щось краще, ніж я собі мислив. Це похвально, тому я з радістю обговорю, як людина бачить реалізацію своєї ідеї. З роками звикаєш працювати за одним шаблоном, з перевіреними рішеннями, а коли хтось ділиться, як краще можна втілити те ж саме, але з новою бібліотекою чи за допомогою маловідомого фреймворку, і таким чином виграти в часі — обов’язково візьму це собі на замітку. Кандидату така відкритість однозначно додає плюсів.
  • Відповідність проєкту. Коли шукаємо розробника на конкретний проєкт, очікуємо від нього певних знань, але для досвідчених фахівців це здебільшого не критично. Якщо проєкт побудований на CMS, деякі особливості реалізації системи можна опанувати в процесі роботи. Відсутність специфічних знань можна відносно легко компенсувати загальним рівнем підготовки.
  • Знання бізнес-домена. Розуміння галузі, в якій створюється продукт, важливе, але я б не переоцінював цей аспект. Специфіка бізнесу криється в окремих процесах, десь просто достатньо більше тестування. Тож я скоріше поцікавлюся, наскільки кандидат вправний у написанні тестів до свого коду. Специфічні теми, як-от особливості безпеки в HealthCare проєктах, можна вивчити протягом роботи.

Індивідуальний підхід передусім

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

Якщо кандидат має хороші напрацювання, але на інтерв’ю відповідає слабко, це привід зосередитися на спілкуванні. Спершу пробіжимося по репозиторію. Кандидат не здатен щось розбірно пояснити? Це майже завжди означає: код чужий. Якщо ж теорією володіє добре, код дійсно написано самостійно, але не дуже якісно, дізнаюся про причини обраних рішень. Не бачу проблеми в тому, що в кандидата є дрібні недоліки в коді. Все можна «‎відшліфувати» на практиці, під час випробувального терміну. Головне — бачити свої проблемні місця та бути готовим до роботи над собою.