Тогда компании нанимали инженеров с запасом, под давлением цифровизации, дешевых денег и страха «остаться позади». По данным Indeed и FRED, пик вакансий пришелся на середину 2022 года. После чего последовал резкий спад, так и не вернувшись до прежнего уровня.

Почему ИИ — удобный, но не главный виновник

ИИ стал публичным оправданием сокращений. Заявление «мы заменяем людей на ИИ» хорошо смотрится в отчетах и перед инвесторами.

На практике же компании сокращали издержки, выравнивали штат и параллельно активнее нанимали за пределами США и Европы, где инженеры стоят дешевле.

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

Как будет выглядеть рынок в 2026 году

Эксперты сходятся во мнении: 2026 год пройдет в режиме «низкого найма — низких увольнений». Массовых сокращений не ожидается, но и бурного роста вакансий не будет. Так выглядит стабилизация рынка.

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

По прогнозу Бюро статистики труда США, число вакансий для разработчиков продолжит расти примерно на 15%. Это медленнее, чем ожидалось раньше, но все еще быстрее большинства профессий.

Почему джунам повезло меньше всего

Самое слабое место рынка — начальные позиции. Количество вакансий для junior-разработчиков упало примерно на 40% по сравнению с допандемийным уровнем.

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

Но это также создает отложенную проблему — без притока новичков рушится кадровый «конвейер».

Какие навыки реально востребованы

В 2026 году ценятся не языки сами по себе, а связки «язык + область».

Тот же Python чаще всего нужен при работе с ИИ и данными. JavaScript и TypeScript — для фронтенда и fullstack. Go — для бэкенда и инфраструктуры. Java — для enterprise-систем.

Параллельно растет спрос на ИИ- и дата-инженеров, а также специалистов по ИИ-инфраструктуре.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

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

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

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

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Ниже — оставшиеся три паттерна, которые мы не разобрали в прошлой статье.

Хуки и кастомные хуки

Мы уже несколько раз упоминали хуки (Hooks) — пора поговорить о них как о новом паттерне, фактически пришедшем на смену многим предыдущим. Хуки появились в React 16.8 и моментально изменили стиль написания компонентов. Теперь вместо классов с методами жизненного цикла у нас функциональные компоненты, которые используют состояния (useState), эффекты (useEffect) и другие возможности прямо внутри функции. А главное — мы можем писать свои собственные, пользовательские хуки (custom hooks) для повторного использования логики.

Почему же хуки так популярны? Они дают возможность переиспользовать состояние и побочные эффекты, не меняя структуру самих компонентов. Раньше, чтобы два компонента разделяли какую-то логику, приходилось применять HOC или Render Props — то есть вводить дополнительный компонент-обёртку или коллбэк. Теперь же мы можем вынести логику в custom hook useSomething() и вызвать его в нужных нам компонентах или других кастомных хуках. Получается, что хуки позволяют писать более прямолинейный, читаемый код: вместо закулисной магии HOC мы явно вызываем необходимые нам хуки и получаем данные.

Custom hook — это просто функция, название которой по соглашению начинается с use (чтобы линтер React знал, что внутри неё могут быть хуки). Например, давайте перепишем наш HOC withCounter из предыдущего примера как кастомный хук:

Получилось то же самое поведение (счётчик кликов), но без обёрток. Компонент ClickButton сам вызывает useCounter() и получает count и increment. Внутри useCounter может быть любая другая сложная логика, побочные эффекты, вызовы других хуков — компонент, использующий наш хук, об этом не знает и не должен знать. Зато код компонента предельно ясный: он просто берёт нужные ему данные из хука и использует их.

Повторное использование логики — главное преимущество кастомных хуков. Вы можете написать, например, хук useFetch(url) (достаточно распространённое решение), который будет обращаться к API и возвращать состояние загрузки, успеха запроса, данные и ошибки. Далее можно применять этот хук в разных компонентах, страницах, не дублируя сам код запроса.

