Привет, Хабр! Меня зовут Лёша Руденко, во фронтенде уже более семи лет, сейчас работаю в финтехе. А ещё я ментор на курсе «Мидл фронтенд-разработчик» в Яндекс Практикуме. Как наставник я помогаю студентам совершить карьерный переход из джуниор-разработчика в мидлы. Точнее так: моя задача в том, чтобы начинающий разработчик не утонул в огромном количестве советов, рекомендаций, статей и видео и сам пришёл к заветной цели. Количество фреймворков и технологий пугает, кажется, что нужно учиться сразу всему. А рассказы про невероятные, практически демонические алгоритмические задачи на собеседованиях добавляют фрустрации. Но если чётко видеть цель, то пройти путь легче. Именно поэтому я решил поделиться тем, что я понимаю под «мидл фронтенд-разработчиком», и очертить сам путь развития в профессии. Мидл — понятие относительное: у каждой компании свои требования и ожидания к задачам, которые решает мидл. Например, уровень L4 в Google требует как минимум диплома бакалавра по Computer Science, а также от двух до четырех лет опыта в индустрии. В это же время от мидла в небольшой продуктовой компании могут ожидать умения работать с определенными фреймворками и писать тесты на свой код, а на опыт работы будут смотреть далеко не в первую очередь.  Умение решать алгоритмические задачки будет приветствоваться везде, но необходимым этапом отбора будет скорее всего только в крупных компаниях вроде Яндекса или FAANG. Компании и продукты, в штате которых гораздо меньше разработчиков, могут ожидать от мидла чисто утилитарных навыков: писать тесты, взаимодействовать с API, верстать компоненты и использовать их в рамках фреймворка. Есть интересные попытки свести все возможные навыки в матрицы компетенций или роадмапы. В интернете найдёте много и разных, а я оставлю ссылку на roadmap.sh: там есть сноски и ссылки почти на все узлы роадмапа. Но призываю помнить о том, что каждый такой скилсет — лишь личное мнение его автора и может быть абсолютно неприменим в вашей компании или продукте. Некоторые компании публикуют свои ожидания к разработчикам и делятся своими внутренними принципами, которыми они руководствуются при создании продуктов. Для примера изучите статьи Принципы лидера в Амазон или Как работают инженеры в Револют. Как видите, единого понимания нужных навыков мидла нет, потому что нет такого набора, который подойдёт любой компании.  Углубитесь в свой стек. Для освоения стека React необходимо обладать хорошим пониманием компонентного подхода, внутренних концепций фреймворка, а также различий между функциональными и классовыми компонентами. Я бы добавил сюда понимание жизненного цикла компонентов, влияния его на перфоманс приложения, и навыки это оптимизировать.  Информации о фреймворках в сети достаточно много, так что я не буду останавливаться на конкретных ресурсах, но сошлюсь на официальную документацию — это всегда наилучшая отправная точка, чтобы начать или продолжить углубленно изучать фреймворк. Кроме того, мне лично нравится ютуб-канал Джека Херрингтона: он много рассказывает про реакт, но не только про него.  Немаловажно следить за ченжлогами вашей библиотеки — даже с минорными версиями может появится что-то интересное или важное. Но я не рекомендую бесконтрольно апгрейдить версию в рабочем проекте, это стоит делать осознанно и с конкретными целями — закрыть уязвимости, улучшить перфоманс, начать использовать новые API и т.п. Javascript. Важно глубоко понимать концепции языка. Я отнесу сюда понимание того, как работают функции в JS, области видимости, контекст. Важно понимать, как работают прототипы и конструкторы, классы и наследование. На практике вы можете долго не сталкиваться с этими вещами, например с наследованием в JS. Но знание концепций даст глубокое понимание вашего инструмента, а значит, и открывает больше возможностей для вас как для специалиста.  Ещё важно понимать, как работает асинхронность в JS, знать про основные способы работы с сетевыми запросами и базовый Node.js. Не буду оригинальным и рекомендую соответствующие разделы на всеми любимом ресурсе learn.javascript.ru Я нежно люблю книгу «Секреты JavaScript Ниндзя» Джона Резига. Читал её в первом издании, уже вышло второе на русском языке, и я отчаянно рекомендую её к прочтению.  Кроме того, выпускается второе издание серии книг You Don’t Know JS Кайла Симпсона. Они на английском языке, но английский язык также можно отнести к необходимым навыкам программиста и изучать вместе с прочтением книги :D  А начать мягкое погружение в продвинутый Джаваскрипт можно с одноименного видео на ютуб-канале Фронтенд. Инструменты разработки. Важно не только знать, как работает JS, но и как из всего многообразия инструментов разрабатывать приложения. Сюда я отнесу и подходы к написанию CSS — CSS Modules, Styled Components, Tailwind, pre- и post-процессинг. Не нужно учить наизусть, лучше просто знать про подходы и как они выглядят. TypeScript. Можно ли считать его стандартом в индустрии или нет — вопрос открытый. Однако используется он с каждым днём все шире и шире: сейчас сложно найти проект, где нет TypeScript. Кроме официальной доки есть неплохой ресурс learntypescript.dev.  В сети полно русскоязычных материалов, например на Хабре. Кроме того, мягкое погружение в TS можно начать с видео из вышеупомянутого ютуб-канала про типизацию. Но наилучшим способом освоения тайпскрипта всё-таки является постоянная практика! Инструменты и протоколы клиент-серверного взаимодействия: axios, FetchAPI, XMLHTTPREQUEST, GraphQL — и понять, в чём же различие, плюсы и минусы. Где-то здесь рядом тема про безопасность и CSRF / CORS. Браузер и жизненный цикл вашего кода в нём. Важно хотя бы раз прочитать или узнать о том, как браузер вычисляет, строит и рендерит то, что мы наверстали и запрограммировали на JS. Это позволит не только блеснуть знаниями на собеседовании, но и широко взглянуть на продукт, который вы делаете, обнаружить слабые места в своем коде.  Очень люблю серию статей “Critical rendering path” от Ильи Григорика. Они достаточно детально рассказывают про то, как браузер строит страницу:   https://web.dev/critical-rendering-path/ https://web.dev/critical-rendering-path-constructing-the-object-model/  https://web.dev/critical-rendering-path-render-tree-construction/  https://web.dev/critical-rendering-path-render-blocking-css/  Кроме того, есть отличнейшая статья «Как браузер рисует страницы» от Доки. Ну и бонусом — классный выпуск подкаста Запуск Завтра про то, как работает браузер. FrontOps практики. Это как девопс, но только для фронтенда. Во многом подготовка современного фронтенда может быть сложнее, чем некоторых бэкенд-сервисов. Мы должны подумать о совместимости с браузерами, о том, как будут упакованы и преобразованы наши стили и чем, как будут оптимизированы картинки. В какой момент запускать модульные тесты, а когда — скриншотное тестирование, запускаем ли мы линтинг кода локально на машине разработчика или уже в репозитории. Звучит достаточно монструозно и именно так выглядит в реальности. Однако стоит понимать общие принципы. Можно оттолкнуться от того, какую инфраструктуру вы уже используете — у GitHub есть GitHub Actions, для Gitlab – Gitlab CI. Документация GitHub Actions Документация GitLab CI/CD Нанимают за харды, а увольняют за софты. И речь здесь вовсе не про то, как быть славным парнем для коллег. В компании может считаться важным умение работать самостоятельно, а может — умение согласовать решения со всеми заинтересованными лицами. Достаточно интересно раскрывает эту тему vas3k в своей статье про софтскилы. Умение работать в команде — витальный скил для мидла. Именно поэтому на курсе «Мидл фронтенд-разработчик» в Яндекс Практикуме обучение включает в себя командный трек, во время которого студенты делятся на команды по пять человек и пилят проект вместе. Знания и умения разных фреймворков и технологий отличаются от компании к компании, так и набор необходимых софтов может отличаться. Однако есть вещи, которые будут полезны в любой компании, по крайней мере, не могу себе представить обратное. Уметь аргументировать свои решения и предложения и уметь спокойно выслушать коллег. Вообще, умение аргументировать — это показатель того, что вы понимаете, что вы делаете. Про виды аргументов, способы и правила можно узнать в статье Аргументация: что это, как строится, виды аргументов — как развивать навык аргументации в деловом общении. Уметь объяснять технические концепции «нетехническим» коллегам и транслировать их мысли и идеи в техническое русло. Вас не всегда будут окружать программисты. Вам придется взаимодействовать с дизайнерами, менеджерами, возможно — заказчиками. Зачастую может случиться так, что управлять проектом могут назначить человека, который никогда ничего не разрабатывал. Во всех этих ситуациях наша задача – продолжать обеспечивать результаты разработки. А значит, придётся преодолевать этот барьер. Уметь формировать и принимать фидбек, в том числе на код-ревью, а также умение принимать и работать с фидбеком на свою работу. Иногда вам будет казаться, что кто-то не прав. Иногда он будет действительно не прав! Более того, не правы будете вы, и нужно быть к этому готовым. Наша же задача — обеспечить максимально продуктивное взаимодействие, безопасное, от которого не хочется защищаться или прятаться, а значит, результаты не будут страдать, а профессиональные компетенции будут расти. Классный материал про то, как давать обратную связь, — в нем перечислены несколько шаблонов: Гайд по фидбеку: как давать и принимать обратную связь. Уметь вовремя сообщать о сложностях и проблемах команде, лиду или менеджеру. Не всегда приятно признавать, что ты застрял. Но когда проблемы обнаруживаются и обсуждаются вовремя, команда может сосредоточиться на их решении до того, как они превратятся в серьёзные затруднения и повлияют на сроки. Помощь руководителя. Если вы работаете в крупной компании с выстроенной HR-стратегией, линейкой грейдов и понятными процессами развития сотрудника, то вам всего лишь нужно поговорить со своим руководителем. Смело обратитесь к нему с вопросами о том, как он оценивает ваш уровень сейчас и как вам его вырастить в рамках компании. Скорее всего вы получите исчерпывающий фидбек и рекомендации о том, какие стороны нуждаются в развитии. Стоит помнить, что это развитие в рамках компании, ведь именно компания определяет, соответствует ли ваш уровень ожиданиям команды. Личная ответственность. Если в вашей команде или компании пока нет механизмов с четко описанными грейдами и набором скилов к ним, то вы можете самостоятельно расширять  компетенции. Берите на себя задачи, связанные с разработкой крупных модулей и компонентов. Ваша задача — понять, зачем они разрабатываются, какие метрики могут быть у этих задач. Вы можете стараться обнаружить слабые места, потенциальные сайд-эффекты на другие модули. Вы не просто будете применять набор технических знаний из пунктов в начале статьи, но и увеличите насмотренность, поймёте, как работает продукт, и усилите вашу роль в компании. Ментор. Один из очень сильных инструментов роста — помощь наставника. Он сможет делиться с вами опытом и практиками, которые он использует ежедневно в своей работе. Это не самый легкий путь, так как ментор не только должен обладать опытом и экспертизой, но и подходить вам по характеру, чтобы создать доверительные отношения, нацеленные на ваше развитие. Ментор не будет давать вам готовые решения или делать задачи за вас, но поможет направить, провалидировать источники или подходы, словом, даёт карту и помогает по ней продвигаться.  В Яндекс Практикуме все менторы — это работающие специалисты из разных компаний, у каждого за плечами богатый опыт. Они делятся реальными ситуациями и кейсами. Например, я, проводя ретроспективу по итогам спринта в команде, где никто из студентов раньше не участвовал в таких мероприятиях, могу рассказать, как проходила последняя ретроспектива у меня и какие моменты мы с моей командой обсуждали. Opensource. Участие в опенсорсе помогает прокачать насмотренность, подтянуть опыт и развить гибкие навыки, научиться новому, познакомиться с актуальными практиками. Есть очень классное мероприятие под названием Hacktoberfest — это событие, которое проводится каждый год в октябре с целью сделать популярным участие в разработке opensource-проектов. Участники приглашаются внести свой вклад в открытые проекты на платформе GitHub, выполнив минимальное количество пулл-реквестов. За участие в Hacktoberfest и выполнение задач участники получают различные награды, такие как футболки и стикеры. Pet-проекты. Не только личные, но и с участием коллег или друзей. Не всегда удастся освоить лучшие практики, но позволит попробовать технологии.  Например, вы фронтендер на Vue и пишете классическое SPA на своей работе. У вас есть возможность попробовать написать решение, не меняя кардинально стек, но с использованием подхода SSR и SSG. Тогда вы сможете смело положить в резюме опыт с Node и, например, с Nuxt. Собеседования. Периодически проходить собесы — это достаточно непросто и может добавить стресса. Но если отнестись к этому как к источнику нового опыта, то можно почерпнуть для себя много важных вещей: пробелы в знаниях, детали использования технологий в других компаниях. Мы обсудили, что должен знать и уметь начинающий мидл фронтенд-разработчик. Мы прошлись не только по технологиям, но и по некоторым навыкам из разряда софтскилов — о них не стоит забывать, ведь это то, что делает вашу работу эффективнее.  Вы наверняка найдете, что можно добавить, а что убрать из статьи, и скорее всего будете правы, ведь для любого случая требования всегда будут уникальными и особенными. Если вы понимаете, что в статье не хватает каких-то пунктов или некоторые из них –– лишние, это замечательно и очень этому рад. Это означает, что у вас есть образ желаемого результата и вы знаете, куда нужно двигаться именно вам!