Всем привет! На связи Артём Шумейко👋🏻

Я 3 года преподаю Python, еще дольше снимаю обучающие видеоролики на YouTube, и за это время вокруг меня собрались сильные, увлечённые своим делом ребята, которые впоследствии стали частью моей команды.

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

Я запустил этот канал, чтобы рассказывать о школе, делиться опытом, новостями и полезными материалами по Python. Здесь будет место для практики, полезной информации и историй наших выпускников.

Спасибо за поддержку. Дальше будет ещё интереснее.

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

Через вопросы по этой теме оценивают, как разработчик думает о системе:

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

Хотя Python позволяет использовать различные парадигмы программирования, архитектура большинства реальных проектов строится именно на ООП.

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

Крупные проекты, где важны надёжность и масштабируемость, всегда строятся на принципах ООП.
И, несмотря на то, что ООП — один из базовых инструментов Python-разработчика, именно он чаще всего вызывает вопросы.

Какие темы в ООП вызывают у тебя трудности? О чем ты много читал, но до сих пор не понял?

Базовая задача по ООП — проверь себя

Такого типа задачи часто встречаются на собеседованиях на Python-разработчика. Попробуй разобраться, какие значения b_.check_activity() выведутся на экран? А может, вообще выдаст ошибку?

class ClientA:

    is_active = False

    def check_activity(self) -> bool:
        return self.is_active


class ClientB(ClientA):

    def __init__(self, is_active: bool):
        self.is_active = is_active

a_ = ClientA()
b_ = ClientB(is_active=True)
print(b_.check_activity())
a_.is_active = False
print(b_.check_activity())
b_.is_active = False
print(b_.check_activity())


Выбирай свой ответ ниже👇🏻

🔥 – решил верно
👍 – решил неверно

48% участников ошиблись во вчерашней задаче по ООП

Правильный ответ:


True  
True  
False


Разберем, почему так👆🏻
is_active в ClientA — это атрибут класса, а при создании ClientB через __init__ мы создаём одноимённый атрибут экземпляра. Когда мы обращаемся к self.is_active, Python сначала ищет в экземпляре, а уже потом — в классе. Поэтому изменения в a_.is_active (атрибуте класса) не влияют на b_, у которого уже есть собственный атрибут.

Сегодня вечером выложим ещё одну задачу, она будет не менее интересная

Новая задача по ООП — проверь себя

Сегодня задача посложнее. Попробуй разобраться, что выведет код?

class Collection:

    def __init__(self, *items):
        self.collection = []
        for item in items:
            if isinstance(item, (list, tuple)):
                self.collection.extend(item)
            else:
                self.collection.append(item)

    def map(self, fn: Callable) -> Self:
        return self.__class__(*map(fn, self.collection))

    def filter(self, fn: Callable) -> Self:
        return self.__class__(*[x for x in self.collection if fn(x)])

    def __repr__(self) -> str:
        return f"{self.__class__.__name__}:{self.collection}"


coll = Collection(1, 2, -3, 4, 5)
result = coll.map(lambda x: x * 2).filter(lambda x: x >= 6)
print(result)

Выбирай свой ответ ниже👇🏻

👍 – решил
🤝 – не решил

🥳Релиз нового курса «Продвинутое ООП в Python»

Мы собрали в нём всё, что действительно нужно, чтобы мыслить архитектурно: понимать, как проектировать систему, выстраивать зависимости и писать код, который не ломается при первых изменениях.

В программе курса — полный набор тем, которые нужны разработчику, чтобы уверенно работать с объектно-ориентированным подходом в Python:

• работа с атрибутами и методами
• свойства объектов (@property)
• использование декораторов @classmethod и @staticmethod
• магические методы и переопределение поведения объектов
• итерируемые объекты и последовательности
• контекстные менеджеры и декоратор @contextmanager
• дескрипторы
• наследование, композиция и полиморфизм
• использование __slots__ для оптимизации классов
• Enum
• декораторы классов
• модуль dataclasses

Отдельные блоки посвящены архитектурным принципам:
• SOLID
• паттерны проектирования
• абстрактные классы
• интерфейсы и композиция

🔥В курсе предусмотрено создание 2 проектов: по базе ООП и по SOLID.

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

Смотри программу на сайте и начинай обучение.

Совет от нашего наставника, который должен услышать каждый начинающий разработчик

На курсе Backend-разработки на Python у нас есть замечательный наставник — Полина. Она делится советом со всеми начинающими разработчиками:

Мониторьте бесплатные митапы и IT-мероприятия от крупных компаний, и обязательно ходите на них оффлайн.

Не спорим, что онлайн удобно, но присутствие оффлайн намного эффективнее и вот почему:

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

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

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

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

Скрытый бонус

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

Если ты хочешь обучиться backend-разработке на Python, получать офферы и расти по карьере, сейчас самое время воспользоваться скидками черной пятницы и начать обучение.

Что должен уметь backend-разработчик в 2026 году

