Найм первого сеньор-инженера: чеклист для основателя

Почему этот найм ощущается иначе

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

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

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

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

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

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

Что нужно роли в ближайшие 12 месяцев

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

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

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

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

Простой таймлайн держит роль честной:

• К 30 дням он понимает продукт, кодовую базу и главный источник тормозов.
• К 90 дням он выпускает одно значимое улучшение и уменьшает одно повторяющееся больное место.
• К 180 дням он владеет частью системы «от конца до конца» и делает команду проще для масштабирования.

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

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

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

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

Простая структура работает хорошо. Начните с 20–30-минутного скрин-звонка. Проверьте, понимает ли кандидат объём работы, подходит ли ему такой тип роли и комфортен ли с хаотичной стартап-работой.

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

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

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

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

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

Хороший процесс интервью показывает одно: как думает человек, когда ставки реальны.

Как разработать полезное испытательное задание

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

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

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

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

Что стоит проверять

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

Ищите несколько вещей. Упростил ли кандидат задачу перед началом? Назвал ли риски и допущения? Соотнес ли он усилия с объёмом? Объяснил ли, где важнее скорость, а где — качество? Оставил ли понятные заметки для следующего человека?

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

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

На что слушать во время интервью

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

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

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

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

Несколько сигналов требуют особого внимания:

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

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

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

Ошибки основателей во время поиска

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

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

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

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

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

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

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

Предупреждающие знаки, которые нельзя игнорировать

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

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

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

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

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

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

• "Мне приходилось делать всё самому."
• "Команда меня замедляла."
• "Надо, наверное, всё переписать с нуля."
• "Я не особо занимаюсь наставничеством."

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

Компенсационные компромиссы, которые стоит обсуждать заранее

Расплывчатые разговоры о зарплате стоят дороже, чем многие думают. Назначьте диапазон зарплаты до финального раунда, а не после того, как все эмоционально вовлечены. Это экономит время и сохраняет доверие.

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

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

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

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

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

Компенсация — это не только числа. Это ещё и ясность. Правильный кандидат не всегда нуждается в самом высоком предложении, но ему нужно честное.

Реалистичный пример из маленького стартапа

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

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

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

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

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

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

Быстрая проверка перед сделкой

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

Пройдите пять быстрых проверок:

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

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

Ещё одна проверка полезна, если вы не технический: попросите доверенного советника или Fractional CTO просмотреть ваши заметки, задание и план оффера. Десять минут внешнего мнения могут уберечь от очень дорогой догадки.

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

Что делать после принятия решения

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

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

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

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

Нужны и правила. Может ли он утверждать технические изменения в одиночку или вам нужен одобрение основателя по архитектуре? Насколько быстро должны двигаться pull request'ы? Когда используют чат, почту или звонок? Малые команды часто пропускают это, а потом винят найм за беспорядок.

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

Если вы хотите второе техническое мнение перед окончательным решением, короткий внешний ревью может помочь. Oleg Sotnikov на oleg.is работает со стартапами как Fractional CTO и советник — такие обзоры роли и найма именно там, где опытный технический взгляд может сэкономить время и деньги.