Знакомый фаундер четыре месяца не мог закрыть позицию senior-инженера. В итоге поднял оффер на 20% выше рынка — кандидат согласился, команда выдохнула. Через три месяца он ушёл в другую компанию.
Другой фаундер находился в более слабой позиции: ранняя стадия, неизвестный бренд, ограниченный бюджет, продукт ещё не сформулирован. За шесть недель он закрыл три senior-позиции. Прошёл год — команда осталась с ним.
На первый взгляд — две истории о рынке труда. Один «не нашёл», другой «нашёл». Но рынок у них был один: те же инженеры, те же ожидания, та же конкуренция.
Разница была не в рынке. Разница — в том, что каждый из них продавал кандидату.
Первый описывал вакансию через стек, задачи, зарплату и место в команде. Второй объяснял контекст: что компания пытается построить, почему это важно сейчас, какие решения предстоит принимать и как инженер повлияет на результат.
До этого я тоже думал в категориях «ищу людей» — будто это процесс поиска. Это процесс продажи. Ты продаёшь видение будущего, в которое кандидат должен поверить. Всё меняется: от описания вакансии до поведения на собеседовании. Ты больше не оцениваешь кандидата. Ты конкурируешь за него.
На ранней стадии стартап почти никогда не выигрывает у крупной компании по стабильности, инфраструктуре, бренду или предсказуемости. Если конкурировать только этим, стартап проигрывает ещё до первого разговора.
Но у него есть другие преимущества: скорость, ownership, доступ к пользователям, возможность вырасти вместе с компанией. Проблема в том, что многие фаундеры не умеют это показывать. Они говорят общие слова — «быстрый рост», «сильная команда», «большой рынок» — но не объясняют, где место конкретного инженера.
Сильные инженеры принимают решение не только по офферу. Они оценивают, будет ли их работа иметь значение.
Деньги не покупают лояльность. Они покупают время до увольнения
Компенсация важна. Если платить заметно ниже рынка и требовать работы в режиме пожара, разговор не состоится. Люди не обязаны субсидировать стартап своим уровнем жизни.
Но деньги редко создают лояльность.
Оффер отвечает на вопрос: «Могу ли я позволить себе эту работу?» Но не на вопрос: «Почему я должен остаться, когда появится другой вариант?»
Первый фаундер решил проблему как закупку: не находится ресурс — подними цену. Это может сработать в момент. Позиция закрыта, в таблице — зелёная ячейка. Но если единственная причина выбора — деньги, сделка остаётся хрупкой.
Следующий работодатель может повторить тот же аргумент — даже без усилий.
Высокий оффер без сильной траектории покупает не лояльность, а время. Несколько месяцев, пока кандидат не получит другой сигнал: больше денег, сильнее бренд, интереснее команда, понятнее продукт или меньше риска.
Стартапу особенно опасно строить найм только на оплате. У крупной компании есть бренд, процессы, бонусы, карьерные уровни. У раннего стартапа этого нет. Если он ещё и не может объяснить, почему риск оправдан, кандидат видит худшую версию сделки: меньше стабильности, больше хаоса, непонятный upside.
Поэтому вопрос не в том, «платить или не платить». Платить нужно нормально. Вопрос в другом: что остаётся в оффере после того, как деньги перестают быть единственным отличием?
Если ответа нет, компания конкурирует только бюджетом. Это почти всегда плохая стратегия для раннего стартапа.
Самый недооценённый канал найма — твоя личная репутация
Не репутация компании. Лично твоя. В крутых стартапах люди идут за конкретным фаундером или техлидом, а не за логотипом.
Фраза «люди поверили в фаундера» часто звучит абстрактно. Будто речь о харизме или красивой речи.
На практике это конкретнее.
Кандидат верит не в настроение. Он верит в качество решений.
После разговора с фаундером у сильного инженера должно возникнуть ощущение: этот человек понимает рынок, не прячет риски, быстро учится, принимает неприятные решения и собирает сильных людей.
На ранней стадии фактов мало. Но проверяется качество мышления.
Фаундер, который понимает, что строит, говорит иначе. Он не ограничивается «мы делаем AI-платформу для X». Он объясняет: какие гипотезы проверены, где продукт слаб, почему пользователи решают проблему плохо, какие технические ограничения станут критичными через полгода, а какие можно игнорировать.
Ещё важнее — он объясняет роль инженера.
Не «у нас много интересных задач», а: «в ближайшие три месяца нужно перестроить эту часть, иначе не проверим следующую гипотезу»; «архитектура выдерживает сейчас, но через полгода станет ограничением»; «нам нужен человек, который поможет выбрать, где нельзя накапливать долг».
Вот это и есть доверие. Не обещание успеха. А ощущение, что в неопределённости команда не действует случайно.
У ранней компании может не быть бренда, но должен быть сигнал доверия. Это может быть прошлый проект, сильный техлид, открытый код, рекомендации, первые пользователи или качество публичных текстов.
Личная репутация важна не как «личный бренд», а как способ снизить неопределённость.
Сеньор 2026 — другой человек
AI сделал видимой проблему, которая существовала и раньше.
Слово «сеньор» окончательно перестало что-то значить.
В одной компании senior — это тот, кто давно пишет код и почти не требует контроля. В другой — проектирует системы и влияет на стратегию. В третьей — просто следующий уровень после middle.
До AI значительная часть производительности зависела от ручной реализации. Кто быстрее писал код, лучше знал фреймворк — тот выглядел сильнее.
Теперь часть реализации стала дешевле.
Можно быстрее получить черновик функции, тесты, миграцию, прототип, несколько вариантов решения, документацию или разобрать незнакомый код.
Если раньше инженер выигрывал за счёт скорости реализации, теперь — за счёт понимания, что именно нужно реализовать, где нельзя ошибиться и как проверить результат.
Senior в 2026 — это не «человек, который пользуется AI». Это слишком слабый критерий.
Сильный senior — тот, кто встраивает AI в процесс, но не передаёт ему ответственность за систему.
Он превращает расплывчатую продуктовую задачу в техническую спецификацию. Отделяет важные ограничения от шума. Быстро получает черновик, но не принимает его за архитектуру. Видит edge cases, которые модель не увидела. Понимает, где сгенерированный код — временное решение, а где — долг через три месяца.
Это принципиально другой уровень работы.
AI увеличивает output только у тех, кто умеет управлять контекстом. У остальных он ускоряет производство технического долга.
Отсюда — резкий разрыв между инженерами. Опытный инженер, который работает как раньше, не становится плохим. Но его преимущество уменьшается. Менее опытный, но с системным мышлением и привычкой к спецификациям, может стать намного продуктивнее.
Не потому что AI заменил опыт. А потому что опыт теперь нужно уметь конвертировать в более быстрый процесс принятия решений.
Вокруг AI-инструментов много поверхностного разговора
Часто он сводится к тому, кто чем пользуется. Но в работе важен не промпт, а способность формализовать задачу.
Хороший запрос к AI очень похож на хороший technical brief.
- Контекст: какая система, какие ограничения, зависимости.
- Ожидаемый результат: что должно измениться.
- Критерии качества: как понять, что решение подходит.
- Запреты: что нельзя ломать, какие подходы не подходят.
- Способ проверки: тесты, метрики, логи, ревью, сценарии пользователя.
Если инженер не умеет дать чёткую задачу человеку, он точно не сможет дать качественный промпт AI.
И наоборот: тот, кто умеет писать спецификации, получает от AI реальный leverage. Он не просит «сделай красиво». Он разбивает задачу, задаёт границы, получает варианты, сравнивает, проверяет допущения и интегрирует результат.
Поэтому в найме важно проверять не «умеет ли кандидат пользоваться Claude или Codex». Это быстро станет базовым навыком. Важно проверять, умеет ли он формулировать инженерную задачу так, чтобы её мог выполнить и человек, и машина.
Многие технические интервью построены так, будто работа инженера — это решить изолированную задачу с известным ответом
В реальности senior-инженер в стартапе почти никогда так не работает.
Он получает неполное описание проблемы, частично сломанный контекст, legacy-код, ограничение по времени, противоречивые ожидания, неидеальные данные. Иногда — решение, принятое до него, которое нужно спасти или заменить.
Интервью, проверяющее только алгоритмические задачи в вакууме, легко даёт ложный сигнал.
Кандидат может хорошо проходить такой формат и плохо работать в неопределённости. Или наоборот: сильный инженер, который проектирует системы и принимает зрелые trade-off, может выглядеть средне в неподходящем формате.
Для early-stage стартапа это особенно опасно. Цена ошибки в первых наймах очень высока. Первые десять инженеров формируют не только код, но и нормы: как спорят, принимают решения, относятся к качеству, пишут документацию, сообщают о рисках, работают с пользователями.
Собеседование должно моделировать реальную работу.
- Вместо абстрактной задачи — дайте кусок реального кода. Попросите разобрать: что рискованно, что можно оставить, что переписать, что проверить перед релизом, где долг, а где нормальное решение.
- Вместо тестового на выходные — короткая paid-сессия на похожей задаче. Важен не только результат, но и ход мысли: какие вопросы задаёт кандидат, как уточняет ограничения, где предлагает быстрый путь, где настаивает на надёжности.
- Вместо «знаете ли вы X» — спросите: «как бы вы выбрали между двумя плохими вариантами, если релиз нужен через неделю?»
Потому что именно так обычно и выглядит работа.
В стартапе продакты не нужны
Тезис звучит эффектно, но в буквальном виде — слишком грубый. Сильные product-менеджеры существуют и создают ценность.
Проблема в раннем стартапе — не в отсутствии продакта, а в том, что продуктовая функция вынесена в отдельную роль слишком рано.
До product-market fit продукт нельзя «передать» продакту, как зрелую функцию в большой компании. На ранней стадии ещё неясно: кто пользователь, где боль, какая фича критична, что можно не строить, где техническая сложность оправдана, а где команда делает красивую, но ненужную вещь.
Если фаундер не понимает этого сам, продакт не спасёт компанию.
В early-stage команде инженер, который понимает продуктовый контекст, становится намного ценнее. Не потому что он заменяет продакта, а потому что сокращает расстояние между проблемой пользователя и техническим решением. Это гораздо продуктивнее, чем оптимизация процессов в Jira.
Роль продакта в стартапе не исчезает, а меняет форму. На ранней стадии функции продукта должны быть встроены в фаундеров и первых инженеров. Отдельный человек нужен тогда, когда он усиливает систему, а не заменяет отсутствующее понимание пользователя.
Не нанимайте как большая компания, если вы не большая компания
Многие стартапы копируют процессы найма больших компаний, не понимая, под какую задачу те были спроектированы. У большой компании другой поток кандидатов. Она может позволить себе длинный процесс. У неё сильный бренд, тысячи заявок и много внутренних ролей. Её процесс оптимизирован под снижение ложноположительных решений: лучше отказать сильному, чем нанять неподходящего в масштабную систему.
У раннего стартапа другие потери
У него мало кандидатов. Если процесс медленный, неясный или похож на бюрократию, кандидат уйдёт туда, где решение принимают быстрее.
Это не значит, что нужно нанимать хаотично. Наоборот, маленькой компании особенно нужен качественный процесс — но он должен быть коротким и эффективным.
- Один сильный технический разговор лучше пяти этапов, которые только поверхностно раскрывают кандидата.
- Reference check от человека, который реально работал с кандидатом, часто ценнее формального интервью.
- Честный разговор о рисках и сложных задачах лучше презентации, где всё выглядит идеально.
Главный вопрос для стартапа: какой минимальный процесс даёт достаточно сигнала, чтобы принять решение и не потерять сильного кандидата?
Тут можно думать о найме, как об инженерной задаче
Если смотреть на найм так, становится ясно: фраза «хороших людей нет» часто скрывает конкретные проблемы.
- Описание роли не объясняет, зачем она нужна.
- Первый звонок не отвечает на главные риски кандидата.
- Техническое интервью проверяет не будущую работу, а привычный формат интервьюера.
- Команда долго принимает решение.
- Фаундер не может объяснить, почему проект стоит нескольких лет жизни.
- Scorecard существует формально, но решение принимается на ощущениях.
- После отказов никто не анализирует, какой сигнал был потерян.
AI может ускорить операционную часть рекрутинга: суммаризировать интервью, готовить письма, искать профили. Но автоматизация не решает главный вопрос: какой именно сигнал компания пытается получить.
Если система проверяет не то, AI просто быстрее масштабирует плохой процесс.
Компании, которые выиграют найм, не обязательно будут иметь самый большой HR-отдел. Скорее, они будут лучше других понимать, какие люди им нужны, как их распознать и как не потерять по дороге.
Инженерам тоже нужно думать не только об оффере
Вторая сторона — кандидаты.
Многие инженеры слишком рано оптимизируют карьеру под максимальную текущую компенсацию. Это понятно: деньги — видимый и простой критерий. Их легко сравнить. Они дают ощущение рационального выбора. Но в начале и середине карьеры главный актив — не зарплата, а скорость роста.
Есть роли, где платят хорошо, но почти не увеличивают leverage. Ты становишься частью большой системы, делаешь узкий кусок работы, медленно растёшь в ответственности и через два года оказываешься примерно в той же точке — только с более высоким окладом.
И есть роли, где зарплата может быть не максимальной, но ответственность растёт быстрее, чем твой титул. Ты ближе к пользователям, к архитектуре, к ошибкам и последствиям. Ты быстрее понимаешь, как технические решения влияют на продукт, деньги, команду и скорость компании.
Это не романтизация стартапов. Большинство из них не становятся большими. Некоторые плохо управляются. Некоторые сжигают людей. Некоторые обещают ownership, а дают хаос без поддержки.
Но хороший стартап может сжать несколько лет опыта в короткий период. Не из-за «магии», а из-за высокого овнершипа.
Выбирать такую роль стоит не на вере в красивую историю, а по конкретным признакам:
- Понимает ли фаундер рынок?
- Есть ли у команды скорость обучения?
- Будет ли у вас реальный ownership над задачами?
- Сильные ли люди рядом?
- Что вы будете знать и уметь через год, чего не умеете сейчас?
- Сможете ли вы объяснить будущему работодателю или инвестору, почему этот опыт был ценным, даже если компания не стала единорогом?
Круто, когда растёт не только зарплата, но и сложность задач, качество решений, уровень ответственности и способность влиять на результат.
«Стабильный путь» не всегда самый безопасный
Стабильность часто воспринимается как противоположность риску. У неё есть плюсы: предсказуемый доход, процессы, бренд, инфраструктура, меньше хаоса. Для многих — это правильный выбор на конкретном этапе жизни.
Но у стабильности тоже есть стоимость:
- Можно потерять скорость роста.
- Можно несколько лет работать над задачами, где влияние инженера почти не ощущается.
- Можно перестать видеть рынок, пользователей и бизнес-контекст.
- Можно стать сильным специалистом внутри одной системы, но слабее как человек, который умеет строить новое.
Это не делает большие компании плохими. В них можно учиться у сильных людей, работать с масштабом, видеть инженерные практики, недоступные стартапам.
Проблема начинается, когда «стабильность» становится автоматическим выбором без анализа траектории.
Риск — это не только вероятность потерять работу. Это ещё и вероятность через пять лет обнаружить, что вы стали дороже, но не стали сильнее как строитель систем, продуктов и команд.
В мире, где реализация дешевеет, особенно ценны те, кто умеет выбирать правильные задачи, принимать решения в неопределённости и доводить продукт до пользователей. Это не всегда лучше всего развивается в самой стабильной среде.
Главный вывод: когда код дешевеет, дороже становятся решения
AI не отменил инженерную работу. Он изменил место, где чаще всего возникает ботлнек. Если раньше команды упирались в то, что «некому написать код», теперь проблема — выше.
Найм инженеров в 2026 — это уже не просто HR-задача. Для технологического стартапа это часть инженерии компании.
Фаундер должен уметь не только открыть вакансию, но и объяснить: что строится, почему это важно, где риски, какую роль сыграет разработчик и почему эта возможность сильнее альтернатив.
Разработчик должен уметь не только сравнить офферы, но и оценить среду: где быстрее растёт ответственность, где сильнее люди, где больше ownership, где опыт через два года будет стоить дороже, чем разница в зарплате сегодня.
Стартапы, которые выиграют борьбу за талант, не обязательно будут платить больше всех. Скорее, они будут лучше других: снижать неопределённость для кандидата, точнее проверять реальные навыки и быстрее превращать найм в управляемую систему.
В мире, где писать код стало проще, сложнее стало другое: выбрать правильную задачу, собрать правильных людей и построить процесс, который выдерживает скорость изменений.
Именно это теперь отличает сильную техническую команду от команды, у которой просто есть доступ к тем же инструментам.
Именно поэтому AI сам по себе не создаст миллионы успешных предпринимателей.
Если вы фаундер — перестаньте конкурировать только зарплатами. Создайте причину, по которой сильные люди захотят строить что-то вместе с вами.
Если вас нанимают — перестаньте оптимизировать жизнь только под краткосрочную зарплату. Оптимизируйте путь.
Найм в 2026 — это уже не про job descriptions.
Это про то, что именно вы строите — и почему талантливые люди должны захотеть строить это вместе с вами.