Как и в любой IT-специальности, требования к специалистам отличаются от компании к компании. Где-то разработчик с опытом 2 лет считается middle, где-то всё ещё junior. Рассмотрим усредненный набор знаний и навыков, по которым обычно определяют грейд:

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

Что нужно знать:
✅ Python на уровне уверенного написания простых сервисов
✅ Основы ООП, понимание принципов SOLID на базовом уровне
✅ Асинхронность (async/await) — базовые представления
✅ FastAPI — базовые CRUD-эндпоинты, роутинг, обработка ошибок
✅ PostgreSQL: JOIN, GROUP BY, индексы, транзакции
✅ SQLAlchemy или Django ORM — базовые запросы
Понимание NoSQL (Redis, MongoDB) на уровне базовых операций
✅ Docker: запуск простого контейнера, базовый Dockerfile
Понимание, что такое REST API, HTTP, статусы ответов
✅ Git: ветки, merge request, code review, конфликты
Логирование, работа с зависимостями, структура проекта

Middle
Middle-разработчик уже не ждёт подробного ТЗ. Он предлагает решения, оптимизирует архитектуру, умеет разбираться в чужом коде и общается с аналитиками, менеджерами, QA.

Что нужно знать:
✅ Глубокое понимание Python: генераторы, контекстные менеджеры, async/await, типизация
✅ Понимание паттернов проектирования
✅ FastAPI: асинхронные приложения, middleware, фоновые задачи
✅ PostgreSQL: планы выполнения, оптимизация запросов, индексы, триггеры
✅ Проектирование API, контрактов, интеграций
✅ Использование Redis для кэша, rate-limit, очередей
✅ Работа с SQLAlchemy ORM на продвинутом уровне
✅ Docker: мультистейдж сборка, оптимизация образов
✅ CI/CD (GitHub Actions/GitLab CI/Yandex Cloud)
✅ Базовые знания Kubernetes (часто встречается в 2025)
✅ Pytest: фикстуры, моки, тестирование API
✅ Опыт с брокерами сообщений: Kafka, RabbitMQ
✅ Линтеры: ruff, black, mypy
✅ Умение писать документацию
✅ Участие в планировании, декомпозиции задач

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

Что нужно знать:
✅ Проектирование высоконагруженных систем
✅ Микросервисная архитектура, событийный подход
✅ Domain-Driven Design (DDD) на практическом уровне
✅ Продвинутый Kubernetes (Helm, Operators)
✅ Балансировка нагрузки
✅ Мониторинг: Prometheus, Grafana, Sentry
✅ Оптимизация на уровне схемы, репликация, шардинг
✅ Redis для сложных задач: очереди, pub/sub
✅ Code review, менторинг, постановка задач
✅ Ведение технических дорожных карт
✅ Понимание влияния архитектурных решений на продукт
✅ Оценка рисков, сроков
✅ Качество SLA, отказоустойчивость систем

Подробнее о разнице в задачах и росте в backend’е расскажем в следующих постах.

Различия между грейдами backend-разработчиков.

Разбор на реальном кейсе
Разница между Junior, Middle и Senior проявляется не только в навыках, но и в том, как каждый уровень решает одну и ту же задачу. Рассмотрим на примере из практики.

Кейс
Сервис электронных уведомлений столкнулся с проблемой: пользователи жалуются, что письма и push-уведомления приходят с задержкой. В пиковые часы очередь задач растёт, а система не справляется. Нужно понять, что происходит и как стабилизировать работу сервиса.

Junior
Начинающему backend-разработчику нужно поставить чёткое ТЗ: проверить один конкретный модуль или часть очереди. Он сможет:

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

Middle
Middle-разработчик уже сам исследует проблему, формулирует гипотезы и предлагает варианты решения. Он сможет:

— Проанализировать узкие места: медленные запросы в PostgreSQL, блокировки, неэффективные ORM-операции.
— Проверить, не упирается ли сервис в ограничение Redis, очередь, лимиты CPU.
— Переписать критичный участок на асинхронный FastAPI, вынести операции в Celery или другой брокер задач.
— Оптимизировать SQL: добавить индексы, CTE, изменить схему таблиц.
— Настроить метрики и алерты: время ответа, длину очереди, ошибки 5xx.
— Внедрить rate-limit, чтобы ни один канал не перегружался.
— Предложить архитектурное улучшение: разделить сервис на два модуля, вынести тяжёлые задачи в отдельный worker.

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

— Спроектировать высоконагруженную архитектуру для отправки уведомлений: очереди, ретраи, шардирование, отдельные сервисы под каждый канал.
— Выстроить систему observability: логирование, трассировка, метрики, алерты, дашборды в Grafana.
— Переписать критичные части на устойчивую схему: worker-пул, механизм backpressure.
— Настроить CI/CD, автотесты, нагрузочное тестирование, чтобы проблем не возникало после релизов.

Важно: как и в любой IT-специальности, требования к специалистам отличаются от компании к компании.