Рубрика «Кем работать в IT» — интервью с представителями IT-профессий, в которых специалисты рассказывают о тонкостях своей работы: плюсах, минусах, подводных камнях и заработной плате. Мы надеемся, что джунам и стажерам она поможет больше узнать о том, что их ожидает на карьерном пути, а профессионалам — посмотреть на свою специальность через чужой опыт и, может быть, открыть для себя что-то новое. Сегодня о своем опыте работы нам расскажет Роман Гриневич, Lead Backend Developer в ГК «Астра».  Чтобы узнать среднюю зарплату бэкендера в разрезе классификаций, языков, навыков и городов, вы можете воспользоваться зарплатным калькулятором Хабр Карьеры.  На текущий момент продукт переживает стадию активного развития. Всё это сопровождается существенным ростом команды. Поэтому основное моё занятие сейчас — это координация команды по задачам, определение способов решения бизнес-задач (декомпозиция и детализация), помощь новым сотрудникам в исследовании кода и компонентов продукта, код-ревью и мерджи. Однако стараюсь выделять не менее 30% рабочего времени на такое удовольствие, как работа с кодом. Высшее техническое. Окончил Зеленоградский МГИЭТ-ТУ, специалистом (еще успел, сейчас пятилеток уже нет). Выпустился в шикарную дату 06.06.06. По специальности я поработал в дочке Motorola, проектировал микросхемы, так что на «программиста» учился самостоятельно. Однако образование пригождается в системном подходе к задачам и дает понимание «как это работает на железе». Микросхемы в Зеленограде — это исторически сложившееся направление. Более того, это у нас семейное. Изначально учился в лицее, который взаимодействовал с институтом. Успешное окончание лицея — поступление с минимальными сложностями в МИЭТ. Именно проектирование микросхем как факультет заинтересовало меня уже в процессе учёбы, поскольку в институте увлёкся паяльником и программированием на ATmega (нынче эти камни в ардуинах). Первая моя работа — админ в лицее. Устроился спонтанно. Как-то пришел к учителям информатики, с которыми хорошо дружил еще во время учебы. Завязался разговор о том, что старый админ уходит, а к новому году поставляют 4 класса новых машин — тогда я и загорелся «поиграться» с новым железом. Собеседование получилось неклассическое: мне позвонил друг, которому я раньше преподавал программирование (был такой этап в студенчестве, когда я подрабатывал репетитором). Он устроился админом на новый небольшой склад, где ребята хотели свою систему: готовые не подходили из-за специфики работы. Меня спросили: «Ты ж программист, сможешь нам сделать?» Я ответил: «Конечно».  Я оценил перечень действий, этапность и подтвердил: что да, это по силам, но мне нужен еще человек в команду. В итоге эта ситуация позволила мне приобрести важную компетенцию — выработать подход в общении с заказчиками, которые не особо разбираются в подкапотном пространстве IT, а иногда и не знают, чего именно хотят. Кроме того, уже тогда я научился решать задачи бизнес-класса (без детализации в решении), строить архитектуру и понимать, что именно и как можно решать. Я больше практик, чем теоретик: не переношу академических знаний (и на собеседованиях спрашиваю кандидатов именно понимание сути). Поэтому те несколько собеседований, что я «провалил», были как раз с запросами терминов, описаний и подобного. Как самоучка, без профильного образования, я до сих пор теряюсь в некоторых «программистских» терминах и не гнушаюсь гуглить какие-то функции, которые редко использую. Совсем первая — рублей 500 — еще в школьные годы подрабатывал уборкой территории. В IT — первая «взрослая» работа админом на полставки 3+ тысячи рублей (2002 г.). Когда я работал админом (по совместительству еще делал сайт лицея), друзья иногда подкидывали мне разные проекты, типа «сделать сайт» — так я все больше погружался в веб-разработку.  Интересной альтернативой был проект разработки и реализации автоматики для ворот на промышленном комплексе. Я неплохо тогда заработал на «черных коробочках». Они делали из нескольких независимых ворот полноценный шлюз, который не запирал человека между ворот (в отличие от готовых аналогов). Когда мне предложили с нуля собрать систему управления складом, я понял, что это моё: мне интересно делать полноценные АИС на вебе. Сегодня попасть в IT стало проще: множество компаний предлагают свои программы обучения по разным специализациям. Сейчас на Хабр Карьере опубликовано более 150 курсов для тех, кто хочет изучить бэкенд. Программы разные: как для опытных специалистов, так и для тех, кто хочет попасть в профессию с нуля. Перед текущим местом работы я осознанно устроил себе «отпуск» — уволился с прежнего места и полтора года посвятил себе, семье и редким проектам «для души» — надоело мотаться в офис и жить в режиме челнока (живу за городом).  Перед выходом из отпуска собрал перечень компаний, которые удовлетворяли моим запросам: удалёнка, белый оклад, полностью российская компания, перспективное направление, польза для общества. На собеседовании в основном общались про бизнесовые задачи, душевно поговорили. В тех.части собеседования — сразу нашёл общий язык, было приятно вспомнить практический базис. Очень понравилось, что взгляды собеседующих совпадали с моими: и в целях, и в реализации.  Меня зацепила возможность разрабатывать российский стек, впечатлили амбиции и технический уровень команды — то, к чему я и стремился при поиске работы. Да и темпы роста «Астры» тоже говорили о возможностях «раскрыться на полную катушку». Я понял, что здесь я точно смогу найти применение своим знаниям, влиять на развитие продукта и, вероятно, продвигать свои идеи. Так и получилось: в команде приветствуется «накидывание идей»: как еще можно улучшить, расширить и развить продукт. Поскольку я начал работать в разгар ковида, проблем с коммуникацией не возникало — я и до этого работал по проектам с заказчиками «через зум». Единственная, наверное, непривычная вещь для меня, не работавшего до этого в полноценных командах, — это полный цикл разработки: от постановки задачи до закрытия. Работая до этого универсалом, я сам ставил задачи, решал и проверял их. Тут же я мог смело положиться на QA, которая скурпулезно выискивала ошибки и не пропускала их в продукт, — это было приятным нововведением в моей работе. Я довольно недурственно разбирался в операционках, полностью знал весь популярный стек разработки на питоне, поэтому уже на третий день начал закрывать задачи. Кроме того, я знал, как правильно выстраивать архитектуру и продукта, и процессов в команде. Получилось, что я, взяв горячие задачи, начал указывать на статусах «ожидаю такую-то задачу», «попросил реализовать в приоритете», «сделал механизм, теперь можно быстро тиражировать», «скоро потребуется вот это, нужно заложить в план» — таким образом, довольно быстро стал негласным организатором работы бэков.  В дальнейшем как самому опытному в питоне ко мне пришли задачи код-ревью, мерджа в дев/мастер, отслеживания статусов в баг-трекере. В тот момент увидел, что в «мастер» ранее попадали коммиты с архитектурно-неверным кодом («детские болячки» разработчиков, работающих по проектам: быстрее закрыть, не задумываясь о последствиях). Начал наравне с QA, анализирующей логику, проверять (и иногда отбрасывать в работу) задачи по коду: потенциально опасный, неоптимальный, «не в том слое» и т.п. Код шёл в доработку с моим комментарием зачем/почему/как лучше.  Таким образом начал подтягивать культуру кода и скилы разработчиков. Параллельно ввел культуру работы с задачами: в треке задачи стало довольно прозрачно видно, кто что сделал перед следующим этапом работ по задаче, появились ответы для QA при пинг-понге (отладка между статусами «в работе <-> на ревизии»). Тут, кстати, можно обратить внимание на самовосприятие разработчика в команде: необходимость активно взаимодействовать с QA в процессе работы (а в дальнейшем со всей командой) погружает человека в процессы и жизненный цикл продукта; именно такой подход я выработал для себя (даже поработал грузчиком и оператором на складе, чтобы опробовать свою АИС «в жизни»). Если же не поддерживать общение с командой, разработчик может уйти в простое «выполнить по ТЗ», не понимая, зачем это нужно, к чему приведет и как можно это улучшить. Отчасти проблему решают ежедневное общение, популярные по большинству стратегий разработки, но и примитивные тикетные комментарии тоже дают общую погруженность в процессы. Через 2-3 месяца начал детально ощущать силы бэков в команде, поскольку работал с их коммитами, видел скорость и качество выполнения задач. Обмолвился тимлиду про то, что один из разработчиков не справляется с нагрузкой (парень пропадал на день-два и тянул простые задачи по несколько дней), приходилось забирать его задачи или просить кого-то из ребят перехватить их — мне доверили проведение собеседований.  Это позволило мне выйти в позицию планирования и реализации работ: я получил расчетные этапы жизненного цикла продукта на ближайший год и понимал «чего и сколько»: каких компетенций не хватает, что может подождать или что мы можем закрыть текущим составом. Так постепенно я вышел в лида бэков. Когда начался активный рост команды, был ИО техлида, но не справился (не очень люблю работу с документами, не моё) — вернулся к лид-бэку. Требование было простым при поиске, и я не исходил из «минимум-максимум, а там как предложат». С учетом удалёнки, компетенций, цвета зарплаты и еще нескольких факторов — рассчитал (и получил) комфортный мне оклад. Раз уж зашла речь о трудоустройстве — сейчас на Хабр Карьере около 800 вакансий для бэкендеров. Сотрудников ищут Иннотех, Сима-ленд, Bell Integrator, VK, TextMagic и много других компаний. У ГК «Астра», где работает Роман, тоже есть открытые вакансии для бэкендеров. Замечательный вопрос. Если просто «попасть» — стандартный набор любого курса «питон за 5 минут/месяц/год» и т.п. Обычно такие курсы подразумевают практику — это более полезный навык, чем сухое знание: показывает возможности применения стэка, подводные камни, дает уже владение не языком, а набором технологий. Однако, на мой взгляд, еще полезнее уметь мыслить нестандартно, строить абстракции, смотреть на картину со стороны: иногда задачу не надо решать, изобретая велосипед: достаточно использовать готовую утилиту.  Софт — это в первую очередь ответственность и самодостаточность (насколько это возможно). Хороший сотрудник тот, кто может поспорить о подходах в реализации задачи, сформулировать и задать вопросы, прогнозировать последствия решения локальной задачи. На мой взгляд, это касается всех: от джунов до сеньоров — умение правильно сформулировать вопрос, спланировать свою работу (соответственно, понять, что и как делать), учесть подводные камни, увидеть риски. Харды — это знание подкапотного пространства языка, понимание принципов работы. В наше время обилие библиотек и гугл сводит решение большинства задач к работе с конструктором, но понимать, как это собирается вместе и как работает, всё равно нужно. Такой подход, кстати, позволяет легко и быстро подстраивать «внутренний компилятор» под любой язык программирования (т.е. общение с машиной). Для начала классика: определиться, нужно ли тебе это вообще и зачем. Как ни попсово звучит, но кем ты себя видишь через 5 лет. Это поможет сориентироваться в направлении. Всё как с абитуриентом: какие навыки ты хочешь получить и как применять? Вопрос в деньгах — смотри ценник вакансий IT. Цели — возьми листик и распиши то, что интересно, найди продукты/компании, которые этим занимаются.  Определи ключевые технологии, которые светятся в вакансиях и описаниях продуктов/компаний. Дальше — вопрос техники: гугл, курсы, практика. В идеале — придумать, что по этой теме можно сделать самому для личного использования (пусть это будет изобретение велосипеда). Реализовать собственный локальный проект дома (пусть кривой, с костылями, но свой).  Не смогу ответить на первый вопрос: для каждого набор будет индивидуален, в зависимости от потребностей. Определить направление, поискать варианты, посмотреть отзывы и приступить. И главное — практика: сухие знания, которые не прошли через ваши пальцы, навыком не станут. Относительно возможностей: тут всё просто и сложно, как мы любим. Оба последующих варианта совместимы. Если ты хочешь «просто работать и получать прибыль», достаточно закрыть базовые компетенции разработчика и в дальнейшем развивать их. Это приводит к финансовому росту, хоть и с ограничением по планке. Тут в помощь — обилие тематических каналов как для развития текущего инструментария, так и для поиска новых направлений.  Дополнительно стоит изучить примитивные (но работающие) инструменты управления потоком работы: помидорки, организация дня (и дня в пределах года, поскольку время года влияет на продуктивность), перебрать, наконец, различные IDE и найти что-то по душе. Если есть потребность к карьерному росту, необходимо подтягивать свои компетенции из других областей и перенаправлять их на работу: ходишь в горы — хорошее чувство команды; сам занимаешься ремонтом авто/недвижимости — планирование и проектирование; есть опыт управления отелем — работа с заказчиками и подчиненными; есть дети — эмпатия и детализация задач; работал в техподдержке — интуиция на потенциальные ошибки и т.п.  Ищи то, что не связано напрямую с кодом, но помогает в организации своей и чужой работы, в т.ч. во взаимодействии с заказчиком. Тут появляется множество ролей: от пафосного «отец/мамаша команды» до тонкого «решала» или «дружище». Такие роли обычно подразумевают «универсальную боевую единицу», которую организация может использовать для решения разного рода задач, что, опять же, будет повышать твои компетенции не только в разработке. Мы часто слышим от специалистов на Хабр Карьере вопрос: как понять, что я уже сеньор? Или: что мне нужно сделать и освоить, чтобы вырасти до миддла?  В каждой статье рубрики мы разбираем новую специализацию и показываем карьерный трек. Это инфографика с навыками, задачами и условиями работы, разбитыми по квалификациям. Вот такой трек по бэкенд-разработке нам помог составить Роман из ГК «Астра» — не путайте данные с реальными вакансиями или зарплатами в компании. Наши соцсети: ВКонтакте, Telegram, Twitter.  Помогаем строить карьеру в IT