Март 23

Технічна співбесіда на Java-розробника: питання і поради щодо підготовки

[Про автора: Зеновій Верес — керівник освітнього напрямку Lviv IT Cluster, Solution Architect в компанії SoftServe, асистент кафедри комп’ютеризованих систем автоматики у Львівській політехніці]

За останні 10 років я провів понад 300 технічних інтерв’ю Java-фахівців — як Intermid, Senior рівнів, так і TechLead/Architect. Існує багато коментарів як кандидатів, які пишуть про неадекватні запитання, так і інтерв’юерів, які нарікають на недостатній рівень кваліфікації спеціалістів.

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

Цілі інтерв’ю та підхід

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

Очевидно, що зробити об’єктивну оцінку рівня знань надзвичайно складно за короткий проміжок часу — як правило, технічне інтерв’ю триває близько години, іноді — півтори. Саме тому я готуюсь до інтерв’ю заздалегідь, спершу перечитую резюме та профіль кандидата (Candidate Profile), який він сам заповнює, оцінюючи свій рівень знань (knowledge area) та володіння технологіями. Перший блок співбесіди традиційно ознайомчий — я зазвичай задаю декілька вступних запитань, щоб познайомитися та розрядити атмосферу.

Досвід роботи

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

Запитання

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

Зважаючи на те, що я прихильник практичних завдань, то дуже часто описую певну задачу і прошу кандидата розказати, як би він її вирішив. Приклад такої задачі для архітектора/технічного лідера: для описаного вами проекту, яким чином ви б забезпечили підтримку додаткових 5000 користувачів одночасно; яким чином ви б організували заливання 1000 записів у базу даних з використанням Spring/JPA і т. п.

Відштовхуючись від отриманої інформації, я переходжу до запитань по об’єктно-орієнтованому дизайну. Я очікую, що людина із рівнем Intermid і вище знає, для чого слід використовувати шаблони проектування (GoF/GRASP/SOLID/Layered Arcitecture). Від кандидатів Senior-рівня я очікую розуміння, коли і котрий з шаблонів слід застосовувати, а також як виконувати рефакторинг коду із використанням шаблонів (рекомендую книгу Д. Кірієвскі «Рефакторинг з використанням шаблонів»). А також ситуації, коли використання шаблону може мати негативний вплив або бути невиправданим. Також до базового набору я відношу запитання по SQL/DB Design, програмного доступу до бази даних (DB Access), що включає в себе знання JPA/Hibernate. Звісно, від кандидата також очікується і знання мови програмування Java та змін, які були внесені у Java SE 8/9 s Java EE 8 (Jakarta EE). Зауважу, що на даний момент менше уваги приділяється багатопоточності, адже наявність багатьох фреймворків ізолює розробника від потреби створювати та керувати новими потоками.

У випадку наявності досвіду по Spring обов’язково задаю низку питань — перш за все, з якими компонентами цього фреймворка працював кандидат. А також запитання по REST/SOAP сервісах.

А тепер найцікавіше — які саме запитання слід очікувати на інтерв’ю? Я зазвичай починаю зі складніших запитань, але якщо кандидату вони виявляються заскладні, то поступово переходжу до простіших. Для економії часу читачів не буду наводити список стандартних запитань (чому слід перевизначати equals та hashCode, яким чином інтерфейси дозволяють реалізовувати інкапсуляцію та ін.) — по кожній із зазначених вище сфер є достатньо запитань в інтернеті. Зупинюся більше на запитаннях, пов’язаних з архітектурою, та запитаннях «з родзинкою».

Про архітектуру:

Опишіть архітектуру проекту — яким чином ви її документували, як вносили зміни, що було причиною внесення змін? Назвіть основні якісні характеристики (quality attributes) системи — яким чином ви їх досягли, чому для системи важливі саме ці атрибути, які у вас є обмеження, які припущення ви зробили при проектуванні системи? Рекомендую почитати книгу Len Bass «Software Architecture in Practice», 3rd Edition.
Які фактори вплинули на вибір фреймворків для проекту, які були альтернативи, що було основним фактором відхилити альтернативи? Яким проблеми виникали при виконанні запитів до бази даних, як ви їх вирішували? Як реалізовували REST-сервіси, яку бібліотеку обрали, як реалізовували HATEOAS-принцип?
Яку версію Java використовували на проекті? Що для вас є найважливішим у версії Java SE 8/9? Що входить в Java EE, яким чином відбувається реліз Java EE (Jakarta EE)? Що саме з Java EE ви використовували? Чи стикалися ви з out of memory error? Якщо так, то як саме вирішували та відслідковували використання ресурсів? Чи стикалися з memory leak? Якщо так — як шукали причину, як організовували роботу з пам’яттю?

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

