Как оценить кандидата на CTO на реальных задачах компании

Почему абстрактные интервью не работают

Отточенный ответ может скрывать слабое суждение. Многие кандидаты на CTO умеют звучать спокойно, стратегично и уверенно, если вопрос остаётся слишком общим. Спросите: «Как вы руководите инженерными командами?» — и, возможно, услышите аккуратную историю, которая всё равно почти ничего не скажет о том, как человек справится с вашим сдвинувшимся роадмапом, пробелом в найме или неловкой передачей задач между продуктом и инженерией.

Общие вопросы о лидерстве упускают компромиссы, из-за которых эта работа и сложна. Настоящий CTO не работает в вакууме. Он выбирает между запуском сейчас и исправлением долга, между быстрым наймом и повышением планки, между выполнением обещания клиенту и сокращением объёма, чтобы защитить команду. Если интервью не заставляет делать такой выбор, вы в основном оцениваете уверенность, память и манеру подачи.

Поэтому абстрактные интервью часто выигрывают не у тех, кто лучше думает, а у тех, кто лучше натренирован. Уверенный собеседник может красиво говорить о культуре, видении и процессах, а потом зависнуть, когда проблема становится конкретной. Более тихий человек может проявить себя намного лучше, когда увидит реальную бизнес-задачу.

Используйте проблемы, с которыми команда сталкивается прямо сейчас. Если сроки уже сдвигались дважды, возьмите это. Если роадмап растёт, а команда остаётся той же, тоже берите это. Если вам нужен план найма, но вы не понимаете, что важнее сначала — senior engineers, QA или продуктовая поддержка, сделайте это частью обсуждения.

Один конкретный пример работает лучше, чем десять общих вопросов. Скажем, ваша sales-команда пообещала фичу за восемь недель, двое инженеров уже перегружены, а кодовую базу пора чистить. Затем спросите кандидата, что бы он сделал первым, что бы отложил и что бы сказал CEO.

В этом и смысл сессии. Вы хотите увидеть, как человек думает под обычным давлением, когда информации мало и идеального ответа нет.

Выберите правильную проблему компании

Чтобы честно оценить кандидата на CTO, берите проблему, которая уже есть в вашей компании. Не придумывайте аккуратный сценарий для воркшопа. Нужна текущая, неловкая, связанная с работой задача, которую нельзя без последствий отложить.

Начните с одного конфликта в роадмапе, который уже существует. Например, sales нужен обещанный фичер в этом квартале, а продукт хочет исправить onboarding flow, который бьёт по активации. Такая напряжённость показывает, как кандидат взвешивает давление, сроки и понимание продукта.

Затем добавьте один реальный риск по поставке. Возьмите риск, который влияет на выручку или на конкретный дедлайн, а не абстрактную техническую тревогу. Это может быть процесс релизов, который ломается через раз, продление клиента, зависящее от одной просроченной интеграции, или миграция, которая всё время сдвигается и блокирует остальную работу.

Принесите одну проблему найма, которая перейдёт к новому CTO. Держите её в рамках вашей команды, бюджета и темпа. Возможно, вам нужен более сильный backend-лидер, но бюджет позволяет только одного хорошего универсала. Или разработчики быстро выпускают фичи, но за инфраструктуру и uptime никто не отвечает.

Сфокусированная проверка обычно состоит всего из трёх частей:

• один конфликт в роадмапе
• один риск по поставке
• один пробел в найме

Всё остальное убирайте. Посторонние темы часто делают сессию умнее на вид, чем она есть на самом деле. Если вопрос не повлияет на ближайшие 6–12 месяцев, не включайте его.

Это значит: никаких абстрактных споров о будущих оргструктурах, никаких общих разговоров про AI-стратегию и никаких любимых технических тем, которые так и не доходят до клиентов. Лучше меньше, но точнее. Так вы поймёте, умеет ли кандидат принимать решения в ваших условиях, с вашими ограничениями и на реальных ставках.

Подготовьте рабочую сессию

Отправьте короткий бриф до встречи. Обычно хватает одной страницы. Кандидат должен начать с фактов о вашем бизнесе, а не тратить первую часть звонка на догадки, что это за компания.

Сделайте бриф практичным. Включите детали, которые влияют на реальные решения:

