Как нанять первого разработчика в стартап

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

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

Кого нанимать первым: CTO, сеньора или студию?

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

Вариант	Когда подходит	Главный риск
Технический сооснователь	Технологии — ядро продукта, долгий горизонт	Сложно найти, конфликт основателей обходится дорого
Опытный фулстек-разработчик	Нужно быстро сделать и развивать MVP	Один человек — единая точка отказа
Студия или подрядчик	Нужно запуститься быстрее, чем получится нанять	Знания о продукте вне компании
Джуниор «на вырост»	Почти никогда для первого найма	Некому принимать архитектурные решения

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

Какие качества важнее всего у первого разработчика?

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

На что смотреть:

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

Фото: Unsplash

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

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

Порядок найма, который работает

1. Пригласите технического советника — знакомого CTO или независимого консультанта — на час-два для финальных интервью и оценки тестового.
2. Проведите разговор о прошлых проектах: что именно кандидат сделал сам, какие решения принял, что бы сделал иначе.
3. Дайте оплачиваемое тестовое задание на 1–3 дня, похожее на реальную задачу продукта.
4. Попросите объяснить решение вам и советнику: почему так, что упрощено, что сделал бы при большем времени.
5. Поговорите с прежними руководителями или заказчиками кандидата.

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

Задача: API для списка заказов пользователя
- регистрация и вход по email
- создание заказа и список своих заказов с пагинацией
- пользователь не видит чужие заказы
- README: как запустить, что упрощено и почему
Оцениваем: работает ли, понятен ли код, есть ли тесты, честен ли README

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

Сколько платить и нужна ли доля в компании?

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

Что обсудить и закрепить письменно:

• размер доли, график её получения (вестинг) и что происходит при уходе;
• роль и зону ответственности — разработчик или будущий CTO;
• кому принадлежат код и результаты работы — это нужно закрепить в договоре;
• как будет расти команда и кто будет её нанимать.

Условия доли стоит оформлять с юристом: ошибки в них всплывают в самый неудобный момент — на привлечении инвестиций или при уходе сотрудника.

Как не зависеть от одного разработчика?

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

Минимальная гигиена с первого дня:

1. Репозиторий, хостинг, домены, почта и внешние сервисы — на аккаунтах компании, у основателя есть права администратора.
2. README с инструкцией, как развернуть проект с нуля.
3. Автоматические бэкапы базы и проверка, что из них можно восстановиться.
4. Короткое описание архитектуры и ключевых решений.
5. Регулярные демо — основатель видит, что готово, а не узнаёт об этом из отчётов.

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

Коротко

• Первым нанимайте опытного фулстек-инженера или технического сооснователя, а не джуниора.
• Ищите самостоятельность, продуктовое мышление и опыт запуска с нуля.
• Без технических знаний опирайтесь на советника и оплачиваемое тестовое задание.
• Долю в компании давайте в дополнение к рыночной зарплате и оформляйте с юристом.
• Все доступы и знания держите на стороне компании с первого дня.