Кроме того, хуки отлично работают друг с другом. Вы можете внутри одного хука вызвать другой (например, использовать useContext или useReducer внутри своего useAuth хука). Это помогает облегчить написание сложных функциональностей, так как мы используем небольшие хуки, выполняющие простые задачи, из которых как конструктор составляем более сложное поведение.

Плюсы: ясность и лаконичность. Мы не оборачиваем компонент, использующий хук, ни в какие лишние слои, его JSX не замусорен вспомогательными функциями или компонентами, он просто вызывает хук и получает результаты. HOC и Render Props во многом ушли в прошлое из-за того, что хуки решают те же проблемы более естественным для JavaScript способом. Кастомные хуки легко тестировать (это по сути просто функции). Хуки позволяют разделять логику внутри одного компонента на независимые части: например, компонент может использовать одновременно и свой локальный useState, и несколько разных кастомных хуков — каждая часть отвечает за себя, и этот код не переплетается, тогда как при использовании нескольких HOC или Render Props было бы труднее изолировать ответственности.

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

В целом, сейчас хуки — основной инструмент в React, используемый разработчиками. Большинство новых API, фреймворков, библиотек строятся вокруг хуков. Поэтому если вы видите библиотеку, написанную на HOC либо Render Props, то, скорее всего, у неё уже есть или появится версия на хуках. Хуки сделали код React компонентов более понятным и свели на нет необходимость в классах (почти все новые фичи React рассчитаны только на функциональные компоненты).

Compound Components (Составные компоненты)

Паттерны, о которых говорилось выше, касаются того, как компоненты делятся логикой или данными. А есть подход, делающий фокус на композиции компонентов, позволяя создавать гибкие интерфейсы. Compound Components — это паттерн, при котором несколько компонентов работают вместе как единое целое, обмениваясь общим состоянием (обычно через контекст). Пользователь такого комплекта компонентов может гибко комбинировать его части в JS.

Я познакомился с данным паттерном, когда писал в качестве пет-проекта свой собственный UI Kit. Представьте <Accordion> с множеством <AccordionItem> или <Select> и <Option>. Compound Components — когда мы пишем код таким образом, что компонент <Accordion> не обязан принимать массив пунктов через пропсы и рендерить его внутри. Мы даём разработчику возможность самому в JSX расписать, какие пункты будут у аккордеона и что в них будет находиться, используя заранее предусмотренные дочерние компоненты: <Accordion.Item>, <Accordion.Header> и <Accordion.Panel>.

Возможно, у вас, как и у меня, сразу же возник вопрос в голове: «как же Accordion узнает о своих Item и организует их работу?» Внутри — как раз при помощи React Context. Compound Components обычно реализуются так: родитель (компонент-контейнер) содержит всё состояние (например, какой пункт раскрыт) и методы управления (функция toggle(index)). Он оборачивает children своим контекст провайдером и передаёт туда эти данные и функции. Дочерние компоненты (которые рендерятся где-то внутри children) просто берут нужное из контекста и таким образом получают доступ к состоянию родителя. Они знают, к какому именно контейнеру принадлежат, благодаря тому, что рендерятся внутри него и получают его контекст.

Давайте рассмотрим конкретный пример. Сделаем простой составной компонент Toggle, который будет управлять отображением/скрытием некоторого контента по клику. У нас будет <Toggle> в роли контейнера и его дочерние компоненты <Toggle.On>, <Toggle.Off> и <Toggle.Button>.

Здесь <Toggle> управляет состоянием on (показано/скрыто) и предоставляет через контекст значение { on, toggle } всем потомкам. <ToggleOn> и <ToggleOff> читают on и в зависимости от него либо рендерят children, либо нет. <ToggleButton> получает из контекста функцию toggle и вызывает её при клике. В итоге снаружи мы получаем удобный и декларативный интерфейс: внутрь <Toggle> мы помещаем разные части UI, которые сами знают, когда им отображаться и что делать при клике — мы лишь описываем структуру, не связывая их вручную пропсами.