Каверзні запитання

Іноді я відходжу від стандартної канви і ставлю запитання зовсім іншого характеру. Роблю це не для того, щоб підловити, а щоб зрозуміти хід думок кандидата. Трапляються випадки, коли людина завчила запитання суто по Java і навіть не хоче подумати, хоча відповідь може бути дуже простенькою. Наприклад, запитання по типах колекцій є достатньо стандартними. А ось запитання на кшталт «при яких операціях відбувається економія часу, коли ми працюємо з HashMap та за рахунок чого відбувається така економія; які операції при цьому відбуваються повільніше, у порівнянні з ArrayList» показує, наскільки кандидат розуміє принципи роботи даної колекції. Крім того, така методика зазвичай використовується саме для того, щоб подивитися, як людина відреагує на такі запитання. Інколи «правильна відповідь» не найважливіше, що ми хочемо почути. Такі завдання дозволяють нам побачити ваші soft skills, глибину мислення та підхід до вирішення непростих завдань.

Поради

Найголовніша порада — будьте чесними, починаючи з резюме. В ньому варто чесно відобразити технології та фреймворки, з якими працювали саме ви, а не які в цілому використовувалися на проекті. Пам’ятайте, що на початку інтерв’ю кожен кандидат має 100% довіри — з кожною невідповідністю цей кредит падає і з кожним разом все швидше.
Відображайте в резюме всі проекти, над якими працювали, навіть якщо їх багато. Це дозволить побачити всю картинку розвитку вас як фахівця. Також це дає уявлення, чи неперервний досвід ви мали, чи були перерви, з якими технологіями стикалася.
Чесно розкажіть про ваше особисте ставлення до проекту — подобався\не подобався, чому зупинилися саме на таких технологіях, чи були виклики і як з ними справлялися, яка була взаємодія команди в таких випадках, як приймали рішення. Це дозволить зрозуміти, наскільки ви були залучені до проекту та жили ним, а також який ви командний гравець.
Ставте запитання. Переконайтеся, що перед тим, як почнете відповідати чи розв’язувати задачу, ви правильно її розумієте. Не варто часто просити повторити запитання. Якщо хочете дізнатися більше про проект, команду чи компанію — запитуйте. Відсутність запитань може означати, що ви не зацікавлені в компанії чи позиції, на яку проходите співбесіду.
Зробіть домашнє завдання. Під час інтерв’ю з рекрутером вам надають первинну інформацію про проект — не соромтеся розпитувати та просити трохи більше деталей. Це дозволить вам зрозуміти специфіку проекту та краще підготуватися до технічної співбесіди — освіжити теоретичні знання, заглянути в код, зрозуміти, яка інформація з вашого резюме може бути найактуальнішою.
Заспокойтеся та не нервуйте. Співбесіди — це стресова ситуація для будь-кого. Можливо, ви подалися на позицію, на яку дещо не вистачає кваліфікації, чи навпаки — здається, що в описі вакансії йдеться саме про вас. В будь-якому випадку ви хвилюєтесь. Важко розкрити всі свої переваги, коли нервуєшся. Тому заспокойтеся, підготуйтеся та розкрийте свої сильні сторони.
Погугліть перед інтерв’ю. На інтерв’ю задають достатньо стандартні запитання, до яких можна і потрібно підготуватися.
Запишіть запитання, на які ви не знали відповіді під час співбесіди або незадоволені своєю відповіддю. Потім пошукайте відповіді для себе — це дозволить вам розвиватися.
Завжди просіть надати інтерв’юера відгук про інтерв’ю — які у вас виявлені сильні сторони, а над чим слід попрацювати.