Всем привет! Я Дима, начинающий разработчик. В статье расскажу о своем первом опыте работы в крупной продуктовой IT-компании.

Я пришел в ЮMoney полгода назад, когда мне было 19 лет. А сейчас набрал достаточный опыт, чтобы рассказать про жизнь backend-разработчика в компании.

Как я устроился в ЮMoney

Изначально я отправлял отклик на junior-разработчика на сайте вакансий. Ждал две недели, но приглашение на собеседование так и не получил. Скорее всего, не прошел первичный отбор по опыту и хард-скиллам. Тогда я решил написать письмо лично HR.

Контакты нашел в корпоративном аккаунте ЮMoney на Хабр. Ранее я читал статьи из блога, был знаком с устройством компании, поэтому было несложно описать, чем меня зацепила вакансия. К письму приложил ссылки на GitHub с учебными и pet-проектами. Личное общение действительно сработало! Сообщение сразу переслали HR, ответственному за собеседование джавистов.

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

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

Первое техническое интервью - это разговор с HR и старшим разработчиком. Мы познакомились, я рассказал о себе. Далее перешли на техническую часть — мне задавали вопросы по Java Core, Spring, структурам данных и алгоритмам, базам данных, паттернам разработки. Разговор был свободный: мы сразу перешли на «ты». В конце собеседования я расспросил про стек. Убедился, что команда на самом деле использует весь инструментарий, о котором говорилось в вакансии.

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

На финальном этапе мы с руководителем отдела backend-разработки и ведущим разработчиком обсуждали мою реализацию. Интересно, что интервьюеры на первом и финальном этапах отличаются, чтобы новичок получил объективную и всестороннюю оценку.

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

Итак, я успешно прошел последний этап и попал в ЮMoney: здесь начинается мой путь адаптации.

Адаптация

Я пришел в разгар пандемии, когда вся компания работала на удаленке. Адаптация новичков была заточена под онлайн-формат. Так как я работаю в backend-отделе, буду рассказывать об адаптации со стороны Javа-разработчика.

За мой онбординг отвечали:

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

2. HR - менеджер, курирующий процесс найма. Это та самая сотрудница, что ответила на мое сообщение

3. Руководитель отдела разработки серверных решений. Я общался с ним на собеседовании, успел перейти на «ты», поэтому не боялся задавать рабочие вопросы.

Наставник играет важную роль в процессе адаптации. Вот с чем он помогал:

• рассказывал про процессы отдела,

• делился полезными ссылками,

• оценивал первые достижения,

• показывал точки роста - куда мне развиваться, а не просто закрывать задачи,

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

HR рассказывала, как устроена компания и помогала с любыми рабочими и организационными вопросами.

Во время адаптации мне помогли следующие ресурсы:

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

2. Личный кабинет в 1C. Здесь я могу сделать электронную заявку на отпуск, обучение, тимбилдинг, изменить реквизиты для получения зарплаты. На формах минимум полей для заполнения: минимум бюрократии и максимум удобства.

3. «Универ» — корпоративный портал для обучения сотрудников. Сюда загружены техтолки, митапы, курсы и тренинги в формате видеоуроков, тестов, статей. Я записался на курс по Kafka, чтобы прокачать хард-скиллы, которых не хватало на старте.

4. Wiki — наша внутренняя Вики, в которой можно разузнать о каждом рабочем моменте. Например, здесь хранится Книга новичка, которая помогает ориентироваться в процессах компании.

5. Книга разработчика backend-отдела — здесь вся нужная техническая информация для разработки: конвенции написания кода на Java, рекомендации по работе с БД, устройство нашего мониторинга и трассировки и много другого.

6. Книга отдела backend-разработки — здесь информация по процессам разработки: какие внутренние собрания есть в отделе, какое обучение как Java-разработчик я пройду, как происходит продвижение по карьерной лестнице.

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

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

В первое время я трудился в команде Backend-платформы, ответственной за поддержку базы для микросервисов и CI/CD. Так на новичка меньше давят сроки и проверяется его спектр знаний, ведь задачи в команде технически ориентированные.

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

