Привет! Меня зовут Кирилл, я студент 3-го курса НИУ МЭИ, направление — «Информатика и вычислительная техника», а также Junior Python Backend-разработчик в Альфа-Банке.

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

И я начал искать стажировки для backend-разработчиков.

Удивительно, но несмотря на обилие предложений статей от тех, кто «выжил» после стажировок в IT не так уж много. А вопросов много: «Как попасть?», «Что меня там ждёт?», «Как ко мне будут относиться?», «Как устроены процессы в больших компаниях? Можно ли совмещать с учёбой?», «Как теория лекций согласуется с практическими задачами?», «Смогу ли я узнать что-то новое (и научат ли меня?)», «В какую компанию компанию лучше подаваться?»

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

Дисклеймер. Я пишу для студентов и ребят без опыта работы. Если у вас большой опыт и вы не ищите стажировку в IT — вам, скорее всего, будет не интересно.

Не очень долгие поиски

Первый вопрос, который у меня возник, — «Где искать?» В основном, «предложения» я смотрел:

• непосредственно на сайтах компаний: Яндекс, Т-Банк, Альфа-Банк;

• какие-то вакансии предлагал ВУЗ;

• иногда заходил и на Хабр Карьера.

И как-то я обратил внимание на программу Альфа-Банка, которая называется Альфа-Будущее. Вакансии там размещаются не статично, а появляются и закрываются регулярно, поэтому нет такого, что ты воодушевился, отправил отклик на стажировку, ждёшь и потом случайно узнаёшь, что она давно временно закрыта, а плашка просто висит, «чтобы было».

Интересующая меня стажировка на тот момент была неактивна (на скрине пример, как выглядят неактивные стажировки) и я мониторил сайт раз в неделю.

И спустя пару недель увидел вакансию Python Backend, где кроме знания Flask требовалось умение работать с HTML, CSS и JavaScript.

И вот первое наблюдение — необязательно верстать всю ночь резюме в Word. Своё резюме я отправил просто ссылкой на «Хэдхантер». Его приняли без проблем. Да ещё и ответили через 10 минут.

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

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

Добавлю сюда базовый стек технологий backend-разработчика (Git, Docker, Kubernetes, Kafka, SQL) и небольшой опыт работы в стартапе. Но не стоит воспринимать мой опыт работы как обязательное требование — на самом деле, тот стартап мало чем отличался от хорошего пет-проекта, поэтому вполне можно заменить подобный опыт дополнительным самостоятельным проектом.

И вот через 10 минут после отправки письма с резюме я получил ответное письмо с тестом.

Стоит отметить, что в Альфа-Банке нет масштабного контеста, который характерен для других компаний. Здесь вам присылают короткий тест именно по выбранному направлению.

Однако тест я не прошёл и временно забыл про стажировку в Альфе.

Но...

Через месяц HR написал сам

Примерно через месяц после подачи резюме со мной связался HR из Альфа-Банка и предложил пройти собеседование на другую вакансию стажёра.

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

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

В этот раз вместо Flask в требованиях значился FastAPI, а также упоминался Apache Spark (как выяснилось позже, команда разрабатывала ML-Ops решения) и этот набор совпадал с моими навыками в резюме гораздо больше. Терять было нечего, я согласился, предварительно немного ознакомившись со Spark. К тому же формат работы был полностью удалённый, что помогло бы не забивать на учёбу (это был один из решающих факторов).

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

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

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

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

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

Техническое собеседование

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

На техническом интервью спрашивали, например, о плюсах и минусах FastAPI. Из плюсов я отметил встроенную асинхронность, наличие встроенной инъекции зависимостей, наличие Swagger и валидации Pydantic. Из минусов — отсутствие представлений, как, например, в Django. В целом этого ответа интервьюеру хватило.

Также затронули общие темы о Python, например, про примитивы асинхронности. Здесь я, признаюсь честно, ответил не полностью — из-за волнения всё вылетело из головы. Я указал про конструкции async/await, mutex и корутины. Как я после интервью уже узнал у интервьюера, идеально было бы отметить также таски, фьючеры и ивент-луп.

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

Отмечу, что у меня есть неплохой алгоритмический бэкграунд: тренировки от Яндекса, более 300 решённых задач на LeetCode, участвовал в соревнованиях от Codeforces. И даже с таким опытом, как я считаю, для оценки навыков разработчика такие задачи не нужны (!). По крайней мере, на собеседованиях. Но это отдельная тема для обсуждения.

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

Как я готовился к техническому интервью?

• Повторил базовые концепции Python (асинхронность, многопоточность, декораторы, генераторы, итераторы).

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

• Активно вёл диалог, задавал уточняющие вопросы.

• Потренировался на leetcode.com, codeforces.com, coderun.yandex.ru.

Через неделю я получил оффер в команду FeatureStore, занимающуюся ML-Ops, а через две недели — я уже вышёл на работу.

Работа началась с документации

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

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

Это была фатальная ошибка. Работа с документацией — это полноценные боевые задачи.

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

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

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

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

Что ещё я делал, как стажер?

Задачи не состоят только из «переписывания документации»

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

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

Необходимо знать про асимптотическую сложность алгоритмов, потому что решение в лоб займёт 200! итераций. Это очень много).

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

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

Все задачи на стажировке были настоящими (боевыми).

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

Описание задачи: «Написать проверки валидности репозитория ETL-проекта, которые запускались в отдельном потоке в рамках одного процесса».

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

• реализовал сами проверки,

• отдельно проверил их работоспособность,

• написал unit-тесты,

• а затем проверил работоспособность всей системы, проведя небольшое интеграционное тестирование.

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

Спектр задач был довольно обширный, а довольно гладкий scale сложности задач позволяет на стажировке стажироваться, а не смотреть в стену днями и думать, как решить эту задачу. Поэтому миф о том, что бэкендеры, а тем более стажеры, занимаются только «перекладыванием JSON-ов» — всего лишь миф (по крайней мере, в Альфе). Чего стоит один рефакторинг.

Описание задачи: «Рефакторинг кода»

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

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

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

Ближе к концу стажировки в связи с расширением функционала нашего продукта мне предлагают перейти на штатную позицию бекендера. Думаю из вступления понятно, что я ответил =).

Заключение

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

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

Спасибо за внимание и удачной стажировки!