Знакомый фаундер четыре месяца не мог закрыть позицию senior-инженера. В итоге поднял оффер примерно на 20% выше рынка, кандидат согласился, команда выдохнула. Через три месяца инженер ушел в другую компанию.
Другой фаундер был в более слабой позиции: ранняя стадия, неизвестный бренд, ограниченный бюджет, продукт еще не до конца сформулирован. За шесть недель он закрыл три senior-позиции, прошел год и команда осталась с ним.
Это выглядит как две истории про рынок труда. Один “не нашел людей”, другой “нашел”. Но рынок у них был один и тот же: те же инженеры, те же ожидания по компенсации, та же конкуренция со стороны крупных компаний и других стартапов.
Разница была не в рынке. Разница была в том, что именно каждый из них продавал кандидату.
Первый описывал вакансию через стандартные параметры: стек, задачи, зарплату и место в команде. Второй объяснял контекст: что компания пытается построить, почему эта задача важна именно сейчас, какие решения предстоит принимать и как конкретный инженер сможет повлиять на результат.
До этого я тоже думал в категориях "ищу людей" — как будто это процесс поиска. А это процесс продажи. Ты продаешь виденье будущего, в которое они должны поверить. И вся механика после этого переписывается: от описания вакансии до того, как ты ведешь себя на собесе. Ты больше не оцениваешь кандидата. Ты конкурируешь за него.
На ранней стадии стартап почти никогда не выигрывает у большой компании по стабильности, инфраструктуре, узнаваемости бренда и предсказуемости. Если пытаться конкурировать только этими параметрами, стартап оказывается в слабой позиции еще до первого разговора.
Но у стартапа есть другое преимущество: скорость, ownership, прямой доступ к пользователям и и возможность вырасти вместе с компанией. Проблема в том, что многие фаундеры не умеют это показывать. Они говорят кандидатам общие слова про “быстрый рост”, “сильную команду” и “большой рынок”, но не объясняют, где именно в этой истории место конкретного инженера.
А сильные инженеры принимают решение не только по офферу. Они оценивают, будет ли их работа иметь значение.
Деньги не покупают лояльность. Они покупают время до увольнения
Компенсация важна. Если компания платит заметно ниже разумного уровня и при этом просит senior-инженера жить в режиме постоянного пожара, разговор не состоится. Люди не обязаны субсидировать чужой стартап своим уровнем жизни.
Но деньги редко создают лояльность сами по себе.
Оффер отвечает на вопрос: “Могу ли я позволить себе эту работу?” Он не отвечает на вопрос: “Почему я должен остаться здесь, когда появится другой хороший вариант?”
Первый фаундер из примера решил проблему так, как решают закупку: если ресурс не находится, нужно поднять цену. Это может сработать на моменте. Человек принимает оффер, позиция закрывается, в таблице появляется зеленая ячейка. Но если единственная причина выбора — деньги, то такая сделка остается хрупкой.
Следующий работодатель может повторить тот же аргумент. Иногда даже без особых усилий.
В этом смысле высокий оффер без сильной траектории покупает не лояльность, а время. Несколько месяцев, пока кандидат не получит другой сигнал: больше денег, более сильный бренд, интереснее команда, понятнее продукт или меньше риска.
Стартапу особенно опасно строить найм на одном уровне оплаты. У крупной компании есть: бренд, процессы, бонусы, карьерные уровни, внутренние переходы. У раннего стартапа этого нет. Если он еще и не может объяснить, почему риск оправдан, кандидат видит только худшую версию сделки: меньше стабильности, больше хаоса, непонятный upside.
Поэтому вопрос не в том, “платить или не платить”. Платить нужно нормально. Вопрос в другом: что остается в оффере после того, как деньги перестают быть единственным отличием?
Если ответа нет, компания конкурирует только бюджетом. А это почти всегда плохая стратегия для раннего стартапа.
Самый недооцененный канал найма — твоя личная репутация
Не репутация компании. Лично твоя. В крутых стартапах люди почти всегда идут за конкретным фаундером или техлидом, а не за логотипом.
Фраза “люди поверили в фаундера” часто звучит слишком абстрактно. Как будто речь про харизму, вдохновляющий звонок или способность красиво говорить о будущем.
На практике это более конкретная вещь.
Кандидат верит не в настроение фаундера. Он верит в качество его решений.
После хорошего разговора с фаундером у сильного инженера должно появиться ощущение, что этот человек понимает рынок, не прячет риски, быстро учится, умеет принимать неприятные решения и способен собрать вокруг себя людей сильнее среднего.
Это не всегда проверяется фактами в строгом смысле. На ранней стадии фактов мало. Но это проверяется качеством мышления.
Фаундер, который действительно понимает, что строит, говорит иначе. Он не ограничивается фразой “мы делаем AI-платформу для X” или “мы меняем рынок Y”. Он может объяснить, какие гипотезы уже проверены, где продукт пока слабый, почему пользователи сейчас решают проблему плохо, какие технические ограничения станут важными через полгода, а какие сейчас можно сознательно игнорировать.
Еще важнее — он может объяснить роль инженера в этой системе.
Не “у нас много интересных задач”, а конкретнее: “в ближайшие три месяца нам нужно перестроить вот эту часть продукта, потому что без нее мы не сможем проверить следующую гипотезу”; “сейчас архитектура выдерживает текущий объем, но если мы правы по рынку, через полгода это станет ограничением”; “нам нужен человек, который не просто напишет сервис, а поможет выбрать, где нам нельзя накапливать долг”.
Вот это и есть доверие. Не обещание, что все получится. А ощущение, что даже в неопределенности команда не действует случайно.
Поэтому у ранней компании может не быть бренда, но у нее должен быть сигнал доверия. Это может быть прошлый проект фаундера, а может быть сильный технический лидер. Иногда — открытый код, рекомендации, инвесторы, первые пользователи, качество публичных текстов.
Личная репутация здесь важна не как “личный бренд” в медийном смысле. Она важна как способ снизить неопределенность.
Сеньор 2026 — другой человек
AI сделал видимой проблему, которая существовала и раньше.
Самое крутое изменение последних двух лет: слово "сеньор" окончательно перестало что-то значить.
Слово senior давно размылось. В одной компании 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.
Поэтому роль продакта в стартапе не исчезает, а меняет форму. На ранней стадии функции продукта должны быть встроены в фаундеров и первых инженеров. Отдельный человек под менеджерские задачи нужен тогда, когда он усиливает эту систему, а не заменяет отсутствующее понимание пользователя.
Не нанимайте как большая компания, если вы не большая компания
Многие стартапы копируют hiring-процессы больших компаний, не понимая, под какую задачу эти процессы были спроектированы. У большой компании другой входящий поток. Она может позволить себе длинный процесс. У нее тысячи кандидатов, сильный бренд и много внутренних ролей. Ее процесс часто оптимизирован под снижение ложноположительных решений: лучше отказать сильному кандидату, чем нанять неподходящего на масштабную систему.
У раннего стартапа другие потери
У него мало кандидатов. Если процесс медленный, неясный или похож на бюрократию без причины, кандидат просто уйдет туда, где решение принимают быстрее.
Это не значит, что нужно нанимать хаотично. Наоборот, маленькой компании особенно нужен качественный процесс, но он должен быть коротким и качественным.
— Один сильный технический разговор лучше пяти этапов, которые только поверхностно раскрывают кандидата.
— Reference check от человека, который реально работал с кандидатом, часто ценнее формального интервью.
— Честный разговор о рисках и сложных задача лучше презентации, где все выглядит идеально.
Главный вопрос для стартапа: какой минимальный процесс дает достаточно сигнала, чтобы принять хорошее решение и не потерять сильного кандидата?
Тут можно думать о найме, как об инженерной задаче
Если смотреть на найм так, становится видно, что фраза “хороших людей нет” часто скрывает более конкретные проблемы.
— Описание роли не объясняет, зачем она нужна.
— Первый звонок не отвечает на главные риски кандидата.
— Техническое интервью проверяет не будущую работу, а привычный формат интервьюера. Команда долго принимает решение.
— Фаундер не может объяснить, почему проект стоит нескольких лет жизни.
— Scorecard существует формально, но итоговое решение все равно принимается на ощущениях. После отказов никто не анализирует, какой сигнал был потерян.
AI может ускорить операционную часть рекрутинга: суммаризировать интервью, готовить письма, искать похожие профили; но автоматизация не решает главный вопрос: какой именно сигнал компания пытается достать.
Если система проверяет не то, AI просто быстрее масштабирует плохой процесс.
Компании, которые выиграют найм, не обязательно будут иметь самый большой HR-отдел. Скорее, они будут лучше других понимать, какие люди им нужны, как их распознать и как не потерять по дороге.
Инженерам тоже нужно думать не только об оффере
Вторая сторона этой истории — кандидаты.
Многие инженеры слишком рано начинают оптимизировать карьеру под максимальную текущую компенсацию. Это понятно: деньги — видимый и простой критерий. Их легко сравнить. Они дают ощущение рационального выбора. Но в начале и середине карьеры главный актив часто не зарплата сама по себе, а скорость роста.
Есть роли, которые платят хорошо, но почти не увеличивают leverage. Ты становишься частью большой системы, делаешь узкий кусок работы, медленно растешь в ответственности и через два года оказываешься примерно в той же профессиональной точке, только с более высоким окладом.
И есть роли, где зарплата может быть не максимальной, но ответственность растет быстрее, чем твой титул. Ты ближе к пользователям, ближе к архитектурным решениям, ближе к ошибкам и последствиям. Ты быстрее понимаешь, как технические решения влияют на продукт, деньги, команду и скорость компании.
Это не романтизация стартапов. Большинство стартапов не становятся большими компаниями. Некоторые плохо управляются. Некоторые сжигают людей. Некоторые обещают ownership, а дают хаос без поддержки.
Но хороший стартап может сжать несколько лет опыта в гораздо более короткий период. Не потому что там “магия”, а потому что там выше овнершип.
Выбирать такую роль стоит не на вере в красивую историю, а по более конкретным признакам:
— Понимает ли фаундер рынок?
— Есть ли у команды скорость обучения?
— Будет ли у вас реальный ownership над задачами?
— Сильные ли люди рядом?
— Что вы будете знать и уметь через год, чего не умеете сейчас?
— Сможете ли вы объяснить будущему работодателю или инвестору, почему этот опыт был ценным, даже если компания не стала единорогом?
Круто когда растет не только зарплата, но и сложность задач, качество решений, уровень ответственности и ваша способность влиять на результат.
“Стабильный путь” не всегда самый безопасный
Стабильность часто воспринимается как противоположность риска, но это не совсем так.
У стабильной роли есть очевидные плюсы: предсказуемый доход, процессы, бренд, инфраструктура, меньше хаоса. Для многих людей это правильный выбор на конкретном этапе жизни.
Но у стабильности тоже есть стоимость:
— Можно потерять скорость роста.
— Можно несколько лет работать над задачами, где влияние отдельного инженера почти не ощущается.
— Можно перестать видеть рынок, пользователей и бизнес-контекст.
— Можно стать сильным специалистом внутри одной системы, но слабее как человек, который умеет строить новое.
Это не делает большие компании плохими. В них можно учиться у сильных людей, работать с масштабом и видеть инженерные практики, которые стартапам часто недоступны.
Проблема начинается, когда “стабильность” становится автоматическим выбором без анализа траектории.
Риск — это не только вероятность потерять работу. Риск — это еще и вероятность через пять лет обнаружить, что вы стали дороже как сотрудник, но не стали сильнее как строитель систем, продуктов и команд.
В мире, где реализация дешевеет, особенно ценными становятся люди, которые умеют выбирать правильные задачи, принимать решения в неопределенности и доводить продукт до пользователей. Это не всегда лучше всего развивается в самой стабильной среде.
Главный вывод: когда код дешевеет, дороже становятся решения
AI не отменил инженерную работу. Он изменил место, где чаще всего возникает ботлнек. Если раньше многие команды упирались в то, что “некому написать код”, то теперь все чаще проблема находится выше.
Найм инженеров в 2026 году — это уже не просто HR-задача. Для технологического стартапа это часть инженерии компании.
Фаундер должен уметь не только открыть вакансию, но и объяснить: что строится, почему это важно, где реальные риски, какую роль сыграет разработчик и почему эта возможность сильнее альтернатив.
Разработчик должен уметь не только сравнить офферы, но и оценить среду: где быстрее растет ответственность, где сильнее люди, где больше ownership, где опыт через два года будет стоить дороже, чем разница в зарплате сегодня.
Стартапы, которые выиграют борьбу за талант, не обязательно будут платить больше всех. Скорее, они будут лучше других делать три вещи: снижать неопределенность для кандидата, точнее проверять реальные навыки и быстрее превращать найм в управляемую систему.
В мире, где писать код стало проще, сложнее стало другое: выбрать правильную задачу, собрать правильных людей и построить процесс, который выдерживает скорость изменений.
Именно это теперь отличает сильную техническую команду от команды, у которой просто есть доступ к тем же инструментам.
Именно поэтому AI сам по себе не создаст миллионы успешных предпринимателей.
Если вы фаундер — перестаньте конкурировать только зарплатами. Создайте причину, по которой сильные люди захотят строить что-то вместе с вами.
Если вас нанимают — перестаньте оптимизировать жизнь только под краткосрочную зарплату. Оптимизируйте путь.
Найм в 2026 — это уже не про job descriptions.
Это про то, что именно вы строите — и почему талантливые люди должны захотеть строить это вместе с вами.
