Технічне інтерв’ю — традиційний етап співбесіди на роль девелопера. Щоб перевірити хард-скіли, кандидата можуть попросити написати код, наприклад, невеликого модуля. Який би формат вам не запропонували — live coding під час співбесіди чи «домашка» з подальшим обговоренням — в обох випадках експерти звертають увагу на одні й ті самі речі.
Давайте розберемось, що допоможе отримати позитивний відгук за результатами тестового.
Навіщо потрібне тестове завдання для розробника
Передусім, щоби перевірити рівень практичних навичок. Часом кандидат добре володіє теорією, та, можливо, він загалом начитаний або ж нагуглив і вивчив відповіді на класичні запитання техекспертів. Однак теоретична та практична підготовка можуть разюче відрізнятися. Тоді не залишається нічого іншого, як дати кандидату тестове завдання.
Але й тестове — не «чарівна паличка», його можна «підробити»: знайти відповідь в інтернеті, залучити ChatGPT або попросити знайомого досвідченого розробника написати код за тебе. Відрізнити підробку неможливо. Звісно, експерт може попросити кандидата пройтися по кожному файлу, аби він розповів, що і як працює, як він писав ті чи інші кроки, але і це можна завчити з доступних в інтернеті відповідей. Для повноцінної перевірки навичок зазвичай дається випробувальний термін. Саме в робочих умовах якнайкраще вдасться оцінити знання фахівця і заодно софт-скіли.
Критерії оцінки тестового завдання
- Чи взагалі є рішення?
Чи вирішує код поставлену задачу? Адже функції, які ми хотіли отримати, повинні бути реалізовані та правильно працювати. Це основний критерій оцінки. Питання конкретної імплементації та способу розв’язування завдання — це вже наступні кроки.
- Якість коду
Код має бути чистим, зрозумілим, із дотриманням стандартів програмування та найкращих практик від компаній на кшталт Google. Інколи в коді трапляються складні моменти, і доводиться вдаватися до декомпозиції логіки. У такому разі доречно використати коментарі до обраних рішень. Коменти покажуть, наскільки вправно ви можете застосувати теорію на практиці. Коментуйте стисло, по суті, вважайте це допоміжними аргументами на користь свого рішення.
- Чи відповідають уміння кандидата необхідному рівню розробки
Спосіб розв’язання завдання й імплементації коду має відповідати професійному рівню програмної інженерії конкретного спеціаліста. Можна щось реалізувати примітивним способом, і це теж працюватиме. Але якщо це рішення не буде неоптимізоване чи йтиме в розріз з актуальними best practices — великі шанси, що тестове не оцінять високо. Тобто фахівець може мати чималий досвід роботи в ІТ, але весь цей час суттєво не прогресувати, не вивчати нові підходи й не намагається їх адаптувати на практиці.
- Оптимальність коду
Цей показник навряд чи коректно застосовувати до Junior-розробників, але для досвідчених він точно важливий. Тут експерт перевіряє, наскільки ефективно виконано завдання з погляду продуктивності.
Продуктивним є код, який найоптимальніше підібраний під конкретне рішення. Такий код читабельний, а швидкість його виконання позитивно впливає на всю систему. Не обов’язково прагнути до супершвидкого виконання коду. Зазвичай важко підібрати такий код, що водночас буде зрозумілий команді та виконуватиметься на максимальній швидкості. Краще взяти «золоту» середину: швидкість, прийнятну для подальшої підтримки коду, і таку, що відповідатиме вимогам бізнесу.
Непродуктивним вважається код, який має базове рішення і може негативно впливати не тільки на логіку або безпосередньо на рішення, але й на інші частини програми.
З погляду оптимальності, що можна покращити в коді? Як правило, це стосується певних алгоритмів, структури даних тощо. Оптимальність коду залежить від суті завдання, адже буває, це не першочергова потреба чи вона немає сенсу у вказаному випадку.
- Креативність
Для спеціалістів рівня Middle та Senior вимога цілком очікувана. Технічний експерт може поцікавитись, як кандидат, скажімо, вийшов за межі завдання, чи запропонував цікаві ідеї, чи оригінально імплементував завдання. Це, звісно, додає плюсів на співбесіді, але креативність не замінить оцінку правильності рішення, як і чистоту коду.
- Використання нових технологій
Додаткова перевага для всіх кандидатів. Приємно бачити, коли фахівець слідкує за розвитком галузі й у типових завданнях знаходить застосування новим бібліотекам чи плагінам. А якщо кандидат ще й може пояснити переваги такого рішення, то взагалі супер. Наприклад, почитав статтю, де порівнювали продуктивність різних бібліотек, і саме обрана ним бібліотека в цьому випадку виявилась кращою, і от, чому.
- Покриття коду тестами
Важливим чинником є наявність тестів, зокрема Unit-тестів (хоча плюсом будуть і E2E-тести). Зазвичай вимога стосується комплексних задач. Експерти дивляться, чи покривають тести основну функціональність написаного коду, чи не забув девелопер про винятки за певних обставин. Написання тестів показує, чи здатен спеціаліст перевірити якість свого коду, чи вміє працювати над помилками. Адже похибки періодично бувають у всіх: як у джунів, так і в сеньйорів.
- Архітектура та дизайн
Йдеться не просто про написання коду, а й про можливості його масштабування. На це варто зважати фахівцям рівня Strong Middle та вище. Продумайте подальші архітектурні підходи, структуру проєкту, організацію даних тощо. Слідуйте принципам SOLID та DRY. Все в купі дозволяє побачити експерту, наскільки фахівець думає про стабільність усього проєкту.
- Документація коду
Якщо розглядати тестове як мініпроєкт, дуже вітається опис коду. Документування показує розуміння етапів розробки. В реальній роботі пояснення та коментарі допомагають іншим розробникам швидко і зручно налаштувати та запустити проєкт. Помічними тут будуть і добре задокументована інструкція запуску застосунку, й опис різних середовищ цього застосунку. Як запустити ті чи інші команди, та й в взагалі, які команди передбачені в програмі, за що вони відповідають — це все додає зручності у командній роботі над проєктом. Тож коли девелопер думає не тільки про якість свого коду, але й про його використання іншими девелоперами, це схвально оцінить і техексперт.
Що НЕ критично при оцінці тестового завдання
- Використані технології
Коли клієнт шукає розробника на проєкт із конкретними технологіями, звісно, очевидна вимога глибоко розбиратися в них. Та якщо такої умови немає, використання в тестовому технології суттєво не впливають на фінал співбесіди. Головне — володіти базою, що і дозволить за потреби вивчити будь-яку додаткову технологію. Експерти ж оцінюватимуть загальний рівень мислення. Якщо ви здатні збагнути логіку простих рішень, то зрозумієте і щось складніше.
- Знання бізнес-домена
У роботі девелопер має орієнтуватись на визнані в тому чи іншому домені стандарти. Наприклад, GDPR та HIPPA у HealthCare-проєктах. Але для виконання тестового цього не потрібно. Як правило, даються абстрактні завдання, це загальна практика в ІТ. В більшості команд, особливо в аутсорсі, потрібні універсальні розробники. Інколи замовники називають бажаний досвід та рівень знань для кандидатів, але якщо ці критерії специфічні, їх можна обговорити з командою та переглянути. Це вже внутрішні процеси на проєкті.
- Кодстайл
На етапі перевірки тестового немає значення певне оформлення коду. Добре, коли він просто є, та зрозумілий. Єдиний виняток — пошук розробника на конкретний проєкт. Тоді в команді вже склався свій кодстайл, і новому учаснику було б добре слідувати визначеним критеріям. Експерти зазвичай повідомляють про це під час знайомства з кандидатом, щоби людина розуміла, до чого готуватися.
- Коли продуктивність коду ставиться вище за все інше
Усе в коді має бути збалансованим. Часом мені потрапляють тестові, де все зроблено правильно, але код — не дуже лаконічний, складний для розуміння, і, як на мене, це проблема. Нехай код даватиме більший перфоманс, та він не має викликати зайвих питань у колег. Можна зробити код не таким швидким в обробці, як хотілося б, але читабельнішим. Хоча для оцінки загального рівня знань це зазвичай не критично. Достатньо пояснити кандидату, що саме не так в його коді, і поділитися відповідною документацією. На практиці все завжди можна «відшліфувати».
- Чи взагалі є рішення?
Як не парадоксально, але в деяких випадках цей критерій не є визначальним. Розв’язання важливе, і для досвідчених фахівців це не обговорюється. Та іноді відсутність рішення можна… пробачити. Наприклад, джун ще не знає певних технологій, але натомість проявив у тестовому нестандартний підхід. Пішов у правильному напрямку, затестив різні способи розв’язання задачі, лаконічно й читабельно все оформив. Для техексперта це привід замислитися: певно, у цього початківця хороший потенціал. Можна довго шукати «ідеального кандидата» під всі зазначені у вакансії вимоги. Але в реальності розробникам частіше бракує певних знань. І тоді повертаємося до оцінки способу мислення: хто розуміє логіку і суть завдання, той здатен подужати будь-що нове.
Часом, і досвідчений розробник може припуститися «джуновської» помилки, з ким не буває. Але якщо це стає системною проблемою і не дозволяє спеціалісту проявити себе як експерта вищого рівня, навряд чи з ним продовжать співпрацю.
В цілому ж, на мій погляд, кожному кандидату варто дати шанс, навіть якщо в тестовому не все ідеально. Саме команда може допомогти початківцю чи середньому фахівцю розвиватися в робочих тасках і зростати в обраному ІТ-напрямі.
Кандидатам раджу бути активними: показуйте експертам бажання вчитися, якщо пробіли в знаннях справді є, будьте готові розібратися в нових, складних для вас темах. Цей запал та мотивація важливі не менш ніж хард-скіли, і в багатьох ситуаціях можуть допомогти отримати бажану роль у команді.