Обратите внимание: компоненту <Toggle> без разницы, сколько у него внутри <ToggleOn> или <ToggleOff> и какой внутри них JSX. Всё завязано только на состоянии контекста. Это и есть сила композиции: пользователю библиотеки даются «кирпичики» (несколько компонентов), из которых он может сложить нужную конструкцию как ему необходимо, а не один монолитный компонент с десятком пропсов настроек.

Плюсы этого паттерна: огромная гибкость и выразительность. Хороший compound-компонент ощущается как маленький фреймворк. Например, библиотека @reach/ui (предшественник современной radix-ui) много компонентов строила через этот паттерн: диалоги, списки, выпадающие меню . Пользователю легко понять API — просто вкладывай одни компоненты в другие. Появляется возможность тонко настроить итоговую разметку, вставить дополнительные элементы если надо, ведь внутри children мы не ограничены, можем обернуть тот же <ToggleButton> в какой-нибудь <div> с нужным классом. Проще поддерживать визуальное единообразие: все части контролируются одним контекстом, не размазывая логику по нескольким несвязанным компонентам.

Минусы: сложнее реализовать. Необходимо аккуратно продумать как компоненты будут взаимодействовать, предусмотреть, что некоторые могут отсутствовать или повторяться. Если неправильно спроектировать составной компонент, можно столкнуться с багами: например, если <ToggleButton> случайно использовать вне <Toggle> (то есть вне своего провайдера), useContext вернёт undefined и будет ошибка — надо либо избегать такого, либо делать проверки и бросать понятное сообщение об ошибке (мол, «ToggleButton ОБЯЗАТЕЛЬНО должен быть потомком Toggle»).

Ещё один момент связан с производительностью, когда контекстное значение меняется, все потребители контекста перерендерятся. Например, при каждом клике toggle выше перемонтируются и <ToggleOn>, и <ToggleOff>, и <ToggleButton>. В нашем случае это конечно пустяки, но если бы у нас был десяток сложных для ререндера children'ов, подписанных на контекст, и состояние менялось часто, нужно было бы подумать об оптимизации (разбивке контекстов или мемоизации).

Тем не менее плюсы обычно перевешивают: паттерн Compound Components позволяет создать очень понятный и гибкий пользовательский API для ваших компонентов. Это проявление философии React — композиция важнее наследования. Вместо того чтобы делать сложный компонент с кучей условий, мы делаем набор простых компонентов, которые в комбинации собираются в сложное поведение.

Compound Components — довольно «профессиональный» паттерн. В небольших приложениях вы можете не столкнуться с необходимостью его реализовывать, но если разрабатываете библиотеку компонентов, как я в своём пет-проекте, или сложный виджет, такой подход — чуть ли не необходимость. Практически все продвинутые React UI-библиотеки (Material UI, Chakra, Radix и т.д.) используют контекст и композицию под капотом для своих сложных компонентов.

Серверные компоненты и Suspense: современные возможности React

Наконец, давайте поговорим о новейших возможностях, которые принесли нам 18 и 19 версии React’а. Они направлены на улучшение работы с асинхронностью, данными и рендерингом на стороне сервера. В первую очередь, React Suspense и Server Components. Эти вещи ещё не до конца устоялись в среде разработчиков, но их стоит держать в уме.

Suspense — ожидание с комфортом

Когда интерфейсу нужно загрузить данные, всегда возникает задача — показать индикатор загрузки, пока всё не готово. Раньше приходилось вручную писать логику, часто это бывало состояние isLoading и условный рендер либо спиннера, либо контента. С появлением React Suspense командой React был предложен более декларативный способ. Suspense — это специальный компонент, который позволяет нам приостановить рендеринг своих дочерних компонентов, пока те не готовы, и в это время показать fallback UI.

