Більшість кандидатів цього не запитують: 8 запитань майбутньому тімліду

Дивитись детальніше

Більшість людей готуються до співбесіди в один бік: вчать відповіді, повторюють проєкти, готуються пояснити gap у резюме. І приходять підготовленими — але лише для того, щоб сподобатися. А потім виходять на роботу і за два тижні з’ясовують, що тімлід мікроменеджить кожну задачу, команда давно демотивована, а «цікаві технічні виклики» з вакансії — це легасі-моноліт 2014 року, який ніхто не хоче чіпати.

Співбесіда — це офіційний привід ставити незручні запитання та отримувати чесні відповіді. Та часто кандидати витрачають цей час на формальності і йдуть із інформацією, яка нічого не додає про тімліда та команду.

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

Що запитувати на співбесіді: безпечні запитання vs ті, що мають сенс

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

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

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

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

Запитання про очікування до ролі

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

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

#1. Що не вийшло в попередньої людини на цій позиції / Чому роль відкрита?

Це запитання, яке варто ставити завжди, але формулювати як щирий інтерес до контексту. Можлвио, людина виросла й пішла вище, перейшла в іншу компанію, не впоралася, роль нова. Кожен варіант розповідає щось про компанію. 

Поширена ситуація в IT: роль нова, але насправді це розділена надвоє позиція. Це може бути маркером зрілості, адже команда масштабується та розділяє фокусом. А може бути і red flag: можливо, людина була і техлідом, і product ownerʼом, і ментором для трьох джунів одночасно, а нова роль успадкує той самий контекст.

#2. Як виглядають успішні перші 3–6 місяці на цій позиції?

У багатьох компаніях випробувальний термін формально є, але фактично ніхто не визначив, які маркери успіху. У результаті оцінка стає субʼєктивною: людина може добре виконувати роботу, але не відповідати неозвученим очікуванням по перформансу чи soft skills.

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

Дивитись детальніше

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

Ще один тривожний сигнал — якщо очікування звучать нереалістично для короткого терміну. Наприклад: «За перші 2–3 місяці людина має повністю взяти на себе ключову частину системи» — без згадки про підтримку або час на навчання.

Запитання про команду та внутрішню динаміку

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

#3. Як у вас зазвичай відбувається комунікація в команді, якщо комусь щось не ок по процесу або навантаженню? 

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

В IT це особливо важливо, бо розробники рідко скаржаться прямо. Вони просто починають активніше відповідати рекрутерам у LinkedIn. 

#4. Розкажіть про когось із команди, хто вас здивував у хорошому сенсі.

Нестандартне запитання, яке розповідає відразу кілька речей. Перше — чи може менеджер говорити про тіммейтів з конкретикою й теплом: це означає, що він бачить у них не «ресурс», а людей і помічає внесок. Друге — що саме він вважає «приємним сюрпризом» (технічне рішення, ініціативу чи поведінку в кризі). Це покаже, що він цінує.

Дивитись детальніше

#5. Що у роботі з людьми для вас як менеджера є складним або викликає фрустрацію?

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

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

Запитання про таски та нюанси при виконанні

Іноді «використовуємо React» означає один застарілий проєкт без розвитку. А «працюємо з highload» — три сервери й пік у 200 одночасних користувачів. Ось запитання, які допоможуть швидко зчитати технічний контекст і зрозуміти, чи він збігається з тим, що вам цікаво.

#6. Яке технічне рішення за останній рік ви б ухвалили інакше, якби поверталися назад? Чому?

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

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

#7. Яку таску в команді зараз найменше хочеться робити і чому?

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

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

#8. Як у вас у команді розбирають інциденти та фейли?

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

Зріла відповідь може звучати так: «Кілька місяців тому в нас був інцидент у продакшені. Провели post-mortem, з’ясували, що проблема у відсутності алерта на конкретний сценарій, і додали моніторинг та додаткові перевірки в CI».

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

Тривожна відповідь звучить інакше. У ній акцент зміщується на конкретну людину:

Дивитись детальніше

Це сигнал, що в команді, ймовірно, немає безпечного середовища для помилок. Є ще один нюанс: як тімлід розповідає про інцидент — «ми» чи «він/вона». «Ми пропустили», «ми не врахували», «ми зробили висновки» — мова спільної відповідальності. «Він зламав», «вона не перевірила» — мова дистанціювання.

Наостанок: зрілі команди спокійно говорять про складнощі. Бо це норма. Якщо за 40 хвилин не прозвучало жодної проблеми, справа не в ідеальності.

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

Нехай ваша dream job буде без мікроменеджменту й сюрпризів після оферу!