«Джуны не нужны»: есть ли рост в IT

Как выстроен карьерный рост в IT-сфере для Junior-разработчика? Вопрос «где взять специалиста с опытом работы 10 лет, знанием всего на свете, портфолио проектов от 10 штук, не старше 30 лет» будоражит ИТ-отрасль независимо от изменений рыночной конъюнктуры. Рассказываем, как реально обстоят карьерные дела в ИТ сегодня на своем опыте.

Вячеслав Володкович

Генеральный директор компании «Аэродиск»

Без джуна — ни туда, ни сюда

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

Как же стать мидлом или сеньором, если джуны никому не нужны?

Однако на деле все немного не так.

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

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

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

По опыту своей работы можно сказать, что оптимальные пропорции команды из 10 человек такие: 1 сеньор, 3-4 мидла, тогда как остальные 5-6 человек — именно джуниор-разработчики.

Скорее всего источником байки о ненужности джунов являются «самоучки».

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

Мотивация понятна, однако далеко не всегда она конвертируется в настоящую вовлеченность в профессию.

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

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

С места — в карьеру

Мы — разработчик и производитель систем хранения данных (СХД).

Существует стереотип, что решения такого уровня (базовые компоненты ИТ-инфраструктуры) создают многоопытные бородатые спецы, запускавшие ЭВМ еще в СССР.

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

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

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

Примеров — масса.

Вот один из них: разработчик Python без опыта системного администрирования Linux откликнулся на вакансию и пришел к нам.

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

Развитие началось с простых задач на Python: например, с помощью определенных библиотек создать запрос к операционной системе и получить ответ из разных системных утилит, преобразовать его и вывести.

На следующем уровне задачи усложнялись: с помощью методов, написанных на Python, обеспечить взаимодействие на уровне приложений и интерфейса управления СХД от конфигурации системы (сеть, диски), до логических групп хранения данных.

Да, ему пришлось перелопатить тонны документов и мануалов — например, по утилитам или по большим системам, но сотрудник демонстрировал упорство и получал поддержку команды.

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

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

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

Дорожная карта роста

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

Лучше начинать с работы в офисе, а не с удаленки. Так проще втянуться в процесс: есть возможность задать вопрос напрямую, посмотреть, кто как пишет код. Живой обмен опытом очень важен для младших разработчиков.

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

Пытайтесь получить как можно больше опыта. Деньги важны, но опыт, отточенные навыки, умение учиться и понимание того, как устроен сам процесс разработки — важнее. Инвестируйте больше в развитие, чем в накопительные счета в банке.

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

Так, если ты пришел как младший разработчик бэкенда на Python, не обязательно быть мидлом только по Python. Придется так или иначе изучать клиентскую часть: JavaScript, HTML и CSS.

На ошибках учатся — можно вот на этих

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

Первый: к нам на работу перешел очень серьезный разработчик с огромным опытом в отрасли, покинувший штат крупной западной ИТ-компании.

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

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

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

Формально задача выполнялась, но в разработке все дело в интегрируемости результатов твоего труда в общий продукт.

Здесь этого и близко не было: «мягкие навыки» отсутствовали как таковые, общее отношение к работе «Задачу поставили — вот решение, не нравится — ничем не могу помочь».

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

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

Второй пример – ровно обратный.

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

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

Мало того, то он писал очень сырой код, который очень не любил ни проверять, ни исправлять, за декларациями о нацеленности на рост и прогресс не стояло никакой практики.

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

Это также нередкий случай: но простых путей и легких денег нет нигде, в ИТ — и подавно.

Любые успехи – сумма вовремя и правильно приложенных усилий в верный момент.