Проще говоря, мы оборачиваем часть дерева компонентов в <Suspense fallback={<Loader/>}> ... </Suspense>, и если внутри этой области происходит задержка (например, идёт загрузка кода или данных), React сам автоматически покажет <Loader> вместо содержимого, а когда всё завершится — отобразит наши компоненты. Suspense берёт на себя координацию этого процесса, освобождая нас от ручного управления состоянием загрузки.

Сегодня Suspense широко используется для ленивой загрузки компонентов (React.lazy + <Suspense>). Например:

Здесь компонент Comments будет подгружён по требованию (и в отдельном бандле). Пока бандл не загрузится, пользователь увидит текст-заглушку «Комментарии загружаются...». Как только код придет, React отрисует <Comments>. Всё это без какого-либо специального кода внутри ArticlePage для отслеживания загрузки. Suspense сам разрулит ситуацию — React.lazy под капотом бросает Promise на время загрузки, а <Suspense> ловит его и показывает фоллбэк.

Кроме ленивой загрузки кода, Suspense постепенно начинает применяться и для асинхронных данных. В React 18 появился экспериментальный API, позволяющий Suspense работать с данными, например, можно использовать специальный use для ожидания промиса прямо внутри компонента (пока официально не стабильно, но фреймворки типа Next.js 13 уже вовсю используют это). Идея та же: компонент, который загружает данные, вместо того чтобы сразу вернуть JSX, может приостановить своё выполнение до получения данных. React, обнаружив это, покажет fallback, а когда данные придут — продолжит рендер компонента. Таким образом, можно писать компонент, который выглядит синхронным, хотя внутри у него асинхронный код — за счёт Suspense'а пользователю не покажется незавершённый результат.

Признаться, Suspense для работы с данными — пока штука из области экспериментов. Если вы пишете обычное приложение на Vite или CRA без Next, то прямо сейчас использовать Suspense для загрузки данных «из коробки» не выйдет — потребуется либо сторонняя библиотека (например, React Query пока не интегрирован с Suspense по умолчанию, но планирует), либо фреймворк. Однако направление понятное: React движется к тому, чтобы сделать работу с асинхронностью более декларативной. Уже сейчас вы можете использовать Suspense для спиннеров и заглушек при загрузке кода, а в ближайшем будущем, вероятно, подобный подход станет нормой и для данных (в React 19+ должны появиться официальные инструменты для этого).

Подводя итог по Suspense: этот паттерн позволяет очень аккуратно организовать отображение состояния загрузки. Вместо большого количества условных isLoading ? <Spinner> : <Content> мы просто заявляем: «Эта часть UI может задержаться, показывай пока вот это». Это улучшает UX (пользователь видит скелетон или лоадер без моргания незагруженного контента) и упрощает код. Обязательно следим за развитием Suspense — возможно, скоро он будет использоваться намного чаще, чем сейчас.

Серверные компоненты — React выходит на сервер

Ещё одна революционная идея команды React — React Server Components (RSC), или серверные компоненты. Это попытка объединить лучшее из мира серверного рендеринга и клиентских SPA. Смысл в том, что если часть ваших React-компонентов может выполняться только на сервере, генерируя готовый HTML, который отправляется клиенту, то пусть они и исполняются на сервере, не загружая клиент. Эти компоненты никогда не попадают в бандл JS, не несут в себе интерактива — они чисто для рендеринга контента. Другая часть компонентов всё также остаётся клиентской, это давно знакомые нам React-компоненты, которые умеют обрабатывать события, имеют какое-то своё состояние и т.д. Разделение происходит явно: React различает, какой компонент предназначен для сервера, а какой — для клиента.

Как же React понимает, в какой среде выполнять код компонента? Введена директива "use client": если файл компонента начинается с этой строки, то компонент клиентский, он будет собран в JS и выполнится в браузере. Если же такой строчки нет — компонент считается серверным и по умолчанию выполнится на сервере (например, при рендеринге страницы на Node.js). Серверный компонент может содержать асинхронный код (запросы к БД, файловой системе и т.п.), ведь он запускается в среде сервера. Но он не может использовать, например, useState или useEffect, ведь у него нет постоянного состояния между запросами, да и доступ к DOM он не имеет.

