Вопрос на собеседовании с техническим лидером: спросите, что бы он убрал

Почему ответы про видение могут ввести в заблуждение

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

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

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

Подделать это гораздо сложнее, чем красивый roadmap. Любой может сказать, что будет модернизировать стек или улучшать delivery. А вот сказать: «Я убрал бы этот логгинг-инструмент, потому что вы уже платите за другой, инженеры смотрят только в одну панель, а дублирование тратит и деньги, и время» — может далеко не каждый.

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

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

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

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

Видение всё равно важно. Направление нужно. Но прежде чем доверять человеку большой план, проверьте, может ли он сделать одно точное, практичное удаление и объяснить причину простыми словами.

Что показывает вопрос на удаление

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

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

Ответ также показывает, как кандидат соотносит стоимость и риск. Лучшие не вырезают самую дорогую статью только потому, что она выглядит затратной. Они ищут что-то с небольшим риском и понятной выгодой. Спокойный ответ может звучать так: пока оставить базу данных, до которой никто не хочет трогать, но убрать лишний logging-продукт, потому что команда уже получает те же сигналы из основного стека. Такой выбор экономит деньги и не превращает обычный вторник в инцидент.

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

Умение сказать «нет» тоже важно. Некоторые кандидаты хотят выглядеть смело и выбирают эффектную цель, а потом переходят к следующей теме. На встрече это может впечатлить, но позже часто создаёт хаос. Сильный кандидат может сказать: «Я бы не убирал on-call rotation, даже если он кажется дорогим, потому что он защищает клиентов. Сначала я бы убрал второй project tracker, потому что он создаёт двойной ввод и путаницу». Такой ответ ясный, конкретный и легко проверяется.

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

Как правильно задать вопрос

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

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

Просите об одной вещи. Одна система, один подрядчик или один процесс.

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

Хорошо сформулированный technical leader interview question звучит так: «Если смотреть на текущую настройку, какую одну систему, подрядчика или процесс вы убрали бы первым? Почему именно его?»

Потом продолжайте. Основную работу делают уточняющие вопросы:

• «Какую проблему это создаёт сейчас?»
• «Что вы проверили бы перед таким решением?»
• «Что вы сделали бы в первые 30 дней?»
• «При каком риске вы бы подождали?»

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

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

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

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

Если вы делаете fractional CTO hiring, этот вопрос особенно полезен. Парт-тайм лидеру нужно быстро принимать хорошие решения, и первый выбор очень многое говорит о его мышлении.

Как выглядит сильный ответ

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

Хорошие кандидаты ещё и объясняют нагрузку в цифрах, понятных не техническому основателю. «Мы платим 1800 долларов в месяц за этот инструмент, его используют только два человека, а команда всё равно выгружает данные в таблицы». Или: «Этот handoff добавляет два дня к каждому релизу, поэтому команда выпускает не каждую неделю, а только два раза в месяц». Если человек не может хотя бы примерно назвать стоимость, задержку или частоту ошибок, возможно, он просто гадает.

Следующая часть не менее важна. Сильные технические лидеры называют риск, не пытаясь казаться бесстрашными. Если они хотят убрать подрядчика, они должны сказать, что может сломаться, кто почувствует это первым и как они ограничат ущерб. Хороший ответ звучит так: «Я бы сначала убрал лишний monitoring-продукт, потому что он дублирует то, что команда и так проверяет ежедневно. Риск в том, что часть alert rules, на которые люди ещё опираются, исчезнет. Я бы составил карту этих алертов, воссоздал их, две недели прогонял обе системы параллельно, а потом отключил платный инструмент».

Заметьте, что делает этот ответ убедительным. В нём есть одна цель, причина, стоимость и план безопасности. Он не делает вид, что любое удаление проходит безболезненно.

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

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

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

Ошибки и красные флаги

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

Первый плохой сигнал — масштаб. Хорошие лидеры не начинают с «всё неправильно». Они начинают с одного удаления, которое снижает стоимость или нагрузку и при этом не ставит под риск выручку. Если кто-то сразу предлагает заменить CRM, облачную инфраструктуру, ticketing tool и процесс deployment, он гонится за драмой, а не за результатом.

Ещё один красный флаг — выбрать систему, не спросив, кто ей пользуется. Серьёзный CTO задаёт простые, полезные вопросы: кто зависит от этого каждый день, что сломается, если мы это уберём, и у каких команд уже есть обходные пути. Если человек выбирает billing, support, identity или reporting, не разобрав эти зависимости, ждите сюрпризов и злых людей.

Обвинять подрядчика по названию бренда — тоже промах. «Я ненавижу Salesforce» или «AWS слишком дорогой» почти ничего не говорит. Проблема может быть в плохой настройке, дублирующих инструментах, слабых контрактах или в годы мелких решений, которые накопились. Сильные кандидаты говорят о соответствии задаче. Они объясняют, почему инструмент не подходит вашему масштабу, бюджету, навыкам команды или стадии роста.

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

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

