2024-11-13 18:26 Карьера

«Я просто работал», или Как вырасти до тимлида за 3 года

Во второй части интервью с командой CosySoft мы поговорим с Сергеем – backend-разработчиком, который за три года работы в компании мощно прокачал свои навыки. Сейчас он возглавляет разработку кредитного проекта в крупном российском банке и управляет командой из 18 человек. Сергей расскажет о том, как начинал в IT, где получал образование и первый опыт, а также о том, как ему удается адаптироваться к роли тимлида.

Расскажи, каким был твой путь до IT и почему решил сменить направление?

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

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

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

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

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

Для первичного освоения навыков я выбрал курс JavaRush. Этот курс хорошо известен среди джавистов, и, думаю, многие, как и я, проходили его. Мне кажется, большая часть студентов там — это люди без профильного образования. Курс действительно хороший, и я бы до сих пор его рекомендовал для изучения базовых знаний. Он включает картинки, обсуждения, и очень активное сообщество, где можно найти ответы на многие вопросы, даже если еще не знаешь про Stack Overflow.

Когда заканчивал курс JavaRush, начал искать стажировки или работу для джунов, но в Тольятти таких возможностей было крайне мало. Вспомнил, как это часто бывает, о знакомых. Я когда-то работал в ресторане, и был там шеф-повар, с которым мы общались. Его жена работала рекрутером в IT-компании, и она упомянула, что у них запускается первый поток курсов по Scala для стажеров, с возможностью дальнейшего трудоустройства.

Честно говоря, сначала я сильно сомневался. Почитал про Scala и испугался, потому что даже с Java у меня были сложности, не говоря уже о новом языке. Но она все же уговорила меня попробовать. Я пошел на эти курсы и в итоге оказался единственным, кто их успешно закончил и получил работу в компании. Так что прошел курсы, получил оффер, и Scala меня затянула.

Какой опыт ты получил на первом месте работы?

В итоге, на Scala я работал относительно недолго. В компании подход был такой: какую фичу возьмешь, на том и будешь работать. То есть не все фреймворки были на Scala, и проекты распределялись по-разному. В итоге, за год в компании, примерно 4 месяца я работал на Scala, а остальные 8 — на Java.

Самое главное, что я получил в той компании — это, конечно, первый опыт. Он очень важен, потому что позволил мне попробовать несколько языков и поработать с разными фреймворками. Я познакомился с Akka, работая со Scala, и немного затронул Spring, когда работал с Java.

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

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

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

Как ты попал в CosySoft?

Моя знакомая рекрутер, которая устроила меня на первую работу, перешла в другую компанию. По долгу службы она предложила мне последовать за ней. Сказала: "Ты подрос, пора двигаться дальше". И я согласился. Я уже начал оформляться, но в какой-то момент они попросили подождать. Я растерялся: "Что значит подождать? Я уже уволился!". В итоге выяснилось, что компания решила уходить с российского рынка. К счастью, у меня было еще несколько предложений, в том числе от CosySoft. О чем ни разу не пожалел.

Помню, как HR CosySoft буквально затащила меня в компанию. Я планировал работать удаленно, но ее профессионализм меня впечатлил. Она была настолько настойчива, что смогла убедить меня, даже после того, как я уже принял другое предложение. Так я попал в CosySoft. И первое, что меня поразило, — это атмосфера. Офис с невероятным вайбом, все на контрасте с моей прошлой компанией, где была корпоративная культура с налетом токсичности. Здесь же сотрудники идут на работу с радостью. Я осознал, что работа может быть по-настоящему крутой и приносить удовольствие.

Это был непростой 2022-й год. Как прошли твои первые месяцы в Cosy?

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

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

Расскажи побольше о проекте

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

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

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

Все так, у нас нагрузка значительно ниже.

Однако сейчас перед нами стоят интересные задачи, связанные с платформенностью нашего сервиса. Они мне очень интересны, потому что они предполагают работу с WebFlux, обязательное прохождение нагрузочных тестов, выявление и устранение слабых мест в сервисе. Мы также будем реализовывать паттерны вроде circuit breaker и rate limiting, следить за RPS (запросы в секунду) и распределять квоты на них. Это уже совершенно другой уровень разработки, связанный с тем, что, помимо клиентов, наши сервисы используются другими модулями банка. Это создает дополнительные требования к надежности и масштабируемости системы, и я с нетерпением жду решения этих задач.

Расскажи о какой-нибудь наиболее запомнившейся задаче на проекте. Что тебе особенно запомнилось?

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

Задача заключалась в перенастройке деплоя проектов на стенды и переходе с одного Ansible-проекта на новый, включая работу с Ansible Tower — удобным UI-интерфейсом для управления деплоями в распределенных системах. Это особенно полезно в микросервисной архитектуре, когда приложение разворачивается на множество хостов с разными окружениями. Потрогать Ansible, понять, как работает CA/CD, перенастроить скрипты — это дало мне лучшее понимание всей цепочки доставки приложений на боевые серверы.

Переход с Mesos Marathon на Kubernetes тоже стал важным опытом. Mesos — это устаревший оркестратор, с которым мало кто работал, и его UI-фреймворк оказался крайне неудобным. Kubernetes, напротив, оказался более гибким и удобным. Я поработал с настройкой доступов, маршрутизацией трафика, прописал ингрессы — то есть, освоил базовые вещи, которые расширили мое понимание системы за пределами кода.

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

Не так давно ты стал лидом на своем проекте. Расскажи, как это произошло и как ты к этому пришел?

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

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

Сколько у тебя в команде разработчиков?

В моей команде не только разработчики. Разработчиков восемь — четыре фронтендера и четыре бэкендера. Помимо них, у нас есть три QA, четыре системных аналитика и два дизайнера. Всего сейчас в команде 18 человек.

Что входит в круг твоих задач, как тимлида?

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

Это твои повседневные задачи, а что еще входит?

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

Раскрой секрет, ты строгий тимлид или нет? По шапке даешь?

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

Многие, становясь лидами, открывают для себя новый мир с кучей трудностей. Как у тебя это было?

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

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

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

Как считаешь, какими качествами должен обладать хороший разработчик?

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

Ты согласен с тем, что хороший разработчик в некотором смысле является и аналитиком, который может самостоятельно погрузиться в бизнес-процессы и уточнить требования?

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

Какие советы ты мог бы дать коллегам для эффективного развития?

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

CosySoft