• текущий размер команды и кто отвечает за продукт, инженерию и поставку
• стадию продукта, например до запуска, ранняя выручка или активная база клиентов
• важные дедлайны, например обещание релиза, дата продления или milestone для инвесторов
• ограничения, которые пока останутся в силе, например лимиты бюджета, технический долг, требования комплаенса или открытые роли, которые вы ещё не закрыли

Это быстро меняет разговор. Вдумчивый кандидат часто сначала присылает несколько уточняющих вопросов до сессии. Это хороший знак. Он показывает, что человек уже отделяет сигнал от шума.

Выделите достаточно времени. Шестьдесят минут выглядят удобно, но часто превращаются в скомканное интервью с кейсом сверху. Девяносто минут лучше. Два часа тоже могут подойти, если проблема одновременно затрагивает роадмап, найм и риски поставки.

Сделайте группу небольшой. Основатель или CEO должны участвовать, потому что они знают давление сроков и бюджета. Добавьте product lead и самого опытного инженера, который знает текущую систему. Все остальные могут молча наблюдать или вообще не участвовать.

Слишком много голосов создаёт странную проверку. Кандидат начинает управлять комнатой вместо того, чтобы решать задачу. Вам нужно услышать, как он думает, что спрашивает первым и где возражает.

Если вы пригласите внешнего советника или Fractional CTO понаблюдать, попросите его сравнивать логику кандидатов, а не вести встречу. Кандидат должен работать с вашей реальной командой и вашими реальными ограничениями. Это самый близкий предварительный просмотр перед наймом.

Проведите сессию по шагам

Дайте кандидату одну проблему, которая уже бьёт по бизнесу. Подходит срывающийся запуск, слабый воронка найма или растущее число инцидентов. Чтобы честно сравнивать кандидатов, каждому давайте один и тот же короткий бриф.

Начните с бизнес-цели простыми словами, а не с груды технических деталей. Скажите: «Нам нужно выпустить эту фичу за 10 недель, потому что её ждут два крупных клиента, но команда уже отстаёт». Так вы сразу задаёте компромисс.

Дальше ведите сессию по простому порядку:

1. Попросите кандидата пересказать проблему и цель своими словами.
2. Дайте ему задать вопросы о недостающих фактах, прежде чем он предложит решения.
3. Спросите, в чём, по его мнению, настоящая причина проблемы.
4. Попросите назвать два-три варианта, затем выбрать один и защитить его.
5. Спросите, что он сделал бы в первые 30 дней.

Второй шаг важнее, чем многие основатели ожидают. Хороший CTO не бросается советами, видя только половину картины. Он спрашивает о размере команды, процессе релизов, сроках клиентов, надёжности системы и о том, кто сегодня принимает решения.

Когда контекста уже достаточно, подталкивайте человека от диагностики к рекомендации. Если он остаётся расплывчатым, попросите чёткий выбор: сдвинуть объём, нанять более сильных людей, убрать work on debt или изменить роадмап. Вам нужен тот, кто может выбрать, а не только описывать.

Добавьте немного давления. Скажите, что бюджет оказался меньше, чем ожидалось, или что CEO отказывается двигать дату запуска. Посмотрите, как кандидат справляется с неопределённостью и возражениями. Сильные кандидаты остаются спокойными, объясняют компромиссы и корректируют план, не теряя цель.

Лучшие сессии больше всего похожи на настоящий разговор о лидерстве. После них у вас должно остаться ясное ощущение, как этот человек мыслит, когда ответ непрост и времени мало.

Проверьте напряжение в роадмапе

Кандидат на CTO показывает настоящее суждение тогда, когда ему приходится выбирать, а не когда ему разрешают одобрить всё подряд. Поставьте перед ним реальный план: фича, которую хотят клиенты, обещание sales, одна неприятная техническая проблема и команда, которая уже выглядит загруженной. Затем спросите, что идёт в релиз сейчас, а что ждёт.

Первый ответ важен, но причина важнее. Сильные кандидаты умеют спокойно резать объём. Они могут простыми словами объяснить, почему один пункт идёт вперёд, а другой сдвигается. Слабые кандидаты часто пытаются сохранить живыми все проекты сразу, что звучит красиво и обычно приводит к опозданиям.

Простой способ проверить это — попросить четыре решения:

