Путь в ИТ: фронтенд-разработчик

Меня зовут Дима, мне 34 года, я руководитель команды фронтенд-разработчиков в Т⁠-⁠Банке.

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

Как такового образования в ИТ-сфере я не получал, даже не проходил курсов. Учился опытным путем, много гуглил. Базовые книги для программистов и учебники для чайников я, конечно, освоил, но в основном плыл по течению. Помню, у меня была и книжка по HTML, бумажная, кто-то когда-то мне подарил, и я ее долго изучал.

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

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

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

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

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

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

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

Популярные языки фронтенд-разработки — HTML, CSS, JavaScript. HTML позволяет создавать веб-страницы и приложения для любого браузера, но в современных системах нужны и JavaScript, и CSS, плюс большое количество библиотек и фреймворков и умение выбирать нужные языки и приемы под задачи конкретного проекта. Все эти языки не альтернативы друг другу, а используются для разных целей. HTML необходим для разметки страницы, CSS — для стилизации, JS — для интерактивности. Хочешь стать фронтендером — учишь все.

Я родился, вырос и получил образование в Москве. Окончил обычную, хотя и хорошую, среднюю общеобразовательную школу № 1285 с углубленным изучением английского языка. Меня интересовали естественные науки: химия, биология, физика.

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

Семья уговорила меня пойти в медицину. Я поступил в Московский государственный медико-стоматологический университет имени А. И. Евдокимова на лечебный факультет.

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

С четвертого курса я посещал студенческий кружок по глазным болезням, где мы разбирали разные интересные случаи из практики. Наблюдая за микрохирургическими операциями на глазах, я думал, что именно этим и хочу заниматься. Потом я поступил в ординатуру на кафедру глазных болезней ФПДО, которая базируется в НИИ им. Гельмгольца, где пришлось плотно взаимодействовать с пациентами в ходе поликлинической практики. За несколько месяцев стало понятно, что в жизни мне нужно что-то другое.

Еще на первом курсе ординатуры мой приятель, с которым мы занимались упомянутым сайтом, предложил открыть веб-студию. Я согласился, проработал в ней почти два года, с 2014 по 2016. Мы занимались разработкой и продвижением веб-сайтов, ивентами и пиар-обслуживанием проектов.

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

Я писал в основном на PHP — по большей части создавал небольшие модули для готовых движков сайтов Wordpress и ModX, но были и более сложные проекты, для которых приходилось с головой залезать в Гугл, чтобы сделать фронтенд посложнее: хитрые калькуляторы, мудреные формы со сложным поведением и так далее. Для одного из заказчиков я, например, создал систему работы с клиентами, включавшую CRM, систему управления расписанием и генерации документации. Стек на бэкенде — PHP + MySQL, фронтенд был несложный, максимум библиотека jQuery.

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

Мой личный доход с 2014 по 2016 мог колебаться от нуля до нескольких сотен тысяч рублей в месяц — в зависимости от количества проектов. Ноль был результатом того, что все уходило на зарплаты сотрудникам, а каких-то новых выгодных проектов не появлялось.

Заказчики были самые разные — от строительных компаний до банков и учебных заведений, вот пара примеров: сайт для НОУ «Арт-алекс» и управляющей компании «Садко-финанс» — одной из дочерних компаний «Дил-банка», нашего постоянного клиента.

«Дил-банк» был нашим постоянным и самым крупным клиентом, мы делали сайты для его многочисленных дочерних компаний. Банк приносил нам львиную долю дохода, но в какой-то момент у него отозвали лицензию, он закрылся. По нам закрытие сильно ударило — исчезло 80% выручки.

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

Еще до поисков работы я начал изучать JavaScript, хотя занимался бэкенд-разработкой на PHP, а версткой — на HTML и CSS. Когда в нашей с другом компании стали появляться сайты с динамикой на фронтенде, захотелось научиться делать ее самому. Сначала я пользовался jQuery — относительно простой библиотекой для фронтенда. Но ее не хватало, поэтому я и взялся за JavaScript.

В изучении языка мне помог сайт learn.javascript.ru — «библия», известная каждому фронтендеру. Площадка помогла мне и с точки зрения подготовки к собеседованиям — я освоил почти все, что было на ней в свободном доступе, хотя там есть и платные курсы. Скажем, курс для новичков в 2023 году стоит 23 000 ₽.

