Вопросы для собеседования с техническим сооснователем по вашему бэклогу

Почему собеседования не показывают суждение

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

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

Кодинг-тесты не ловят это по простой причине: они поощряют результат. Кандидат получает баллы за то, что закончил задачу, выбрал правильный шаблон или написал чистый код в спокойной обстановке. Работа в стартапе почти никогда не бывает такой аккуратной. В реальности есть неполные требования, старый код, который никому не нравится, и backlog, где все задачи будто срочные.

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

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

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

Выберите правильный срез бэклога

Хороший разбор бэклога начинается с реальной работы. Не придумывайте аккуратный маленький кейс с одним очевидным ответом. Возьмите 8–15 пунктов из вашего настоящего backlog, чтобы кандидат столкнулся с тем же хаосом, с которым живёт команда.

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

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

Такой набор создаёт напряжение. Кандидату, возможно, придётся выбирать между исправлением нестабильного онбординга, запуском обещанной sales-фичи, чисткой хрупкого скрипта деплоя или устранением проблемы поддержки, которая съедает по часу в день у команды. Именно здесь и видно суждение.

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

К каждому пункту добавьте короткую заметку о бизнес-эффекте. Одного предложения достаточно:

• «Sales нужен это для живой сделки.»
• «Этот баг затрагивает около 12% новых пользователей.»
• «Поддержка делает это вручную каждый день.»
• «Этот код часто ломается и замедляет релизы.»

Такие пометки держат разговор в реальности. Без них кандидаты начинают додумывать пробелы и звучат умнее, чем есть на самом деле.

Сильный backlog-разбор — это живой, актуальный и конкретный материал. Если срез немного неловко обсуждать, скорее всего, вы выбрали удачный вариант.

Как настроить интервью

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

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

Достаточно простого пакета для подготовки:

• 5–8 пунктов бэклога по одной строке каждый
• короткий контекст о продукте и текущей цели
• жёсткие ограничения вроде бюджета, размера команды или даты запуска
• пометка, что можно вычеркнуть, отложить или переписать любой пункт
• просьба объяснять ход мысли вслух во время звонка

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

Используйте жёсткий тайм-бокс. Тридцати–сорока минут обычно достаточно для небольшого среза backlog. Часы заставляют выбирать. Без них многие кандидаты пытаются спасти каждый пункт и выглядят умнее, чем выглядели бы под реальным стартап-давлением.

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

Многие собеседования на роль сооснователя проваливаются, потому что остаются слишком абстрактными. Реальный backlog, чёткий тайм-бокс и одинаковая подготовка для всех кандидатов дают вам то, что очень трудно подделать: суждение в условиях ограничений.

Как провести разбор бэклога шаг за шагом

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

Потом положите перед ним реальный backlog. Обычно хватает 8–12 пунктов. Смешайте баги, небольшие продуктовые запросы, технический долг и одну более крупную тему для переписывания, чтобы разговор был похож на обычную стартап-работу, а не на тест, придуманный специально для интервью.

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

Хорошо работает простой сценарий:

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

Когда он что-то вычеркивает или откладывает, не идите дальше. Именно этот момент обычно говорит больше, чем самый отточенный ответ. Хорошие кандидаты говорят о боли пользователей, мощности команды, риске и сроках. Более слабые прячутся за расплывчатыми фразами вроде «это выглядит более стратегически» или «нам нужно думать о масштабе», не объясняя, кому это нужно прямо сейчас.

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

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

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

Вопросы, которые вскрывают компромиссы

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

Задавайте по одному вопросу за раз. Потом просите расставить порядок, а не произносить длинную речь. Если кандидат говорит «зависит», спросите, от чего именно и какой сигнал изменил бы решение.

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

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

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

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

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

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

Как звучит хорошее суждение

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

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

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

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

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

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

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

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

Простой пример для стартапа

Представьте небольшой SaaS-продукт с тремя проблемами одновременно. Примерно 3% повторных попыток оплаты не проходят, поиск на крупных аккаунтах занимает 8 секунд, а sales пообещал новый дашборд потенциальному клиенту, который может подписаться уже в этом месяце.

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

Сильный кандидат часто приходит к чему-то вроде этого:

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

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

Решение по поиску тоже важно. Хорошие кандидаты не бросаются на переписывание только потому, что поиск медленный. Сначала они задают несколько простых вопросов. Сколько пользователей попадает в медленный путь? Это недавняя проблема? Может ли одна небольшая правка выиграть шесть месяцев? Именно такое суждение вам и нужно услышать.

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

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

Ошибки, которые скрывают слабое суждение

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

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

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

Слишком много материала тоже скрывает слабое суждение. Когда основатели вываливают 30 тикетов на один экран, собеседование превращается в проверку памяти. Хорошие люди начинают просматривать поверхностно. Более слабые прячутся в общих словах. Обычно 5–8 пунктов достаточно, чтобы заставить делать выбор, не превращая всё в хаос.

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

Последняя ошибка особенно распространена. Кандидат может подробно говорить про event bus, индексы базы данных или границы сервисов и при этом не увидеть очевидное решение: сначала исправить онбординг, потому что 40% пользователей уходят в первый день. Умение приоритизировать почти всегда важнее красивой архитектурной речи на раннем этапе стартапа.

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

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

Быстрая проверка перед решением

Финальный фильтр простой: доверили бы вы этому человеку принять тяжёлое решение во вторник, когда вас нет рядом? Умные ответы важны меньше, чем спокойное суждение. В небольшой компании одна неудачная перепись может сжечь месяц runway.

Помогают несколько проверок:

• Он объясняет компромиссы простым языком, который поймёт основатель или sales-лид.
• Он защищает деньги, доступность и обещанные сроки раньше, чем аккуратный код.
• Он спрашивает, что именно решает переписывание, сколько оно стоит и что ломается в процессе.
• Он умеет сокращать scope, не звуча небрежно или пренебрежительно.
• После разговора остаётся ощущение, что он примет решение, сообщит его и двинется дальше.

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

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

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

Ещё один сигнал тоже важен. Когда он урезает scope, сохраняет ли он результат для пользователя? «Убрать email-шаблоны с девяти до трёх к запуску» звучит аккуратно. «Просто выкатим поменьше» звучит небрежно.

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

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

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

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

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

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

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

Если вам нужен такой взгляд со стороны, Олег Сотников на oleg.is может посмотреть схему собеседования, проверить срез backlog, который вы планируете использовать, и оценить логику каждого кандидата с точки зрения Fractional CTO. Такой дополнительный взгляд особенно полезен, когда команде нравятся разные кандидаты, но никто не может внятно объяснить, кто принял лучшие решения.

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