В ЮMoney два больших направления — B2C (электронный кошелек) и B2B (РКО - ЮKassa). После адаптации мне предложили выбрать наиболее близкое направление. Мой выбор учли при назначении команды: так я попал на разработку B2C-продукта. Отмечу, что при желании я могу свободно перейти в другую команду, если почувствую, что слишком засиделся на месте и хочу «потрогать» чего-нибудь нового.

О жизни в компании и команде

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

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

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

1. Грумминг (раз в 2 недели) — оцениваем задачи в Story Point.

2. Планирование спринта (раз в 2 недели) — данная встреча обычно следует сразу за груммингом. На ней мы решаем, какие задачи, уже оцененные в Story Point, мы берем в следующий спринт.

3. Встреча по бэклогу (раз в 2 недели) — разбираем бэклог, выбираем из него задачи в следующий спринт.

4. Ретроспектива (раз в две недели) — анализируем результаты прошедшего спринта, обсуждаем, что можно улучшить, а что мы сделали хорошо.

5. Daily (каждый день) — встреча на 10-15 минут, где мы рассказываем, что успели вчера, что сделаем сегодня, какие есть проблемы, и все ли идет по плану.

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

Внутренняя кухня backend-отдела

Начнем со стека — у нас он вполне современный:

• Java 11 — Ждём выхода LTS версии Java.

• Gradle, Jenkins — CI/CD у нас построен на основе данных инструментов. Кому интересно, часть инструментов доступна на GitHub: https://github.com/yoomoney-gradle-plugins.

• TestNG, Mockito, WireMock. Также у нас собственная библиотека для улучшения процесса написания тестов.

• SpotBugs, Checkstyle, JaCoCo — не забываем про статический анализ.

• Spring Core, Spring JDBC, Spring MVC, Spring Boot;

• REST, JSON, OpenAPI;

• PostgreSQL, Jooq, Flyway, ElasticSearch, Kafka;

• BitBucket, Jira, Confluence — для BitBucket и Jira у нас множество самописных плагинов, которые облегчают работу. Например, на основе решений Atlassian построен автоматизированный релизный цикл — он выполняется полностью через интерфейс Jira и BitBucket без помощи CLI.

• Ansible, Grafana, Kibana, Moira, Zabbix, Zipkin.

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

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

1. Настройка БД — инструменты для доступа к БД, включая шардирование.

2. Логирование — автоматическое логирование тела и ошибок HTTP запросов-ответов.

3. Мониторинг — автоматические пуши в систему мониторинга. Позволяют следить из Grafana за входящими и исходящими сетевыми запросами, состоянием пулов потоков приложения и Tomcat, хоста, пулов соединений и запросов к БД, JVM.

4. Трассировка — реализация на основе Zipkin. При межсервисных запросах к каждому сообщению в логе прикрепляется traceId. Он позволяет проследить за всеми действиями, инициированными HTTP-запросом, включая межкомпонентное взаимодействие.

5. Периодические очереди и планировщики задач — у нас собственная реализация очередей, разработка которой ведётся на GitHub: https://github.com/yoomoney-tech/db-queue.

6. И множество другой функциональности, облегчающей жизнь разработчику.

Встречи и собрания

Как backend-разработчик я посещаю следующие мероприятия внутри отдела и в компании:

1. Backend Hural — ежемесячная встреча на 30-60 минут. На ней руководитель рассказывает новости отдела, синхронизирует задачи, координирует процессы, инструменты и технологии.

2. Backend Sync — еженедельная встреча по пятницам на 15-30 минут. Здесь говорим о событиях в отделе и компании, получаем обратную связь. На встрече каждый может задать вопрос руководителю отдела напрямую.

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

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

Персональное ревью

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

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

Опрос 360

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

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

Результаты опроса 360 принимаются во внимание при продвижении по карьерной лестнице.

Планы на будущее

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

Приходите в нашу компанию, у нас весело! Если у вас остались какие-либо вопросы, пишите в комментариях, я буду рад поделиться своим опытом.