• что они выпустят в ближайшие 30 дней
• что они отложат на один спринт или один квартал
• что они поставят на паузу, пока команда не уберёт риск
• что они выкинут, потому что отдача слишком мала

Потом немного возразите. Скажите, что sales нужна отложенная фича. Скажите, что один инженер может уйти. Скажите, что у клиента снова вспыхнула проблема. Посмотрите, что произойдёт.

Хорошие кандидаты не переписывают весь роадмап каждый раз, когда вы добавляете давление. Они защищают план, если только новый факт действительно не меняет бизнес-логику. Если они всё же меняют направление, они должны точно объяснить почему. Если держат курс, должны назвать цену этого решения.

Смотрите особенно внимательно, как они балансируют скорость, качество и нагрузку на команду. Зрелый CTO не будет гнаться за скоростью, тихо выжигая людей или накапливая предотвращаемые баги. Он может сказать: «Мы можем выпустить dashboard в этом месяце, но только если отложим новый billing flow и сначала потратим три дня на исправление проблем с деплоем».

Такой ответ полезен, потому что его поймут все в комнате.

Проверьте риски поставки и план найма

Сильный кандидат на CTO должен видеть, где ваш следующий квартал может быстро пойти не туда. Попросите назвать две или три точки, где поставка может сорваться, и заставьте его расставить эти риски по порядку. Если он считает каждую проблему срочной, это плохой знак. Хорошие лидеры отделяют реальные угрозы от шума.

Возьмите живой пример из вашего роадмапа. Допустим, sales пообещала enterprise-функцию, у engineering уже есть debt по багам, а один senior developer собирается уйти. Серьёзный кандидат скажет, что навредит поставке первым, что можно подождать и что он будет отслеживать каждую неделю.

Смотрите внимательно, как он говорит о штате. Некоторые кандидаты сразу переходят к «нанять больше инженеров». Звучит решительно, но часто скрывает слабое суждение. Количество людей помогает только тогда, когда работа понятна, у команды есть время вводить новых людей, а узкое место действительно в мощности.

Лучшие ответы обычно начинают с самой работы. Кандидат может сократить менее важные задачи, сузить объём рискованной фичи, назначить более сильного владельца на заблокированный участок или исправить одну процессную проблему, из-за которой всё время приходится переделывать. Найм идёт после этого, если реальный пробел всё ещё остаётся.

Потом спросите про порядок найма. Что он хочет нанять первым: senior backend engineer, engineering manager с продуктовым мышлением или DevOps? Выбор должен соответствовать только что названному риску. Если с uptime беда, инфраструктура может быть важнее, чем ещё один разработчик фич. Если требования постоянно меняются, команде может сначала понадобиться более сильное продуктово-техническое планирование, а не просто больше кода.

Планы на случай срыва важны не меньше. Спросите, что он будет делать, если найм затянется на три месяца или новый человек не подойдёт. Надёжные кандидаты держат бизнес в движении даже с более скромным планом, а не с фантастическим расписанием.

Слушайте и про сроки. Слабые кандидаты дают желаемое за действительное, например: «Мы, наверное, сможем выпустить всё это в следующем квартале». Сильные кладут на стол цифры и компромиссы. Они могут сказать: «Мы выпустим основной поток за восемь недель, если заморозим изменения после второй недели. Если вам ещё нужен admin layer, один пункт сдвинется».

Используйте простую scorecard

Простая scorecard лучше длинного обсуждения после встречи. Если полагаться на память, самый уверенный собеседник часто выглядит лучше человека, который принял более точные решения.

Держите её короткой. Четырёх-шести критериев достаточно, и каждый кандидат должен проходить через один и тот же сценарий.

Простой вариант выглядит так:

• Суждение — увидел ли он реальные компромиссы или сразу пошёл к лёгким ответам?
• Ясность — объяснил ли он выборы простым языком, с которым команда сможет работать?
• Приоритизация — отделил ли срочную работу от той, что может подождать?
• Понимание поставки — заметил ли он дедлайны, зависимости и вероятные точки отказа?
• Fit с командой — удалось ли ему спокойно и полезно взаимодействовать с вашей группой?

Используйте шкалу от 1 до 5 для каждого пункта. Число важно, но заметка рядом важнее. Записывайте, что кандидат реально сказал или сделал. «Сначала спросил о влиянии на пользователя, а не об архитектуре» — полезно. «Казался senior» — нет.