Освоение информации и обучение новым навыкам мне всегда давалось легко, так что я быстро вобрал в себя нужную информацию и отправил резюме в пару компаний, одной из которых и был Т⁠-⁠Банк — сюда резюме я передал через знакомого.

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

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

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

Через пару недель после собеседования мне позвонили из Т⁠-⁠Банка, и я узнал, что мне одобрили кредитную карту. Это было не совсем то, что я ожидал, но предложением все же воспользовался. Спустя еще неделю я решил позвонить сам и вскоре после этого получил оффер.

Выходит, у меня в карьере было всего два собеседования: в Т⁠-⁠Банке и в ту другую компанию. По ощущениям, интервью в банк я прошел средне: показалось, не знал ответов на половину вопросов из теоретической части.

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

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

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

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

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

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

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

В Т⁠-⁠Банке кандидат, проходя собеседование, попадает в череду фильтров, в воронку.

Первый фильтр — отбор резюме рекрутером. Второй — отбор резюме из базы, набранной рекрутером. Резюме выбирает человек, который разбирается в специфике профессии и непосредственно интервьюирует кандидатов.

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

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

Рынок растет большими шагами. Мой личный доход за пять лет вырос в 7—8 раз. Стартовые зарплаты на разных позициях можно распределить так:

• джуниор: от 56 000 ₽;
• мидл: от 150 000 ₽;
• сениор: от 230 000 ₽.

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

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

За годы в Т⁠-⁠Банке меня помотало. Один коллега, который пришел в банк в одно время со мной, рос именно как разработчик, теперь он архитектор и руководитель кор-команды. Отвечает за разработку общих инструментов, которыми пользуются в работе другие команды в компании. Круто, но это не мой путь.

В компанию я пришел как джуниор в 2015 году. Оставалось несколько месяцев до запуска новой версии интернет-банка. Всего в Т⁠-⁠Банке тогда работало человек 40 фронтендеров, а в команде интернет-банка 15—20. Я оказался среди них.

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

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

С задачей подобного рода мне больше работать не приходилось. А вот глубже погружаться в архитектуру я начал спустя пару лет после прихода в банк. Тут недостаточно прочитать одну книжку, погуглить или изучить один сайт.

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

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

Тогда я не понимал, в чем заключаются обязанности лида, кем мне быть и что делать. Казалось, ты должен разбираться во всем, что делает команда и каждый отдельный сотрудник, проводить код-ревью, самому выполнять отдельные задачи, развивать процессы в команде. В 2017 я не был готов к такой нагрузке, к тому, чтобы правильно включиться в подобный процесс.

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

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

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

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

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

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

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

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

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

С момента перехода в команду ипотеки я ни разу не пожалел о своем решении перейти из разработчиков в руководители. Для меня это стало прекрасным временем знакомства с различными методологиями разработки и управления командами. В то время многие команды в Т⁠-⁠Банке работали (вернее, пытались работать) по Scrum, и команда ипотеки не была исключением. К самому скраму я вопросов не имею, проблема была в том, что никто толком не выстраивал этот процесс в команде, он сложился стихийно и был крайне неудобным.

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

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

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

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

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

Еще во время работы в команде ипотеки я начал читать лекции по фронтенду в Финтех-школе Т⁠-⁠Банк — это учебные курсы по аналитике и разработке, куда может прийти кто угодно. А в 2020 году стал куратором курса по фронтенду. В задачи кураторов входит составление программы, подбор лекторов и менторов и помощь им в подготовке, отбор студентов на курс, организация учебного процесса.

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

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

Со временем удалось формализовать процесс, создать пул интервьюеров, которые стали профессионально и унифицировано проводить собеседования.

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

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

Помимо работы в компании я занимаюсь организацией митапов. В 2019 я попал в организаторы MoscowJS, московского профессионального сообщества разработчиков на JavaScript. В роли организатора я занимаюсь поиском докладчиков, помощью с подготовкой докладов, работой с площадками, парочку митапов провел в качестве ведущего. Также помогаю поддерживать сайт сообщества.

В ковидную эпоху с офлайн-мероприятиями было туго, но делали что могли — экспериментировали с онлайн-форматами, проводили несколько круглых столов, пробовали запустить свой подкаст. В сентябре 2021 провели большую конференцию MoscowJS 50 в партнерстве с Т⁠-⁠Банком, я был ответственным за ее проведение с обеих сторон.

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

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