План найма технического сооснователя: что спросить в первую очередь

Почему одних историй о связях недостаточно

Технический сооснователь, который говорит: «Я знаю много отличных инженеров», может звучать обнадеживающе. Но это всё равно слабый ответ. Нескольких контактов хватит, чтобы закрыть одну вакансию, но это не доказывает, что человек умеет строить команду.

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

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

Разницу легко пропустить в разговоре. Один человек рассказывает истории о бывших коллегах из известных компаний. Другой объясняет, как он сейчас нанял бы backend-инженера, потом frontend-разработчика с пониманием продукта, а part-time DevOps — только когда нагрузка это оправдает. Второй ответ намного полезнее.

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

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

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

Попросите одностраничный план найма

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

Попросите назвать три следующие роли, которые он нанял бы для вашей компании. Очерёдность важна. Сильный ответ звучит конкретно: «Сначала product engineer. Потом дизайнер с сильным чувством frontend. Затем part-time DevOps lead, когда вырастет трафик». Слабый ответ остаётся общим и прыгает между ролями без объяснения.

Хороший одностраничный план обычно включает четыре вещи:

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

Детали показывают, умеет ли человек вести реальный процесс найма в стартапе. Спросите, откуда будут приходить кандидаты. Хорошие ответы включают несколько каналов и реалистичные ожидания: прямой поиск, рекомендации, нишевая площадка, бывшие кандидаты. Затем спросите, какой отклик он ожидает. Не нужны идеальные цифры, но он должен понимать, потребуется ли 30 сообщений или 300.

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

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

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

Если вам нужен простой ориентир, смотрите на тот же тип мышления, который используют сильные операционные руководители, когда собирают lean-команды: понятная последовательность ролей, честные бюджетные ограничения и быстрая корректировка, когда реальность меняется. Oleg Sotnikov часто работает именно так в ролях Fractional CTO, где решения по найму должны одновременно учитывать цели продукта и ограниченный cash flow.

Ищите подтверждение на реальных наймах

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

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

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

• как долго вакансия была открыта
• сколько кандидатов дошло до финальных интервью
• сколько офферов пришлось сделать, прежде чем один был принят
• остался ли человек после первых 6–12 месяцев

Хороший ответ звучит просто. «Мы наняли backend-инженера за пять недель. Сделали два оффера. Первый человек отказался, потому что роль была слишком широкой. Второй пришёл и остался». Это намного лучше, чем «У меня сильная сеть, и я всегда нахожу топовых людей».

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

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

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

Разберите воронку интервью по шагам

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

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

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

Как звучит хороший процесс

• Короткий первый скрининг с названным ответственным и понятным порогом «прошёл / не прошёл».
• Технический этап, который соответствует реальной работе.
• Практическое задание менее чем на два часа или живая задача вроде дебага, code review или улучшения небольшой фичи.
• Финальная беседа про fit с командой, приоритеты и рамки роли.
• Быстрая обратная связь после каждого шага, обычно в течение одного-двух дней.

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

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

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

Проверьте подход к онбордингу

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

Попросите его пройтись по дням 1, 7 и 30. Хорошие ответы звучат как план, а не импровизация. В первый день должны быть доступы к аккаунтам, репозиториям, cloud-права, чаты, трекинг задач, локальная настройка и короткий обзор продукта. Первая неделя должна включать чтение нужной документации, знакомство с людьми, с которыми человек будет работать, и выпуск одной небольшой задачи. К 30-му дню новый сотрудник должен владеть понятной зоной ответственности или выполнять повторяемый тип работы без постоянного спасения со стороны команды.

Слушайте практические детали:

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

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

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

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

Простой пример стартапа

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

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

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

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

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

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

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

Частые ошибки при оценке способности нанимать

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

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

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

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

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

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

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

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

Это важно. Истории могут впечатлять на встрече. Процесс — это то, что помогает человеку получить оффер, стать полезным и остаться в команде через шесть месяцев.

Быстрые проверки перед тем, как сказать «да»

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

Хороший план найма технического сооснователя обычно проявляется в четырёх местах:

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

Слушайте причинно-следственные связи. «Нам нужен senior engineer» — слабый ответ. «Нам нужен backend-инженер первым, потому что у клиентов слишком часто ломается настройка, и в первый месяц этот человек будет отвечать за billing и deployment» — намного лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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