Держите доказательства привязанными к одному и тому же моменту сессии. Если один кандидат получил конфликт в роадмапе, а другой — проблему найма, оценки начнут съезжать. Давайте всем одно и то же начало, одно и то же время и одни и те же уточняющие вопросы.

Пересматривайте scorecard сразу после сессии, пока детали ещё свежи. Если ждать до следующего дня, в оценку легко просачивается bias. Люди быстро забывают конкретику и заполняют пробелы общими ощущениями.

Если участвуют два интервьюера, сначала ставьте оценки по отдельности и сравнивайте позже. Эта небольшая пауза помогает. Она не даёт более громкому человеку направить весь разговор.

Частые ошибки, которые искажают результат

Рабочая сессия помогает только тогда, когда разговор остаётся привязанным к реальным решениям. Многие команды ломают её, превращая в словесный спарринг. Лучший кандидат на CTO — редко тот, кто говорит быстрее всех или спорит жёстче всех. Вам нужен человек, который умеет разбирать хаос, задавать точные вопросы и выбирать компромиссы без драмы.

Уверенность может обмануть. Кандидат может звучать очень определённо, но при этом пропускать базовые факты, не замечать зависимости или отмахиваться от ограничений по найму. Ясное мышление выглядит иначе. Оно звучит спокойно, конкретно и даже немного скучно — в хорошем смысле. Сильный ответ часто включает фразу вроде «Мне нужен этот факт, прежде чем я возьму на себя обязательство», а не красивую речь.

Некоторые основатели специально усложняют задачу. Они скрывают лимиты бюджета, пробелы в команде или дедлайны, чтобы посмотреть, догадается ли кандидат. Обычно это даёт фальшивый результат. Если у вашей компании шесть месяцев runway, два слабых найма и отложенный запуск, скажите об этом. CTO будет работать с той компанией, которая у вас есть, а не с той, которую вы изображаете на 60 минут.

Не дайте комнате исказить результат

Одно громкое мнение может сбить всю сессию. Если основателю уже нравится один ответ, все остальные начинают оценивать стиль вместо сути. Так кандидат получает баллы за то, что совпал с комнатой, а не за решение проблемы.

Помогает простой приём. Попросите каждого интервьюера пять минут после сессии писать заметки отдельно. Сравнивайте их только потом. Так вы увидите, кого подкупили уверенность, жаргон или аккуратная схема на доске.

Жаргон — ещё один плохой фильтр. Некоторые отличные CTO говорят очень простым языком. Они называют риски, объясняют порядок работы и говорят, что бы отложили. Другие звучат впечатляюще, но остаются расплывчатыми. То же самое с манерой рисовать на доске. Неровные схемы нормальны, если мышление при этом сильное.

Оценивайте кандидата по тому, как он формулирует проблему, какие допущения проверяет и подходит ли его план вашей команде, бюджету и срокам.

Реалистичный пример

У небольшой SaaS-компании знакомый беспорядок. Команда постоянно пропускает даты релизов, число обращений в поддержку растёт, а клиенты теперь жалуются на баги чаще, чем на отсутствие новых фич. В роадмапе по-прежнему обещаны три крупных фичи на следующий квартал, но инженеры понимают, что качественно выпустить можно только одну.

Две роли в найме открыты уже несколько месяцев. Senior-инженеры тратят слишком много времени на разблокировку других, разбор прод-ошибок и ответы на вопросы поддержки. Они выгорают, и их собственная работа с каждым неделей сдвигается.

Сильный кандидат на CTO не пытается впечатлить комнату уверенностью. Он начинает срезать объём. Сначала спрашивает, какая фича приносит больше всего выручки или сильнее всего снижает churn, а потом переносит две другие за пределы квартала. Затем он сразу смотрит на процесс релизов: более мелкие релизы, понятная зона ответственности, меньше изменений в последний момент и правило, что повторяющиеся баги из поддержки чинятся раньше новой фичевой работы.

После этого он меняет очередность найма. Вместо того чтобы сразу гнаться за двумя сложными senior-ролями, он может предложить сначала закрыть одну практичную роль, например инженера с продуктовым мышлением или разработчика, который умеет работать с поддержкой, чтобы senior-команда быстрее освободила время. Такой ответ показывает суждение, потому что в одном движении он решает и напряжение в роадмапе, и риски поставки, и план найма.

