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

Усі статті, обговорення, новини про 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

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
це потенційний червоний прапорець для кандидата

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

Я б може й погодився з вами десь у 2021 році, але зараз ринок праці диктує протилежні умови.

У нас є «зачароване коло»:
Ринок на стороні роботодавця (наприклад коли людина ще джун) — роботодавець пробує прогнути кандидата. Кандидат/працівник узагальнює це як «всі роботодавці — мудаки».
Ринок на стороні кандидата, і як же кандидат буде відноситись до роботодавців? В 2021 був у мене кандидат, що дуже посереднє продемонстрував себе на технічній співбесіді, але люди треба, то вирішили робити офер. Офер таки не зробили, бо чувак сказав (дослівна цитата):
ну поуговарівайтє мєня.

Нормально перевірити серверсайд спеца можна за 1-2 години, мобайл буде можна за 1-1.5 лекго. Про тестові можете почитати тут dou.ua/...​signment-for-job-seekers (стаття ще з доковідних часів)

мобайл буде можна за 1-1.5 лекго

комусь легко, комусь — ні)

dou.ua/...​signment-for-job-seekers (стаття ще з доковідних часів)

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

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

Мдяаа.
Пріоритети у вас супер:
1) Відсіяти досвідчених спеців і погіршити імідж контори — це не проблема.
2) Відсіяти людей, що готові «по-приколу» витратити 1-2 години свого часу, при цьому даючи вам можливість розвиватись як інтерв’юер — це нагальна проблема, що потребує вирішення, ціною пункту 1!
Відкрию вам секрет:
Якщо людина прийшла на співбесіду навіть по приколу і пройшла її — це вже потенційне посилення команди. Далі питання чи готова компанія щось запропонувати людині, яка вже перевірено підходить на позицію.

Пріоритет в тому, щоб використовувати наявні ресурси, серед яких мало особистого часу і купа бренду компанії. Якщо співбесіда в «роги і копита» має тестове, то дійсно можна зменшити до 0 воронку кандидатів. Чи тестове може вплинути на імідж моєї теперішньої компанії, про яку знають більшість людей і поза ІТ сферою? Питання риторичне) Як і усіх інших питаннях, все залежить від контексту і одного правильного рішення бути не може.

Чи тестове може вплинути на імідж моєї теперішньої компанії, про яку знають більшість людей і поза ІТ сферою?

1) А ви знаєте який імідж у Аджакс в професійних колах? Пошукайте на доу теми та коментарі :)
2) Знову аргументація з позиції сили/сатусу і оцінка свого часу ціннішого за час майбутнього колеги

Якщо співбесіда в «роги і копита» має тестове, то дійсно можна зменшити до 0 воронку кандидатів.

Питання не в об’ємі «воронки», а в тому кого вона відсіює

Відсіяти досвідчених спеців
1) А ви знаєте який імідж у Аджакс в професійних колах? Пошукайте на доу теми та коментарі :)

Haters gonna hate:) Людей, які хочуть тут працювати вистачає, щоб обирати серед найбільш вмотивованих.

2) Знову аргументація з позиції сили/сатусу і оцінка свого часу ціннішого за час майбутнього колеги

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

Питання не в об’ємі «воронки», а в тому кого вона відсіює

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

Знову ж таки, я повністю згоден з вашими понітами у вашому контексті, але не усі вони мають сенс в моєму контектсі.

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

А що бізнес думає про ретеншн? :)

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

А по резюме «розробник Android із багатим досвідом у галузі» цього зробити не може?
Але фактично ми прийшли до того з чого вам варто було почати статтю:
Ваші поради корисні для відсіву потому на ентрілевер вакансії. Це важливий контекст, бо він чітко вказує вузьку смугу застосування підходу.

А по резюме «розробник Android із багатим досвідом у галузі» цього зробити не може?

Без оцінки коду на лайвкодинку або тестовому? Ні.

Ваші поради корисні для відсіву потому на ентрілевер вакансії.

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

Без оцінки коду на лайвкодинку або тестовому? Ні.

То варто трохи набратись багатого досвіду :). Або скоріше подумати над вже існуючим
А ще можна порефлексувати над тим фактом, що «якість коду» при лайфкодінгу і в реальному проекті буде відрізнятись. Лайфкодінг, тестове і ... вейт фор іт ... випробувальний термін — це 3 різних інструменти, що перевіряють дуже різні якості людини.

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

Дуже дивно, що людина, що має досвід «сотні проведених інтерв’ю в компаніях різного типу» не навчилась задавати питання «по теорії», які дозволяють таких людей відсікати. Чомусь я таких навчився випасати десь на 2-3 десятку співбесід.
Але тут скоріше за все різниця в визначеннях поняття «погано».
Що ви туди вкладаєте?

То варто трохи набратись багатого досвіду :)

«Батя, я стараюсь» :)

А ще можна порефлексувати над тим фактом, що «якість коду» при лайфкодінгу і в реальному проекті буде відрізнятись.

100%, тому я вказую кандидатові, що хочу від коду:
1) Щоб працював:)
2) Тестабіліті;
3) Правильний напрямок залежностей (clean architecture, словом);
4) Розуміння того, як працює Kotlin/Java, Android і обрані бібліотеки. Шукаю в коді типові помилки в роботі з ними.

вейт фор іт ... випробувальний термін

Тут повністю згоден, але це вже навряд по темі.

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

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

Але тут скоріше за все різниця в визначеннях поняття «погано».
Що ви туди вкладаєте?

Відповідно відсутність попередніх факторів.

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

Тобто чуваків, які по-приколу ходять на співбесіду треба відсіяти, а от чувака, що «професійно проходить співбесіди» десь піврочку поговнокодить у вас на проекті ми відсіювати не плануємо :)

Тут повністю згоден, але це вже навряд по темі.

Так само як і попередні 2, які ви чомусь проігнорували в цитуванні.
Про тестове проблеми описані вище.
А от про лайфкодінг, то він перевіряє не якість коду людини, а вміння комунікувати :)

UPD

1) Щоб працював:)

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

Тобто чуваків, які по-приколу ходять на співбесіду треба відсіяти, а от чувака, що «професійно проходить співбесіди» десь піврочку поговнокодить у вас на проекті ми відсіювати не плануємо :)

Для цього є trial period.

А от про лайфкодінг, то він перевіряє не якість коду людини, а вміння комунікувати :)

+

Оця вимога при лайфкодінгу суттєво додає помилок при відборі.

теж +, все попереднє було про тестові завдання. На лайвкодингу критерії оцінювання мають бути радикально спрощені. Ну і я на лайвкодинг ніколи не даю щось складніше ніж  fun isAnagram(first: String, second: String): Boolean , де є безліч варіантів вирішення, але якщо кандидат не може зробити хоч би перебором, то мені такого колеги не треба.

Цікаві поради про співбесіди від 23 річного сеньйору, всього два роки як отримав вищу освіту а вже вчить як кого обирати

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

Ой дякую, зберіг собі на майбутнє)

Хороший структурований підхід, дякую за статтю.

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

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

Підписатись на коментарі