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

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт! Мене звуть Роман, і я Senior Android Engineer в Ajax Systems. Певен, що ви, як і я, помічали недостатній рівень експертизи у проведенні технічних співбесід для мобільних розробників по ринку. Часто це зумовлено тим, що інтерв’юери отримують вказівку зверху провести технічну співбесіду з мінімальною підготовкою, що безпосередньо впливає на імідж компанії та якість найманих таким чином кадрів.

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

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

Вчимося плавати → пишемо нормальну вакансію

Нам потрібно зрозуміти, якого кандидата ми шукаємо. Припустимо, вам потрібно найняти Middle Android-розробника. Почніть з ознайомлення з проєктом, на який відкрита позиція — це допоможе вам скласти список необхідних кваліфікацій.

Для прикладу, розглянемо умовний проєкт в першій-ліпшій компанії.

• Проєкт спершу був написаний на Java, але нові функції вже додають на Kotlin.
• UI архітектурний патерн — MVVM.
• Тестів мало, але потроху пишуться на JUnit4.
• Бібліотека для ін’єкції залежностей — Dagger 2.
• UI написаний на Android View, але нові фічі пишуться на Jetpack Compose.
• Локального кешування практично нема, тому використовуються лише SharedPreferences.
• Асинхронність забезпечує RxJava i Kotlin Coroutines.
• Система контролю версій — Git.
• Reteno для пуш-нотифікацій.
• Firebase для аналітики.

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

• Kotlin, Java, Android Studio;
• знання компонентів архітектури Android Architecture Components:
• знання чистої архітектури, принципів SOLID і шаблонів проєктування, таких як MVVM, MVI, MVP, MVC;
• Android View, Jetpack Compose;
• JUnit 5;
• бібліотека для ін’єкції залежностей Dagger 2;
• досвід асинхронного програмування (Coroutines);
• глибокі знання система контролю версій (GIT);
• Firebase, Reteno;
• Fragment Manager;
• Local Storage: Room, Realm, Shared Pref.

Kotlin, Java, Android Studio. З приводу Java, Kotlin — все ок, а от вказувати Android Studio не бачу сенсу, адже ніхто вже не пише в Eclipse Android-застосунки.

Знання компонентів архітектури Android Architecture Components — насправді, вони не потрібні, коли у вас використовується лише ViewModel.

Знання чистої архітектури, принципів SOLID і шаблонів проєктування, таких як MVVM, MVI, MVP, MVC — тут вказані зайві патерни проєктування, а саме MVI, MVP, MVC.

Android View, Jetpack Compose — все ок:)

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

JUnit 5 — оскільки тестів мало і пишуться вони на JUnit 4, цю вимогу замінимо на загальний досвід юніт-тестування.

Досвід асинхронного програмування (Coroutines) — тут бажано вказати й RxJava, щоб це не стало неприємним сюрпризом для кандидата.

Система контролю версій (GIT) — це база, це фундамент, можна не вказувати, якщо ви не робите octopus merge (ви не робите).

Firebase, Reteno — це прості інструменти, на яких не варто наголошувати.

Fragment Manager — це теж база, не вказуємо.

Local Storage: Room, Realm, Shared Pref — тут знову забагато, Room i Realm не використовуються, а Shared Pref це база, тому це можна не вказувати.

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

Технічний стек, необхідний для реалізації задач:

• Kotlin, Java;
• ViewModel;
• знання чистої архітектури, принципів SOLID і шаблонів проєктування, таких як MVVM;
• Android View, Jetpack Compose;
• досвід асинхронного програмування з Coroutines та RxJava.

Буде плюсом:

• бібліотека для ін’єкції залежностей Dagger 2.

Таким чином ми вказуємо кандидату на необхідні знання без зайвої «води».

Виходимо з води → налаштовуємо процес раннього відсіву кандидатів

Часто у вас бувало таке, що кандидат добре пройшов співбесіду з рекрутером, має непогане резюме, але на технічній співбесіді за 10 хвилин вже зрозуміло, що він не підходить? У мене досить часто. Тому, щоб вберегти себе і команду від витрати зайвого часу, я проводжу технічний прескринінг на 30-40 хвилин для першого знайомства з кандидатом.

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

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

Я проводжу прескринінг приблизно так:

• 5-10 хвилин на знайомство та питання щодо досвіду кандидата;
• 10-15 хвилин важливих технічних питань;
• 10-15 хвилин на розповідь про проєкт, обов’язки, очікування та відповіді на питання від кандидата.

Будуємо ракету → перевіряємо, як кандидати розв’язує прикладні задачі

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

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

Тестове завдання може бути різне, ось кілька моїх варіантів:

1. Маленька фіча з вашого проєкту, наприклад: дістати щось з бекенду і показати на екрані зі збереженням архітектури, тестабельності коду. Це може займати як дві години, так і два тижні. Я прихильник цінування особистого часу кандидата, тому не люблю тестові завдання, довші за дві години.
2. Синтетичне завдання на годинку, наприклад: реалізація компонента за інтерфейсом і покриття його тестами. Просто, швидко та ефективно.
3. Бонусний варіант для кандидатів, які хочуть зекономити свій час — лайвкодинг. Це може бути будь-що, головне, щоб займало 30-45 хвилин, не більше. Нам головне побачити, як кандидат пише код і як мислить. Хочу застерегти вас від вибору проходити лайвкодинг на співбесіді без ґрунтовної підготовки, бо, як показує мій досвід, писати адекватний код під наглядом дуже важко і стресово, що веде до банальних помилок і зазвичай до провалу цього етапу.

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

Намагаємося літати → складаємо план технічної співбесіди

Дуже часто я бачив співбесіди, що були складені з 20 питань про Android з першого-ліпшого посилання в гуглі. Чи може бути така співбесіда показовою? Питання риторичне.

Після усіх етапів відбору нарешті час провести технічну співбесіду і тепер ваша черга готуватися.

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

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

Та найголовніше — не запізнюйтеся!

План стандартної співбесіди:

1. Знайомство — 5-10 хвилин.
2. Питання для «розігріву» — 15-20 хвилин.
3. Творча частина — 45-60 хвилин.
4. Алгоритми та структури даних — 5-10 хвилин.
5. Питання від кандидата — 5-10 хвилин.
6. Обмін враженнями з командою.

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

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

Секція «розігріву» складається з простих базових питань про основні технології: у випадку співбесіди Android-розробника це будуть питання по Kotlin, Java і, власне, Андроїду. Типові питання: модель пам’яті у JVM, відмінності Kotlin i Java та що таке Context в Андроїді.

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

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

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

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

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

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

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

Далі порівнюйте кандидатів між собою та обирайте найкращого.

Висновки

Підсумуймо основні поради:

1. Не вимагайте від кандидата знання, які не потрібні на проєкті.
2. Економте свій час і кандидата — проведіть прескринінг, щоб зрозуміти, чи технічна співбесіда взагалі потрібна, чи ні;
3. Не купуйте кота в мішку — впевніться, що кандидат вміє писати адекватний код на етапі лайвкодингу або тестовому завданні;
4. Не ставте питання з гугла, відповіді на які можна завчити, пройшовши кілька співбесід в інші компанії. Натомість хай це будуть питання, які показують прикладний досвід, а не кількість пройдених співбесід.

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

Залишу посилання на подкаст зі мною, де можна дізнатися більше про те, як я наймаю розробників в команду:
ASP-88: Про найм людей та співбесіди з гостем Roman Shtykalo
ASP-89: Частина 2 про найм людей та співбесіди з гостем Roman Shtykalo