Слабый кандидат обычно идёт в другую сторону. Он обещает ускорить output, говорит, что команда сможет выпустить все три фичи, и рассуждает о найме большего числа людей, не называя компромиссы. Задайте ещё один вопрос: «Что вы перестанете делать в следующем месяце?» Если кандидат всё равно не готов резать объём, вы узнали о нём что-то полезное.

Перед тем как принять решение

Сильная сессия обычно ощущается спокойно и конкретно. Кандидат задаёт достаточно вопросов, чтобы понять бизнес, а затем сужает варианты. Если он бросается в ответы в первые минуты, возможно, ему важнее звучать уверенно, чем быть правым.

Перед решением проверьте, что именно ваша команда видела и слышала:

• Спрашивал ли он про цели по выручке, дедлайны, ограничения команды и текущие блокеры до того, как предложить исправления?
• Делал ли он реальные компромиссы, например откладывал одну фичу ради снижения риска инцидентов или нанимал одного senior engineer вместо трёх junior?
• Замечал ли он риски поставки заранее, например скрытые зависимости, слабую ответственность, отсутствие метрик или роадмап, который предполагает, что всё пойдёт идеально?
• Соответствовал ли его план найма бюджету и стадии компании, и был ли у каждой роли ясный смысл?
• Могли ли основатели, product lead и инженеры понять его логику без человека, который переводит жаргон на простой английский?

Записывайте конкретные примеры, а не размытые впечатления. «Сначала спросил про churn data, а уже потом трогал роадмап» — полезно. «Казался умным» — нет. Так CTO interview process остаётся сфокусированным на суждении, а не на харизме.

Обратите внимание, что происходит, когда кандидат чего-то не знает. Хорошие CTO говорят, что им нужно проверить, что они бы тестировали сначала и что может подождать. Слабые заполняют пробел широкими обещаниями.

Если два кандидата выглядят почти одинаково, выбирайте того, чью логику ваша команда сможет повторить на следующий день. Ясное мышление хорошо переносится между продуктом, инженерией и наймом. Размытая гениальность обычно разваливается, как только начинается работа.

Что делать дальше

Положите заметки из рабочей сессии рядом с реальными потребностями бизнеса, а не рядом со скриптом интервью. Если вашей компании нужна более стабильная поставка, меньше срывов сроков и план найма на ближайшие шесть месяцев, оценивайте кандидата именно по этим пунктам. Острый ответ, который не подходит вашему этапу, всё равно остаётся неправильным ответом.

Ищите прямые доказательства в заметках сессии:

• Увидел ли кандидат реальный компромисс в вашем роадмапе?
• Защитил ли он поставку, не заморозив продуктовую работу?
• Предложил ли он найм для тех пробелов, которые у вас есть сейчас?
• Принимал ли он решения с понятными причинами, а не с расплывчатым разговором?

Именно здесь многие команды теряют сигнал. Они запоминают уверенность и забывают суждение.

Если один важный вопрос всё ещё открыт, проведите ещё одну сессию. Оставьте её узкой и практичной. Попросите кандидата вернуться к слабому месту, например к рискованной миграции, маленькой инженерной команде или релизному плану, который снова и снова сдвигается. Если вам нужна вторая сессия, потому что остаются неясными пять вещей, первая сессия уже сказала вам достаточно.

Проверка рекомендаций должна соответствовать упражнению. Если кандидат продавливал полную перестройку платформы, спросите у бывших основателей или senior engineers, принимал ли он такие решения раньше и чем это закончилось. Если он хотел замедлить найм и сначала наладить поставку, спросите, сработал ли такой выбор под давлением.

Внешний взгляд может помочь, если команда разделилась или если никто раньше не нанимал senior technical leader. Oleg Sotnikov на oleg.is предлагает консультации Fractional CTO для стартапов и малого бизнеса, а опытный ревьюер может здраво проверить ваш план сессии или scorecard до того, как вы примете решение.

Как только один кандидат показывает ясное суждение по вашим реальным проблемам, действуйте быстро. Сильные кандидаты долго не ждут, а промедление создаёт сомнения с обеих сторон. Примите решение, объясните, почему выбрали именно его, и превратите заметки сессии в план на 90 дней.