Вакансия: ведущий бэкендер в Учебник (закрыта)

Привет! Меня зовут Вова, я руковожу разработкой Учебника Тинькофф Журнала.

Ищу к нам опытного бэкендера, который пишет на Python.

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

Бесплатные курсы помогают нам следовать нашей социальной миссии. А платные — еще и зарабатывать.

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

1. Сделать предзапись на курсы. Так студенты заранее больше узнают про курс, получат напоминалку в день выхода.
2. Полностью рендерить учебник на сервере. Сейчас так рендерим только уроки. Фронтендер учебника работает над серверным рендерингом остальных страниц, но, возможно, ему придется помочь с доработками АПИ.
3. Забрать управление уроками в движок Учебника. Сейчас уроки — модифицированные статьи Тинькофф Журнала. Это позволило нам быстрее запуститься, но теперь тормозит развитие.
4. Оптимизировать работу страниц, подгрузку изображений, время ответа АПИ и улучшить разметку.

Еще одна задача направлена на конверсию в продажи: дать возможность сначала оплатить курс, а потом авторизоваться.

Хотим со всем этим управиться до конца года, а там определим следующие этапы.

На бэкенде Python и FastAPI. В основном работать предстоит с двумя сервисами: движком Учебника и сервисом платежей. Клиенты общаются с сервисами по REST, для удобства подрубили Swagger. С другими сервисами они общаются по шине на Google Pub/Sub, но мы переделываем это на Кафку.

Иногда практикуем иннер-сорс: доработку чужих сервисов и принятие доработок от коллег.

Сервисы развернуты в Яндекс.Облаке. Там же крутятся managed-базы: Postgres и Redis. У нас настроены пайплайны на Gitlab CI, в которых запускаются MyPy, Flake, Black и тесты на pytest. Сервисы собираются в Docker и деплоятся с помощью ArgoCD в Kubernetes-кластеры.

По коммиту в фича-ветку поднимается динамическое окружение. Изменение мастера триггерит деплой на стейдж. По гит-тегу раскатывается прод, можно из фича-ветки.

Техническая команда делится на несколько продуктовых подкоманд, Учебник — одна из них. Всего нас: 20 фронтендеров/JS-фулстэков, 10 бэкендеров-питонистов, 4 мобильщика — RN-фулстека, 5 инженеров по тестированию, 2 инфраструктурных инженера.

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

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

1. Код-ревью, общее между разными направлениями.
2. Общие соглашения: в каком формате у нас логи, сколько апрувов на реквест необходимо и достаточно.
3. Инфраструктурные решения: что использовать как шину для асинк-общения между сервисами, где и как агрегировать логи и так далее.
4. Архитектурные решения: в каких случаях допустимо использовать синхронное общение между сервисами, какой способ общения станет предпочтительным.
5. RFC, ADR и другие полезные практики.
6. Добровольное парное программирование.

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

Бэкенд-разработчика, который:

1. Декомпозирует бизнесовую постановку на задачи. Продакт приносит диздок, макеты, пользовательские сценарии и иные подробности. Разработчик формирует из этого задачи себе и коллегам, указывает технические детали и оценивает трудоемкость.
2. Проектирует решения этих задач. Если нужно — рисует диаграммы, расписывает модели и потоки данных, пишет RFC-документы, применяет шаблоны проектирования.
3. Уверенно читает и пишет на Python. Проходит ревью сам, проводит код-ревью другим бэкендерам. При этом действует по правилу бойскаута: оставляет фрагмент кода, с которым поработал, лучше, чем он был. Все это — с использованием аннотаций и покрытием тестами.
4. Самостоятельно доталкивает задачу в продакшен. Доуточняет требования, использует результаты работы коллег, проходит тестирование у наших инженеров, сопровождает выкатывание на прод, рефлексирует над полученным опытом, двигается дальше.
5. Если потребуется, спроектирует новый сервис на знакомых технологиях по требованиям бизнеса, выделит MVP, заложит масштабирование в случае наплыва пользователей.

Если формально, то ожидаю, что кандидат:

• владеет стэком: Python, FastAPI, pytest, SQLAlchemy, Postgres, Redis, Docker;
• понимает, как работает веб, и умеет в проектирование систем: клиент-серверное взаимодействие, REST, особенности асинхронной работы, разница между реляционными и нереляционными базами данных, чистая архитектура, DDD;
• минимально разбирается в структурах данных, алгоритмах и их сложности: о-нотации, цикломатическая сложность, рекурсия, стэки, очереди, кучи, списки, графы.

Будет плюсом, если есть понимание, как работает Kubernetes, и в целом современного инфраструктурного стэка.

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

В списке задач тогда тоже прибудет. У нас роль тимлида предполагает, что он:

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

Можно рассчитывать на:

1. Корпоративное трудоустройство. Белая зарплата, рабочая техника, ДМС с первого дня, особые условия на продукты Тинькофф, скидки, wellness-программы, обучение — и этот пак ништяков постоянно растет.
2. Гибкий график. Главное — побольше времени пересекаться с остальной командой. У нас удачный опыт работы из разных таймзон, и у сов, и у жаворонков.
3. Удаленную работу. Команда работает из России, Беларуси, Армении, Грузии, Казахстана, Турции, Таиланда — список неполный. По желанию можно приезжать в наш офис в семи минутах от «Динамо» или в другие офисы Тинькофф. Поможем с переездом в город, где есть офис.
4. Добровольное участие в материалах о сотрудниках журнала.

В Тинькофф длинная цепочка, этапы такие:

1. Спишемся в почте или Телеграме. Познакомимся там, обсудим стартовые вопросы. Если что — созвонимся.
2. Я передам контакт рекрутеру, чтобы утвердить даты технических собеседований: по алгоритмам (несложное), по языку программирования и по проектированию систем.
3. Сами секции.
4. Финальный созвон: познакомиться с кем-то еще из команды: фронтендером, бэкендером, продактом… Пообщаемся на важные темы, обменяемся каверзными вопросами.
5. Утвердим деньги, пришлем предложение на почту.

При желании у нас можно научиться:

1. Выращивать стажеров и делегировать им задачи. Несколько раз в год набираем студентов Физтеха, Вышки, Бауманки, МГУ и других вузов с неплохими техническими программами.
2. Смежным с работой софт- и хард-скиллам. В Тинькофф развитая система внутренних тренингов — от безопасности веб-приложений до поиска баланса между работой и личной жизнью.
3. Писать статьи на «Хабр» и «Медиум», выступать с докладами на митапах и конференциях. Наши редакторы, HR и DevRel помогут подобрать тему, собрать материал, подготовиться и опубликоваться или выступить.
4. Другим навыкам, которых вам будет недоставать для работы. Есть возможность поучиться на курсах или послушать конференции за счет компании.

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