Первый разработчик в стартапе: кого искать и как оценивать — задача, которую нельзя решать копированием вакансий зрелых компаний. В стартапе поиск и оценка первого разработчика стартапа зависит от стадии продукта, ресурсов фаундеров, runway и ближайших бизнес-целей.
Главный принцип — найти инженера, который быстро превращает продуктовые гипотезы в работающие решения и понимает последствия временных технических компромиссов. Ниже разобраны профиль, evidence, интервью, мотивация, part-time формат, ошибки, метрики и практический алгоритм для работодателя.
Почему задача сложнее, чем кажется
Один стартап начинает без кода, другой наследует MVP подрядчика, третий уже обслуживает первых клиентов. Стек может совпадать, но необходимая самостоятельность будет разной. Поэтому одинаковый title может означать разный мандат, уровень самостоятельности и набор рисков. До поиска нужно описать реальную ситуацию, а не идеальную оргструктуру.
основной язык и платформа
критичные интеграции
архитектурное ownership
минимальная инженерная дисциплина
участие в product discovery
Какой результат должен дать найм
Результат роли или процесса формулируется через изменение бизнеса, а не через количество действий. Для этой темы цель состоит в том, чтобы найти инженера, который быстро превращает продуктовые гипотезы в работающие решения и понимает последствия временных технических компромиссов.
Зафиксируйте результат на первые 90–180 дней, границу решений, доступные ресурсы и зависимости. Это позволяет сравнивать кандидатов по одной задаче и не менять профиль после каждого яркого интервью.
Как составить профиль
Разделите обязательные evidence и предпочтения. В стартапе полезна широта, но она не означает, что один человек должен полноценно закрывать несколько профессий. Название роли обязано совпадать с полномочиями.
основной язык и платформа
критичные интеграции
архитектурное ownership
минимальная инженерная дисциплина
участие в product discovery
Что проверять в опыте
Ищите не только совпадение title, а доказательства: production-запуски, работа с пользовательской обратной связью, осознанный технический долг. Попросите кандидата назвать исходный контекст, личную роль, решение, результат и то, что он изменил после ошибки.
production-запуски
работа с пользовательской обратной связью
осознанный технический долг
ответственность после релиза
code review или найм следующих инженеров
Если нужен адресный подбор сотрудников в IT-стартап, market mapping и shortlist следует строить по сопоставимой стадии, масштабу решений и реальному ownership, а не только по ключевым словам.
Как провести первичный скрининг
На скрининге проверьте стадию прошлых проектов, личную ответственность, мотивацию, условия и готовность работать с тем уровнем неопределённости, который действительно есть в компании.
Рано обсудите формат, диапазон и критичные ограничения. Нет смысла вести человека через несколько этапов, если стороны по-разному понимают роль, риск или доступные ресурсы.
Вопросы на интервью
Вопросы должны собирать evidence по scorecard, а не проверять уверенность речи. Полезно задавать одинаковые темы всем финалистам, чтобы сравнение не превращалось в обсуждение личной симпатии.
что нельзя экономить даже в MVP
когда покупать готовый сервис
как выбирать минимальную архитектуру
когда переписывать, а когда продолжать
как оценивать сроки без идеального ТЗ
Практический кейс
Нужно выпустить MVP за ограниченный срок при двух критичных интеграциях и неизвестной нагрузке. Кандидат объясняет границы решения, риски и порядок реализации.
Кейс должен занимать ограниченное время, использовать обезличенный контекст и проверять ход мысли. Не просите кандидата бесплатно решить реальную рабочую задачу, которую компания затем использует.
Взаимодействие с фаундером и командой
Критичные участники взаимодействия: технический фаундер или CEO, product owner, первые пользователи, внешние подрядчики, следующие инженеры. Проверяйте способность задавать вопросы, объяснять компромиссы, фиксировать решения и передавать контекст.
технический фаундер или CEO
product owner
первые пользователи
внешние подрядчики
следующие инженеры
Мотивация и предложение
Стартап должен честно объяснить стадию, scope, влияние, доступные ресурсы и риски. Миссия и скорость не заменяют фиксированную компенсацию, ясные полномочия и уважение к времени кандидата.
реальный ownership
честное состояние кода
доступ к продуктовым решениям
понятный горизонт продукта
компенсация и equity отдельно
Когда помогает part-time формат
Внешний инженер полезен для аудита, инфраструктуры или узкой интеграции, но постоянное ownership ядра продукта обычно требует высокой вовлечённости.
Для временного усиления можно использовать подбор специалистов на part-time, если заранее заданы объём, SLA, доступность, владелец знаний и критерий перехода к full-time или завершения сотрудничества.
Как построить процесс отбора
Рабочая схема обычно включает intake, sourcing, скрининг, содержательное интервью, короткий кейс при необходимости, финальную сверку и письменный offer. Каждый этап должен проверять отдельную часть scorecard.
Системный подбор команды для стартапа требует одного владельца решения, зарезервированных интервью-слотов и согласованного срока обратной связи.
Типичные ошибки
Ошибки процесса редко исправляются дополнительным количеством резюме. Если компания не готова принимать решения, новый sourcing только увеличит очередь и ухудшит candidate experience.
искать одиннадцать профессий в одном человеке
оценивать только алгоритмы
скрывать состояние legacy
романтизировать постоянные переработки
путать широту с отсутствием глубины
Пошаговый алгоритм
Начните с business outcome и ограничений, затем соберите профиль, карту рынка, процесс оценки и план онбординга. Изменения после запуска фиксируйте только при повторяющемся сигнале или изменении бизнес-задачи.
описать состояние продукта
выделить критичный стек
задать результат на 90 дней
проверить production ownership
провести короткий design-case
согласовать архитектурные полномочия
Чек-лист перед запуском
До публикации вакансии проверьте: кто владелец решения, что является результатом роли, какие полномочия и ресурсы доступны, каковы диапазон, этапы, SLA и план первых месяцев.
Понятная стадия и бизнес-контекст.
Один главный результат роли.
Граница полномочий.
Согласованный диапазон и формат.
Роли интервьюеров.
Срок обратной связи.
План онбординга.
Как измерять качество поиска
Смотрите не только time-to-hire. Важны качество shortlist, конверсии между этапами, скорость feedback, причины отказов, принятие оффера и результат первых месяцев.
подтверждённый production-опыт
релевантность стадии
качество технических компромиссов
скорость решений
причины отказов кандидатов
Как тема отличается от соседних материалов
Первый разработчик может быть сильным hands-on инженером без долгосрочного founding-статуса и без обязанности строить всю технологическую функцию.
Такое разведение интентов помогает не смешивать разные управленческие задачи в один общий текст и снижает риск SEO-каннибализации.
Частые вопросы
Нужен ли full-stack разработчик?
Только если продукт реально требует широты. Full-stack не означает обязанность закрывать DevOps, QA, design и product одновременно.
Можно ли взять сильного middle?
Да, если есть технический лидер, который принимает критичные решения и поддерживает развитие.
Обязателен ли startup-опыт?
Не всегда. Важнее запуск нового, самостоятельность и работа при ограниченных ресурсах.
Стоит ли давать тестовое?
Короткий ограниченный или оплачиваемый кейс допустим. Несколько дней бесплатной разработки не нужны.
Чем роль отличается от Founding Engineer?
Founding Engineer обычно имеет более широкий долгосрочный ownership и влияет на культуру и следующий найм.
Вывод
Первый разработчик в стартапе: кого искать и как оценивать требует ясной бизнес-задачи, структурированной оценки и честных ожиданий. Сильный результат появляется не из количества этапов, а из качества профиля, решений и коммуникации.
Передайте вакансию на подбор сотрудников в IT-стартап, если нужен адресный рынок, проверка реального опыта и процесс, который не разваливается между фаундером, интервьюерами и кандидатами.