Найм tech lead: проверяйте суждение, компромиссы и спокойствие команды
Научитесь нанимать tech lead: проверяйте суждения, компромиссы и умение успокаивать команду с помощью практических вопросов, сценариев и быстрых проверок.

Почему количество тикетов не показывает сути
Подсчёт тикетов кажется аккуратным, потому что даёт число. Работа tech lead редко бывает аккуратной. Большую часть времени лидер принимает решения при частичных данных, реальных дедлайнах и компромиссах, которые никому не нравятся.
Именно поэтому сырая продуктивность — плохой фильтр. Кто-то может закрыть двадцать тикетов и при этом оставить команду с путаными передачами, шаткой архитектурой и багами, которые вернутся через два спринта. Скорость важна, но скорость без суждения обычно создаёт переработки для всех остальных.
Tech lead также работает на другом уровне, чем сильный индивидуальный исполнитель. Они решают, когда держать объём маленьким, когда добиваться чище исправления и когда принять некрасивый, но безопасный патч, потому что бизнес ждать не может. Ничто из этого не видно в простом отчёте по тикетам.
Самую большую разницу вы увидите в тяжёлые недели. Релиз падает в продакшене, а отдел продаж ждёт обещанной функции. Один лидер продолжает кодить и добавляет шума. Другой замедляет комнату, называет реальный риск, назначает ответственных и сокращает план до того, что команда может безопасно выкатить. Команды помнят такого человека месяцами.
Если вы хотите нанять tech lead, смотрите дальше личной продуктивности и спрашивайте, что происходило вокруг их результатов. Их решения снижали стресс или его распространяли? Помогли ли они другим инженерам работать быстрее на следующей неделе, а не просто закрыть больше задач сегодня? Остановили ли они плохое решение, когда у никого не было полной информации?
Хорошие лидеры пишут код. Но код — лишь часть работы. Тяжёлая часть — выбирать хорошо в условиях неопределённости, защищать команду от избегаемой текучки и приносить спокойствие, когда комната начинает крутиться.
Как выглядит хорошее суждение tech lead
Сильный tech lead не начинает с любимого инструмента или быстрого ответа. Они начинают с цели, реальных ограничений и людей, которые будут жить с результатом каждый день. Это обычно значит, что они спрашивают про дедлайны, стоимость отказов, размер команды, слабые места в текущей системе и кто будет поддерживать работу после запуска.
При найме обратите внимание, может ли кандидат сказать "не сейчас" без колебаний. Хорошее суждение часто видно в том, от чего они отказываются строить прямо сейчас. Они сознательно урезают объём, защищают график и оставляют место для обучения прежде, чем команда возьмётся за более крупный дизайн.
Они также ясно называют риски. Сильный ответ может звучать так: "Если мы сейчас добавим второй сервис, релизы станут медленнее, дежурство сложнее, и у команды появится больше подвижных частей для управления. Я бы оставил всё в одном сервисе, пока трафик или структура команды не дадут реальную причину разделить."
Другой хороший признак — обратимость. Вдумчивые лидеры предпочитают шаги, которые команда может отменить, если узнает что-то новое. Они используют фич-флаги, небольшие выкаты, узкие изменения интерфейсов и короткие эксперименты вместо больших переписок. Это не делает их пассивными. Это делает их трудными для того, чтобы поймать на одном необратимом ставке.
Суждение также имеет человеческую сторону. Надёжный tech lead защищает мораль, одновременно требуя ясности. Под давлением они понижают температуру, отделяют факты от догадок и дают команде простой план на несколько следующих часов. Они не скрывают проблемы и не сеют панику.
Простой пример делает это очевидным. Допустим, после релиза выросли времена ответа. Слабый лидер сразу кидается править и заглушает остальных. Сильный — спрашивает, что изменилось, что чувствуют клиенты первым, безопасен ли откат и кто отвечает за коммуникацию, пока команда расследует. Это спокойный, упорядоченный ответ — частый самый явный знак реального суждения.
Постройте интервью вокруг реальных решений
Абстрактные вопросы дают слабые интервью. Если вы хотите нанять tech lead, используйте решение, с которым ваша команда действительно сталкивалась в последние месяцы. Выберите что-то достаточно запутанное, чтобы заставить проявиться суждение, а не тривиальность.
Хороший пример — релиз, который сорвался, потому что одна зависимость постоянно падала, в команде было две разные идеи фикса, а продукт всё ещё хотел исходную дату. Это звучит обычно — и в этом смысл. Настоящая работа редко выглядит аккуратно в процессе найма.
Дайте кандидату короткий бриф, а не полный специфик. Включите цель, несколько фактов и намеренно оставьте пробелы. Не давайте всех деталей, чтобы увидеть, заметят ли они, чего не хватает.
Перед ответом попросите перечислить вопросы, которые они зададут в первую очередь. Сильные кандидаты обычно замедляются здесь. Они спрашивают, кто заблокирован, сколько пользователей испытывают проблему, что на самом деле значит дедлайн, кто владеет рискованной частью и что произойдёт, если команда выкатит меньший фикс сейчас.
Затем ужмите ограничения. Урежьте бюджет. Морозьте найм. Скажите, что один старший инженер будет отсутствовать две недели. Сдвиньте дедлайн ближе или скажите, что дата неподвижна, потому что от неё зависит другая команда. Смотрите, адаптируют ли они свой план спокойно и практично.
Вам не нужен самый умный с виду дизайн. Вам важнее, как они сортируют проблему. Защищают ли они команду от паники? Меняют ли они объём ради безопасности? Знают ли, когда собирать больше фактов, а когда решать?
Завершите одним простым вопросом: что бы вы сделали на первой неделе? Это переводит разговор из теории в практику. Хорошие ответы чаще всего включают общение с людьми, которые ближе всего к проблеме, проверку того, что ломается в реальном использовании, установку короткого окна для принятия решения и обеспечение того, что команда знает, что пока не будет сделано.
Эта последняя часть важнее, чем многие думают. Лидер, который может уменьшить шум, сузить выбор и принять ясное решение, помогает больше, чем тот, кто просто даёт быстрый ответ.
Вопросы, которые выявляют системное мышление
Сильный лидер редко начинает с кода. Они начинают с карты системы простыми словами: пользователи, сервисы, хранилища данных, очереди, внешние поставщики, точки отказа и передачи между ними. Спросите: "Прежде чем что-то менять, что бы вы сначала отрисовали?" Если они сразу прыгают к фреймворку или переписке, считайте это предупреждением.
Затем давите на хрупкость. Спросите: "Какие сигналы заставили бы вас сказать, что система хрупкая?" Хорошие кандидаты говорят о медленных деплоях, неясной ответственности, ручных починках, шумных алертах, общих таблицах, скрытых повторных попытках и изменениях, которые ломают несвязанные области. Они должны называть сигналы, которые видели раньше, а не расплывчатые слова про сложность.
Скрытая связанность часто отделяет лидера от сильного индивидуального исполнителя. Спросите: "Где вы бы ожидали, что невинное изменение может привести к повреждению в другом месте?" Слушайте ответы про аутентификацию, биллинг, общие схемы данных, фоновые джобы, кеширование, права доступа и всё, что касается нескольких команд без заметного контроля. Самые сильные ответы звучат осторожно, а не драматично.
Командное мышление тоже важно. Спросите, как они разделили бы работу, если бы её нужно было выпустить двум или трём людям. Хороший ответ показывает последовательность, а не равные куски. Один человек может сначала ужесточить логи и тесты, другой изменить API, третий заниматься выкатыванием и откатом. Вы хотите того, кто уменьшает столкновения и оставляет место для обучения в процессе работы.
Наконец, спросите, что они будут наблюдать после запуска. Сильные лидеры упомянут небольшой набор сигналов: уровень ошибок, задержки, глубину очереди, успешность задач, обращения в поддержку и чёткий триггер отката. Многие хорошие кандидаты добавляют деталь, которую другие пропускают: кто будет смотреть эти числа и как долго.
Ответы должны звучать обоснованно. Ищите грубые карты, вероятные точки отказа и план для людей, а не только для кода. Эти детали скажут вам гораздо больше, чем отшлифованный рассказ о количестве закрытых тикетов.
Вопросы, которые показывают чувству компромиссов
Если вы хотите нанять tech lead, спрашивайте о выборах, которые слегка неудобны. Любой может сказать, что ему важны качество, скорость и здоровье команды. Полезный сигнал появляется тогда, когда эти цели тянут в разные стороны и кандидат вынужден выбирать.
Хороший вопрос меняет давление посреди ответа. Дайте нормальный план, затем сократите дедлайн. Спросите: "Мы думали, что у нас шесть недель. Теперь три. Что вы сначала урезаете, а что защищаете?" Сильные лидеры не отвечают лозунгами. Они называют, что отбрасывают, что сохраняют и почему.
Сравнение скорость против полировки — ещё один чистый тест. Поместите их в реальный контекст: внутренний админ-инструмент, публичная форма регистрации, изменение биллинга или миграция с данными клиентов. Тогда спросите, где они допустят шероховатости, а где притормозят. Если они относятся ко всем проектам одинаково, это тревожный знак. Хорошее суждение меняется в зависимости от риска.
Короткие фиксы против долгих исправлений показывают, как они думают дальше этой недели. Попробуйте кейс: сервис падает каждую пятницу под нагрузкой, поддержка устала, а у команды неделя до релиза. Спросите, что они запатчат сейчас, а что запланируют позже. Слушайте два момента. Во-первых, уменьшают ли они боль быстро? Во-вторых, оставляют ли ясный путь, чтобы убрать патч позже?
Некоторые риски заслуживают твёрдого «нет». Попросите назвать, что они отказались бы выпустить даже под давлением основателя. Хорошие ответы обычно включают бесшумную потерю данных, дыры в безопасности, непроверенные изменения биллинга, нарушённый контроль доступа и миграции, которые нельзя откатить.
Затем спросите, как они объяснили бы жёсткий компромисс основателю, который хочет всего и сразу. Лучшие ответы используют простой язык: что команда получает, что теряет, что может сломаться и кто должен владеть решением. Спокойный лидер умеет сказать «нет», не нагнетая обстановку.
Как они успокаивают команду под давлением
Давление быстро раскрывает привычки. Интервью должно показать, понижают ли они температуру или раздувают её. Хороший tech lead не успокаивает команду мотивационной речью. Они делают проблему меньше, назначают владельцев и держат всех, опирающихся на одни и те же факты.
Попросите рассказать одну историю из напряжённой недели релиза. Не принимайте отшлифованное резюме. Спросите, что сломалось, кто подключился к созвону, что они сказали первыми и что изменилось в плане в тот день. Люди, которые это переживали, помнят детали. Они могли заморозить рискованные мерджи, урезать объём, назначить одного владельца на каждую открытую проблему или перейти на обновления каждые 30 минут.
Потом спросите про конфликт между двумя сильными инженерами. Давление редко выглядит как чисто техническая проблема. Чаще оно превращается во фрикцию между людьми, которые оба считают, что защищают продукт. Устойчивый лидер выслушивает обе стороны, называет решение, которое нужно принять, и закрывает петлю. Если кандидат только говорит о «выравнивании», продолжайте допытываться.
Спросите, что они говорят, когда план сдвигается. Лучшие ответы просты и конкретны: "Мы опаздываем по этой части. Мы всё ещё можем выкатить безопасную версию к пятнице, если уберём эти два пункта. Я подтвержу новый объём до 14:00." Такой ответ успокаивает комнату, потому что заменяет тревогу на следующий шаг.
Паника свыше — ещё один хороший тест. Спросите, что они делают, когда основатель, руководитель или клиент начинает требовать почасовых изменений. Сильные кандидаты защищают команду от такого шторма. Они дают один ясный статус, предлагают два варианта и не допускают случайного нового объёма в спринт.
Слушайте конкретные действия. Хорошие лидеры сужают объём вместо обещаний большего, устанавливают ритм обновлений, назначают ответственных за каждую открытую проблему, говорят прямо при начале конфликта и не дают панике катиться вниз по иерархии. Если ответ звучит как речь о лидерстве, продолжайте копать. Успокоившие лидеры помнят, что они сделали, а не только как себя чувствовали.
Ошибки, ведущие к плохому найму
При найме tech lead самые большие ошибки обычно простые. Команды вознаграждают отшлифованные ответы, быструю речь и уверенный тон. Эти сигналы приятно звучат в комнате, но часто скрывают слабое суждение.
Лучший кандидат часто делает что-то менее эффектное. Он делает паузу, просит недостающие факты и объясняет, что проверит прежде, чем принимать решение. Ясное мышление часто звучит спокойно и немного просто.
Интервью, перегруженные тривией, дают другой промах. Кандидат может назвать инструменты, облачные продукты и детали фреймворков весь день, а затем застрять, когда реальная проблема выглядит грязно: сломанный релиз, двое инженеров с противоположными фиксями и менеджер, требующий отчёт через десять минут. Tech lead должен сортировать шум, выбирать направление и объяснять почему.
Многие панели пропускают вопросы про конфликты и давление, потому что эти темы неприятны. Это оставляет большую слепую зону. Кандидат, отлично выглядящий в дружелюбном интервью, может оказаться жёстким, расплывчатым или резким с людьми, когда дедлайны поджимают. Вам нужно услышать, как они решают разногласия, как успокаивают комнату и как держат работу в движении, когда у никого нет идеального ответа.
Уверенность тоже получает слишком много кредитов. Некоторые кандидаты отвечают на всё сразу и говорят с полной уверенностью. Это может звучать как старшинство. Часто это просто скорость. Хорошее суждение звучит иначе. Сильные лидеры говорят, что они знают, что не знают и что изменит их мнение.
Дизайн панели тоже может испортить интервью. Один сильный кодер часто доминирует в обсуждении и сводит всё к качеству кода, умным фиксам или глубине технических деталей. Эти вещи важны, но они — лишь часть работы. Если один человек контролирует комнату, вы можете никогда не узнать, как кандидат справляется с компромиссами, риском или людскими проблемами.
Простое решение помогает. Дайте каждому интервьюеру одну область для проверки и заранее запишите, как выглядит хороший ответ. Затем сравните заметки после.
Кандидат, который с уверенностью говорит "переписать", может впечатлить комнату. Безопаснее взять того, кто спрашивает про влияние на клиентов, опции отката, владение и нагрузку поддержки.
Простой сценарий для использования в интервью
Дайте кандидату одну проблему, смешивающую продуктовое давление, технический риск и командный конфликт. Хороший tech lead редко получает аккуратные выборы. У них бывает неделя вроде этой.
Используйте такой запрос:
"Ваш продукт замедляется каждое утро понедельника. Поддержка говорит, что жалоб клиентов становится больше. Отдел продаж хочет релиз через три недели. Один инженер предлагает переписать. Другой — мелкие патчи. Вы руководите следующие десять дней. Проговорите, что вы делаете."
Потом посидите тихо. Дайте им выбрать, с чего начать. Этот выбор много говорит.
Сильный кандидат обычно не бросается сразу в код. Они сначала уменьшают неясность. Они называют немедленную цель, например защитить клиентов в понедельник и понять причину замедления, прежде чем делать ставку на переписку. Они также отделяют план на десять дней от плана на три недели.
Попросите пройтись по дню за днём, но держите всё просто. Вам нужны решения, а не театральность. Спросите, что они делают в первые 24 часа, какие факты нужны перед выбором фикса, как решают спор переписать против патчей, что говорят продажам и поддержке и какой результат они хотят получить к десятому дню.
Хорошие ответы звучат спокойно. Кандидат собирает небольшой набор фактов, проверяет паттерны трафика, всплески ошибок, недавние изменения и влияние на клиентов, затем выбирает минимально рискованный ход, который может улучшить следующий понедельник. Возможно, они приостановят несущественную работу, назначат одного инженера на поиск узкого места, другого — на подготовку безопасного краткосрочного фикса, и назначат время, чтобы пересмотреть вопрос о переписке после стабилизации системы.
Это упражнение работает, потому что оно выявляет суждение. Слабый кандидат воспринимает замедление как чисто задачку кодирования. Сильный видит четыре проблемы сразу: производительность, сроки поставки, разногласия в команде и доверие клиентов.
Когда вы нанимаете tech lead, слушайте простой язык. Они должны ясно объяснять компромиссы, делать одну-две ставки и говорить, что не будут делать пока. Если они пытаются всё решить сразу, они, скорее всего, создадут шум именно тогда, когда команде нужен покой.
Быстрые проверки перед оффером
Не делайте оффер только потому, что один ответ звучал умно. Tech lead заслуживает доверия малымим шагами: вопросами, которые они задают первыми, предпосылками, которые они называют, и моментами, когда они решают замедлиться вместо догадки.
Начните с их инстинкта до решения. Если вы дали им запутанный сценарий и они сразу прыгнули к фиксу — это предупреждение. Сильные кандидаты обычно сначала задают полезные вопросы. Они хотят знать, что изменилось, кого затронуло, что не должно ломаться и сколько у команды действительно времени.
Предпосылки имеют такое же значение. Хорошие лидеры проговаривают их вслух. Они не скрывают неопределённость за уверенным языком. Если они говорят: "Я предполагаю, что аутераута затрагивает только корзину" или "я бы подтвердил, что дедлайн фиксирован", вы быстро узнаёте, как они думают и смогут ли держать команду в курсе при неполных фактах.
Смотрите, где они замедляются. Эта пауза часто — лучшая часть интервью. Зрелый лидер не воспринимает каждую проблему как гонку. Они замедляются вокруг рискованных миграций, неясной ответственности, вопросов безопасности и напряжённых межличностных ситуаций. Они умеют объяснить, почему быстрый фикс может создать большую проблему на следующей неделе.
Ещё одна важная проверка: защищают ли они доставку и доверие команды одновременно? Слабый лидер говорит так, будто быстрая доставка решает всё. Сильный держит релиз в движении, не подставляя людей, не скрывая плохих новостей и не доводя команду до выгорания.
Перед решением сравните заметки панели по короткой карточке. Задали ли они полезные вопросы перед предложением изменений? Проговорили ли предпосылки явно? Объяснили ли, где они бы приостановились и почему? Сбалансировали ли дедлайны с доверием внутри команды? И описали ли большинство интервьюеров одного и того же человека?
Последний пункт легко пропустить. Если один интервьюер увидел спокойное суждение, другой — эго, а третий — расплывчатость, остановитесь и разберите глубже. Смешанные заметки обычно означают, что сигнал недостаточно силён.
Следующие шаги, если сомневаетесь
Сомнение после сильного интервью обычно значит одно из двух: кандидат хорошо говорил, или ваша команда задала слишком открытые вопросы, вокруг которых легко импровизировать. Не откладывайте и не полагайтесь на память. Встречайтесь сразу после интервью, пока детали ещё свежи.
Попросите каждого интервьюера назвать конкретные моменты, а не общие ощущения. "Он выглядел старшим" ничего не говорит. "Он сократил объём во время сценария с отказом вместо обещания полного фикса за час" даёт вам что-то реальное для сравнения.
Запишите риски, которые всё ещё кажутся открытыми, простым языком. Умеет ли кандидат принимать решения при неполной информации? Защищает ли команду под давлением? Объясняет ли компромиссы без жаргона? Поднимет ли он проблему рано, даже если это замедлит запуск?
Если суждение всё ещё неясно, назначьте вторую узкую беседу. Один реалистичный сценарий обычно достаточен, и 30–45 минут дадут больше, чем ещё один полный цикл интервью. Дайте ситуацию с запутанными ограничениями: дата релиза, усталая команда, один нестабильный сервис и старший заинтересованный запрашивает уверенность. Спросите, что они сделают в следующие два часа, следующие два дня и что скажут команде.
Смотрите, как они думают, а не сколько говорят. Хорошие ответы обычно включают несколько спокойных ходов: уменьшить объём, защитить дежурного инженера, назначить время проверки и проговорить неизвестные. Если они прыгают прямо в героическое кодирование — допытывайтесь.
Если ваша команда хочет внешний взгляд, практичный вариант — привлечь опытного оператора для финального этапа. Oleg Sotnikov на oleg.is делает такого рода консультации и может просмотреть кандидатов или покрыть обязанности Fractional CTO, пока вы продолжаете найм.
Если вы всё ещё не можете понять, есть ли у человека здравое суждение, воспринимайте это как сигнал. Эта работа требует ясности под давлением. Оставшееся сомнение после фокусированного второго прохода обычно значит, что стоит продолжить поиск.
Часто задаваемые вопросы
Почему число тикетов — плохой критерий для оценки tech lead?
Потому что лидер формирует всё вокруг работы, а не только то, что он лично завершил. Двадцать закрытых тикетов мало что значат, если команда выпускает баги, спорит об ответственности или тратит следующий спринт на исправление поспешных решений.
Что должен сделать tech lead в первую очередь, когда релиз начинает падать?
В серьёзном инциденте сначала нужно сузить проблему. Спросите, что изменилось, кто чувствует проблему первым, безопасен ли откат и кто отвечает за каждую открытую задачу, затем уменьшите шум и дайте команде короткий план.
Как проверить суждение на интервью?
Откажитесь от абстрактных заданий и используйте реальный кейс, с которым ваша команда сталкивалась. Дайте короткий бриф с несколькими пропущенными фактами, ужмите дедлайн по ходу и смотрите, что они спрашивают до того, как предложат фикс.
Какой вопрос показывает системное мышление?
Прежде чем говорить о технологиях, спросите, что они сначала отобразят. Сильные лидеры обычно начинают с пользователей, сервисов, хранилищ данных, внешних поставщиков, точек отказа и того, кто будет поддерживать систему после запуска.
Как отличить уверенность от хорошего суждения?
Быстрые ответы и уверенный тон могут ввести в заблуждение. Хорошее суждение звучит спокойнее: они называют предположения, просят отсутствующие факты и говорят, что могло бы изменить их мнение.
Должен ли tech lead всё ещё писать код?
Да, но код — лишь часть роли. Лид должен быть достаточно близко к кодовой базе, чтобы принимать обоснованные решения, при этом управлять объёмом, рисками, выкатыванием и координацией команды.
Какие компромиссы tech lead должен хорошо решать?
Ставьте их в ситуацию, где скорость, безопасность и нагрузка на команду тянут в разные стороны. Хорошие лидеры говорят, что они бы урезали, что защитили бы и что отказались бы выпускать даже под давлением.
Как tech lead должен решать конфликт между инженерами?
Когда два инженера конфликтуют, уравновешенный лидер выслушивает обе стороны, называет решение, которое нужно принять, и закрывает цикл. Он не допускает, чтобы спор тянулся и тормозил спринт.
Какие красные флаги указывают на плохой найм tech lead?
Осторожно относитесь к кандидатам, которые сразу предлагают переписать систему, отвечают на всё с абсолютной уверенностью или говорят только о коде. Ещё тревожные знаки — игнорирование влияния на клиентов, отката, ответственности или нагрузки на поддержку.
Что делать, если я всё ещё не уверен после интервью?
Если остаётся сомнение, проведите ещё одну короткую сессию с запутанным сценарием и жёсткими ограничениями по времени. Можно также привлечь опытного оператора вроде Oleg Sotnikov для обзора кандидата или временного исполнения обязанностей Fractional CTO, пока вы продолжаете найм.