Python-разработчик (Django/DRF)

Что предстоит делать

О компании Мы — продуктовая компания. Наш основной фокус — продукты в сфере офлайн- и онлайн-кредитования. Среди наших клиентов: • розничные банки Беларуси — Сбер Банк, Банк БелВЭБ, Банк Дабрабыт, Паритетбанк и др.; • крупные торговые сети — 5 элемент, Электросила, Ома и др. О продукте Брокерская платформа. Через неё заявки на кредит и лизинг из магазинов уходят в 12+ банков и лизинговых компаний, проходят скоринг, подписание и выдачу. Это не витрина и не CRUD: заявка живёт неделями, проходит через десятки состояний, и на каждом шаге её ждёт чужая система со своим характером. Платформа развивается много лет. Часть кода уже устроена так, как надо: слои, pydantic-модели, state machine, тесты. Часть предстоит привести к этому же виду. Систему с нуля мы не переписываем и релизы не останавливаем — приводим в порядок по частям, вместе с продуктовыми задачами.

• Развивать ядро платформы: жизненный цикл заявки, статусы, интеграции с банками.
• Выносить логику из больших view-файлов и сигналов в явные use cases и state machine.
• Укреплять интеграции с банками: идемпотентная отправка, таймауты, ретраи, единый HTTP-клиент, транзакционные side-effects.
• Покрывать тестами критичные сценарии: создание заявки, отправка в банк, повторная отправка, callback от банка, смена статусов.
• Задавать архитектурные решения и ревьюить код команды, помогать коллегам писать тестируемый код.
• Брать продуктовые задачи: новая функциональность идёт вместе с рефакторингом, а не вместо него.
• Катить свои изменения в прод самостоятельно — от ветки до релиза.

Что ждём от вас

• От 5 лет коммерческой разработки на Python, из них от 3 лет на Django/DRF и Celery.
• Опыт работы с большой живой кодовой базой: выделить границы, зафиксировать поведение тестами, заменять по частям, не останавливая продукт.
• Понимание надёжности в распределённых сценариях: идемпотентность, ретраи, transaction.atomic / on_commit, гонки в очередях.
• Интеграции с банковскими и партнёрскими API: и REST с JSON, и SOAP с XML. У разных банков разные протоколы и разное качество документации.
• PostgreSQL: транзакции, блокировки, миграции на живых данных.
• Умение защищать архитектурные решения аргументами и доводить их до конца в команде.
• Кому у нас будет некомфортно
• Тем, кто ждёт с первого дня новый проект и чистый код.
• Тем, кто видит рефакторинг только как «давайте всё перепишем».
• Тем, кто готов улучшать архитектуру только в отрыве от продуктовых задач.
• Наш стек
• Python, Django 5.2 + DRF, Celery
• PostgreSQL, Redis
• pydantic, httpx
• Docker, Git, GitLab, Sentry
• Совпадение по каждому пункту не обязательно — важно, что ты решал эти классы задач.

Что предлагаем