Большинство кандидатов этого не спрашивают: 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 будет без микроменеджмента и сюрпризов после оффера!