React 18 (и в полной мере React 19) позволяет фреймворкам использовать эту возможность. Например, Next.js 13 с новым app/ роутером делает все компоненты по умолчанию серверными, если не указать "use client". Таким образом, большую часть страницы вы можете рендерить на сервере, отдавая сразу на клиент сразу готовую разметку, а для интерактивных элементов использовать клиентские компоненты.

Преимущества Server Components:

• Производительность. Серверные компоненты избегают гидрации, клиенту не нужно повторно исполнять JS, чтобы восстановить состояние UI. Вы получаете выгоды SSR (быстрый первый рендер, минимум работы на клиенте) без обычных недостатков SSR (необходимость гидрации большого объёма HTML).
• Безопасность. Чувствительный код остается на сервере, не попадает в бандл, и данные можно получать напрямую на сервере (например, напрямую из базы) без передачи ключей API в браузере.
• Размер бандла существенно сокращается, ведь клиент вообще не получает код серверных компонентов, только итоговую HTML разметку и нужный JS для оставшихся клиентских компонентов.

Как это выглядит на практике? Самый понятный пример:

Представим блог. Страницу поста можно сделать целиком серверным компонентом, на сервере загрузится пост из БД и вернёт нам готовую верстку статьи. А вот кнопка лайка или форма добавления комментария — это уже интерактив, их делаем клиентскими компонентами. В результате пользователь, заходя на страницу, сразу же получит полностью готовую страницу поста (никакого лоадера, всё пререндерено). А JS-код загрузится для кнопки лайка и формы комментария, и только они будут гидрироваться и начнут работать на клиенте. Это сочетание SSR и SPA, orchestrated by React.

React строго определяет, как серверные и клиентские компоненты могут взаимодействовать. Серверный компонент может импортировать и использовать другой серверный или клиентский компонент, а вот клиентский компонент не может импортировать серверный. То есть дерево может быть: Серверный → внутри него Клиентский → внутри него ещё Клиентский и т.д. Но не наоборот. В примере выше серверный компонент страницы может рендерить внутри себя <LikeButton /> (клиентский компонент кнопки). А если бы вы попробовали внутри клиентского компонента сделать import PostDetails from './PostDetails.server.jsx' — сборка не позволит, скажет, что так нельзя. Таким образом, архитектура разделяется: «верхние» уровни страницы — серверные, «листья» интерактивности — клиентские.

Server Components — пока прерогатива фреймворков. То есть в обычном приложении вы не сможете воспользоваться этим вручную без большого труда. Но если вы работаете с Next.js, Remix или в целом с fullstack React-приложениями, то RSC уже доступны. В React 19 они обещают быть полностью стабильными (в React 18 это скорее эксперимент для энтузиастов). Библиотеки тоже начинают подстраиваться: например, React Router v7 планирует поддерживать RSC, Vite тоже экспериментирует с этим.

Что в итоге нам дают серверные компоненты? Потенциально — большой скачок в производительности и удобстве разработки fullstack приложений. Мы получаем паттерн разделения по среде: какие компоненты должны рендериться на сервере, а какие — на клиенте. Это новое измерение при проектировании React приложения. Разработчику теперь нужно будет думать не только о разделении логики и UI, или о переиспользовании кода, но и решать, где лучше его выполнить — на сервере или в браузере. Правильное использование RSC может значительно ускорить приложение без лишних усилий для разработчика (React сам решит, когда и что подгружать, синхронизирует состояние между сервером и клиентом).

С другой стороны, появляется дополнительная сложность в понимании: нужно чётко осознавать ограничения (например, нельзя в серверном компоненте использовать useEffect, или что состояние в серверном компоненте не сохраняется между запросами). Но это всё решается практикой и хорошей документацией.

