Рецепт адекватної співбесіди, або Викиньте у смітник свої запитання

Привіт, я Вова. В android-розробці 6-й рік. За цей час провів кілька десятків співбесід та пре-скрінів, як і до себе в команду, так і в паралельні команди в компанії, допомагаю людям шукати їхніх перших android-розробників. Але пишу я цю статтю зараз не тому, що сам раніше проводив погані співбесіди, а тому що зрозумів, що на ринку найму України багато компаній проводять технічну співбесіду, після якої не хочеться йти до них працювати. І цим текстом я хочу підняти рівень співбесід в Україні. Приклади будуть з android-світу, але загальні рекомендації будуть без прив’язки до спеціалізації.

Для кого ця стаття

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

Всі не мають рації, а я Д’артаньян, який вам все розкаже

Усі матеріали, які є щодо співбесід для android-розробників в Інтернеті, це повна фігня. Це звучить доволі жорстоко, але так і є, причому англомовний Інтернет не є виключенням. Усі статті, які я бачив, — це просто список питань, на які кандидат має вивчити відповіді. Причому багато з цих питань явно відстали від індустрії на роки, ви потрапите на них виключно тому, що в Google ці посилання мають велику «вагу». Моя рекомендація — припиніть питати людей по списку, питайте тільки те, що потрібно вашій команді, приділіть багато часу system design (якщо це треба вашій команді).

Наприклад, стандартне запитання в усіх списках — це життєвий цикл activity/fragment. Останній рік я працюю в команді, яка не використовує ні fragment, ні activity, тому я не буду нічого запитувати в кандидата з цієї теми. Звичайно, більшість android-розробників знає життєві цикли, але якщо команда, в яку йде кандидат, не використовує фрагменти/актівіті — ці знання не мають значення.

Встановіть правила гри

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

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

На початку співбесіди варто озвучити кандидату «правила» співбесіди, для прикладу:

1. В нас не можна казати: «Тому що так правильно».
2. В нас не можна апелювати до авторитетів.
3. В нас кожну свою думку треба підтверджувати аргументами.
4. Аргументом може бути особистий досвід кандидата на попередніх проєктах.
5. Нам важливо, що ти думаєш, а не те, що думають автори якихось статей чи книг.

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

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

Не питайте теорію

В теперішньому проєкті є багато роботи з потоками і синхронізацією даних між потоками. Та ми дійшли висновку, що ніяких питань з теорії synchronized, mutex ми ставити не будемо. Ми просто ставимо перед кандидатом задачі, які вирішуємо щодня, і питаємо, як би він їх вирішував. З цього ми вже розуміємо, чи знає кандидат, як працювати з потоками. Що ж робити, якщо в вашому проєкті немає обробки даних на різних потоках, а запитати про race condition хочеться? Відповідь тут тільки одна: стримуйте своє «хочеться».

Не питайте те, що не потрібно

Не треба питати те, що у вас не використовується, це стосується і ширини, і глибини питань. Для прикладу: нормально запитати кандидата про TextView та форматування тексту, якщо це використовується в проєкті, але немає ніякого сенсу питати деталі імплементації RTL, якщо проєкт його не підтримує. Може бути винятком, коли кандидат — цікава людина, і вам просто цікаво порушити тему глибше. Я все кажу кандидату прямим текстом: «Ми це не використовуємо, мені просто цікаво, що ти думаєш на тему...», і далі порушуємо цікаві питання щодо теми.

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

Ви не FAANG

Звісно, рівнятися на кращих — це правильно, але не треба їх копіювати. Це виглядає, наче діти на YouTube граються в телевізор. Тільки компанія з тисячею девелоперів грається в Google. Перестаньте робити інтерв’ю, як у Netflix. Зрозумійте одну просту річ: Facebook бере людей з тих, хто хоче в Facebook, а ви — з тих, хто залишився на ринку. Вхідна воронка цих компаній дозволяє їм поставити практично будь-які умови на вхід. Тому викидаємо питання про червоно-чорні дерева, якщо вони у вас не використовуються.

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

Ще один великий мінус — ставити запитання про алгоритми. До вас може прийти людина, яка займається олімпіадним програмуванням, і, скоріш за все, сильніша за вас у цій темі. І резюме вас від цього не захистить, я, наприклад, ніде не вказую, що брав участь в АСМ-ІСРС, просто тому, що це немає ніякого стосунку до роботи.

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

Візьміть з собою друга

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

Об’єктивність оцінювання. Я вважаю, що для того, щоб взяти кандидата, треба, щоб він сподобався обом.

Форс-мажор. Це може бути все, що завгодно, починаючи від того, що вас підключать на розбір інцидентам на проді, закінчуючи тим, що у вас просто вимкнеться інтернет.

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

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

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

Питання від кандидата

Тут наче все просто. Але є один момент: просто дати можливість поставити кандидату запитання — це не те, що треба. Тому що кандидат не Ванга і не знає, як написаний ваш проєкт. Тут краще коротко переказати ReadMe проєкту.

Мій приклад

Наша команда пише продукт, який називається SportsBook. Команда розробляє бібліотеку, яку інша команда інтегрує в додаток. Бібліотека включає як UI, так і усю роботу з даними і бізнес-логіку продукту. Для socket використовуємо OkHttp, для rest — retrofit, dependency injection пишемо руками, ViewModel, там, де UI на compose, використовуємо гуглові, там, де старі view, використовуємо самописні, вони такі ж, але дозволяється працювати з view як з самостійним елементом.

В нас є своя кодогенерація, тому що в нас свій формат спілкування з back-end і, відповідно, самописні бібліотеки для серіалізації даних. Для dataflow раніше використовувалося самописне рішення, схоже на RxJava, зараз в процесі переходу на Flow. Для збору використовуємо Gradle. Стек для тестів — juint 5 та mockk.

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

Рецепт

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

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

2. Задача. Я просто описую дуже спрощену версію продукту та NFR (в нашому випадку — швидкість доставки інформації і економія трафіку) і прошу кандидата описати, як він бачить розробку цього продукту. Спочатку — в загальному плані, потім переходимо до деталей реалізації UI та роботи з даними. Тут важливий момент, що в нашій задачі немає бізнес-логіки, не треба думати, що кандидат буде знати ваш домен. В моментах, де ми знаємо, які проблеми виникнуть, ми питаємо кандидата, як би він їх вирішив. Тут ми і дізнаємось, чи вміє кандидат вирішувати проблеми race condition, і при цьому ми не ставимо питання в лоб: «Що так mutex?», тому що мені мало того, що кандидат знає, що таке mutex, я хочу, щоб він сам сказав, що його тут треба використати.

3. Переказуємо ReadMe проєкт. І відповідаємо на запитання кандидата.

Короткі висновки

Перше і найголовніше, робіть тільки те, що треба, пишіть у вакансії тільки те, що треба, запитуйте тільки те, що треба. Звісно, будьте привітні і постарайтесь передбачити форс-мажор. І майте план «Б». Звісно, мені як автору буде приємно почути ваші рекомендації, як провести ідеальну співбесіду, і відгуки про співбесіди, в яких ви були кандидатом.

Посилання:

Обговорення теми співбесід в подкасті Android Story

Тред в Twitter про кількість людей на співбесіді