Несколько фраз должны заставить вас остановиться:

• «Я бы заменил весь стек».
• «Этот подрядчик — мусор».
• «Мы сможем мигрировать за выходные».
• «Команда подстроится».

Такой technical leader interview question работает, потому что показывает, как человек думает в реальных ограничениях. Самые сильные ответы часто звучат немного скучно. Они называют одно удаление, защищают людей, которые зависят от системы, и заранее определяют успех, прежде чем что-то менять.

Простой пример из растущей компании

Стартап из 25 человек продаёт подписочный продукт и хочет более понятные отчёты по росту. Со временем команда добавила три analytics-инструмента. Marketing доверяет одной панели, product — другой, а finance выгружает цифры в таблицы, потому что ни один отчёт не совпадает с billing-данными.

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

Сильный кандидат не начинает с обещания огромной перестройки аналитики. Он сначала выбирает одну вещь, которую уберёт. В этом случае он скажет, что отключил бы инструмент, который сильнее всего дублирует остальные и создаёт больше всего путаницы. Затем он назовёт единый источник правды для корпоративной отчётности — обычно тот, что ближе всего связан с billing и product событиями.

Ответ должен звучать практично. Например, так:

• Оставить один источник отчётности для ключевых метрик компании.
• Определить несколько самых важных показателей: trials, paid conversions, churn и revenue.
• На короткое время оставить старый инструмент включённым, чтобы команда могла сравнить результаты.
• Уточнить определения метрик до того, как строить новые дашборды.
• Проверить изменения через месяц.

Этот короткий переходный период важен. Осторожный лидер не удаляет старые данные в первый же день. Он оставляет прошлые отчёты доступными, документирует изменения и даёт команде время убедиться, что новые цифры стабильны. Так удаётся избежать паники и остановить обычный спор: «дашборд изменился, значит, возможно, изменился и бизнес».

Через месяц он проверяет три вещи. Во-первых, снизились ли расходы на софт? Во-вторых, стала ли команда меньше спорить о цифрах и исправлять отчёты? В-третьих, улучшилась ли точность настолько, что finance, product и marketing теперь используют одни и те же цифры на встречах?

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

Именно поэтому этот technical leader interview question может быть таким показательным. Хороший ответ показывает суждение в реальных ограничениях: деньги, время и команда, которая уже устала от грязных данных.

Короткий чеклист для заметок после собеседования

Когда вы задаёте этот technical leader interview question, не оценивайте ответ только по уверенности. Пока человек говорит, отмечайте несколько простых сигналов. Вам нужны доказательства, что он может сокращать лишнее, не ломая то, на что команда полагается каждый день.

Короткая карточка оценки помогает. Отмечайте каждый пункт простым yes, no или maybe.

• Выбрал ли он одну вещь для удаления? Сильный кандидат сначала называет одну систему, одного подрядчика или один процесс. Если он уходит в длинный список желаний, возможно, он не умеет фокусироваться, когда компромиссы становятся реальными.
• Связал ли он удаление с бизнес-результатом? Хорошие ответы говорят о деньгах, времени, риске, нагрузке на поддержку или скорости поставки.

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

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

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

Сразу после каждой встречи записывайте ответ простыми словами. Не полагайтесь на память. Хорошие кандидаты в комнате часто звучат похоже, но их логика сильно отличается, если потом сравнить записи рядом.

Короткая карточка оценки помогает:

• Что он выбрал удалить первым?
• Объяснил ли он бизнес-причину, а не только техническую?
• Назвал ли он риск и то, как его снизить?
• Сказал ли он, как будет измерять, сработало ли удаление?

Затем проверьте финалистов на одном реальном элементе из вашей компании. Возьмите инструмент, подрядчика, ритуал встречи, отчёт, шаг deployment или цепочку согласований, которые уже раздражают команду. Дайте каждому те же факты: стоимость, кто пользуется, что сломается, если это убрать, и от чего это зависит.

Вам не нужен идеальный ответ. Вам нужно понять, как человек думает, когда компромисс реален. Сильный технический лидер может сказать: «Я бы пока оставил это», если риск замены слишком высок. Часто это лучше, чем форсировать эффектное удаление.

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

Если ваша команда не может выбрать между двумя финалистами, возьмите второе мнение перед решением. Oleg Sotnikov делает такой разбор для стартапов и небольших компаний. Он может посмотреть на кандидатов, текущие системы и AI-first operating choices с практическим взглядом на стоимость и delivery. Это полезно, когда кандидат звучит умно, но вам нужен человек, который проверит, выдержит ли такой совет реальную работу внутри компании.

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