Заключение

Мы рассмотрели ключевые паттерны React и даже заглянули в будущее React-архитектур.

• Container & Presentational Components привносят порядок, отделяя логику от отображения.
• HOC и Render Props — старые приёмы для переиспользования кода, которые в значительной мере вытеснены более современными хуками, но по прежнему встречаются в проектах.
• Compound Components демонстрируют силу композиции, предоставляя API для гибкой сборки компонентов из небольших частей.
• А Suspense и Server Components — это уже ближайшее будущее, делающее работу с асинхронностью и рендерингом более эффективной и декларативной.

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

От себя добавлю: изучая паттерны, всегда пробуйте их в деле. Напишите свой HOC, переделайте компонент с Render Props на хук, реализуйте небольшой набор Compound Components — так вы прочувствуете их сильные и слабые стороны. React развивается, и появляются новые приёмы, но фундаментальные идеи (композиция, разделение обязанностей, явное управление состоянием) остаются. Владейте этими инструментами, и ваши React приложения будут благодарить вас чистотой и поддерживаемостью кода!

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

Мы поговорили с Даниилом Динько, тимлидом в международной компании-лидере в кибербезе, который стал руководителем в ХХ лет, а также с эйчар-экспертами Эйч — Анной Динельт и Еленой Артемьевой, и узнали, что это значит — быть молодым тимлидом, как справляться с критикой и какая в целом ситуация на рынке.

— Даниил, расскажи, как ты пришел в программирование и как развивалась твоя карьера до тимлидства?

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

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

Через некоторое время мы с ребятами, движимыми той же идеей, поднимаем первый свой сервер, который набирает в пике 150 человек в онлайне и приносит нам какой-то первый кэш. Представляете, насколько это было приятно на тот момент? Во-первых, ты создал что-то с минимальными усилиями (не пришлось даже чего-то мастерить, речь просто про правильную последовательность нажатий по клавиатуре). Во-вторых, это работает, и этим пользуются люди — еще один огромный источник мотивации. В-третьих, небольшой проект приносит какие-то деньги — можно уже самому сходить и купить что-то приятное. Это и был мой старт в IT.

Затем я просто начал ресерчить другие сферы, изучать разные языки программирования, и понял, что веб-разработка выглядит приятнее всего. Почему — не знаю до сих пор, просто лежала душа. Так я создал свои первые пет-проекты и вышел на фриланс в качестве Fullstack разработчика на NodeJS. Стэком у меня тогда были ReactJS/Angular, MongoDB, NestJS.

А еще через время понял, что мне больше все-таки нравится писать логику — бэкенд. Я пробовал разные языки, но зацепил только один — Golang. Поначалу только синтаксисом, о его мощных инструментах я узнал уже позже. Так и определился со стеком. Затем устроился в первую компанию, получил первый коммерческий опыт не на фрилансе — в сфере криптовалют (тогда туда брали почти всех). А потом уже попал в Ситидрайв, Ozon, а сейчас я тимлид в международной компании-лидере в сфере кибербезопасности (название, к сожалению, говорить не могу).

— Как же ты стал тимлидом?

— Честно говоря, лидом получилось стать весьма спонтанно. Я тогда менял работу, поскольку мне совсем не зашёл тот домен в Озоне, где я работал — логистика на складах, и зарплата была не в рынке. На тот момент я был сеньором и искал вакансии на соответствующую позицию в других компаниях. У меня уже было несколько интересных офферов, но тут вдруг меня приглашают на интервью на позицию TeamLead + TechLead команды в одном лице.

Я был немного удивлен, поскольку у меня не было коммерческого опыта руководства, только программирование в высоконагруженных проектах. Однако на тот момент я ресерчил эту тему, параллельно просматривая доклады с TeamLead Conf просто ради интереса и в качестве горизонтального развития, плюс я уже долгое время был и являюсь ментором на площадке Эйч Навыки, где обучаю ребят Go и всему вокруг него.

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

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

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

— Расскажи, как к тебе относились коллеги? Были ли ситуации, когда приходилось доказывать свою компетентность?

— Я ни разу не сталкивался с предвзятостью в компаниях, где работал. Предполагаю, что в нынешней команде люди узнали о моем возрасте уже после того, как мы с ними начали плодотворно работать. У нас в компании в рабочих процессах абстрагируешься от того, кто ты и сколько тебе лет, мы все объединены одной целью — отдать релиз. Сейчас я потихоньку поднимаюсь на позицию Head of Development: буду руководить еще и фронтендерами, забирая на себя разработку всего продукта.

Я работаю в Яндексе, и здесь к молодым руководителям относятся очень позитивно. Назначения связаны не с возрастом, а с профессиональными навыками и лидерскими качествами. Талантливые ребята рано становятся руководителями, и это круто!

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

Однако с предвзятым отношением я столкнулся в другой сфере, связанной с IT — в менторстве. Я провел более 15 трансляций на большую аудиторию, каждая из которых набрала более 1 500 просмотров и 100 человек в лайве. На первых трансляциях в силу того, что я выгляжу весьма молодо, от некоторых ребят слышал хейт в сторону возраста, и он вполне оправдан: ты уже состоявшийся разработчик не совсем молодого возраста, и тут ты приходишь на стрим, где тебе какой-то молодой «чувачок» пытается что-то объяснить неуверенным голосом. Конечно ты будешь возмущаться.

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

Что для этого нужно было? Во-первых, чувствовать себя уверенно, потому что если ты не сильно уверен в своих компетенциях (синдром самозванца), то и другие тем более. Во-вторых, нужно уметь правильно общаться с аудиторией. У меня следующий принцип: я представляю, что передо мной сидит мой друг, который хочет что-то понять, и мне нужно это объяснить. Аудитории обычно заходит именно такой формат.

— Есть мнение, что молодые тимлиды менее устойчивы на одной позиции и чаще меняют компании (так называемые попрыгунчики). Как это сказывается на карьере?

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

Что говорят эйчар-эксперты

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

Я думаю, что молодой возраст — идеальное время, чтобы пробовать разное и искать себя. Поэтому «0% осуждения, 100% понимания» с моей стороны! В «красный флажок» это превращается, когда человек бессистемно меняет места, проработав на каждом менее 6-8 месяцев. При этом в динамике нет ни роста дохода, ни понятной карьерной траектории. В таком случае для меня на месте нанимающего менеджера это выглядит подозрительно.

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

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

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

Я видела много случаев, когда ребята уходили (в том числе из моих команд) на роль лида, руководителя направления и т.п., со словами «я хочу делать все с нуля и под себя». В итоге 90% из них очень быстро понимали, что роль руководителя — это не то, что они себе представляли, и они либо очень быстро увольнялись и переходили на грейд ниже в новую компанию, либо их увольняли, иногда до конца испытательного срока. Были и исключения, но только для тех, кто быстро понимал, что такое роль лида, какая ответственность на нем лежит, и кто быстро перестраивал свою модель поведения из исполнителя в лидера команды.

— Даниил, скажи, можно ли вырасти до тимлида в одной компании так же быстро?

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

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

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

— Как твой возраст повлиял на карьеру? Было ли проще или сложнее проходить собеседования, вливаться в коллектив?

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

Если бы я был старше, то таких бы проблем у меня, конечно, не возникало. В медийной среде аналогично — если ты где-то ведешь трансляцию или что-то иное, то тебе нужно выглядеть и быть на порядок выше. Если тебе 30-40 лет, то тебя уважают с гораздо большей вероятностью (то есть тебе главное просто не потерять это уважение) — и это нормально. А когда тебе далеко не столько лет — нужно получать уважение с нуля самому, даже, я бы сказал, с минуса — в этом и вся сложность. Но адаптироваться к такой среде можно спокойно, я так и сделал.

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