Чего крепкому Middle-разработчику не хватает до Senior? / Техсобес на позицию Middle Python Dev

Коротко о видео

Это мок-собеседование на позицию Middle Python Developer: кандидат рассказывает о Python-проектах с Flask, RabbitMQ и Celery, а интервьюеры последовательно проверяют понимание тестирования, ООП и архитектуры. Существенная часть беседы посвящена тому, как объяснять назначение паттернов и принципов через решаемые ими проблемы: контракты юнит-тестов, DRY как устранение дублирования ответственности, композицию вместо разрастающегося наследования и разделение ответственности в MVC. В практическом задании исходную жёстко связанную MVC-подобную схему преобразуют в вариант Clean Architecture/DDD с доменом, use cases, инфраструктурой, интерфейсами и DI-контейнером. В финале участники дают положительную, но субъективную оценку кандидата для Middle-уровня и отмечают недостаток опыта в проектировании архитектуры.

Затронутые темы

Что взять на заметку

• Для объяснения Celery недостаточно сослаться на TCP или «гарантию доставки»: в беседе выделяют сокращение времени ответа, вынесение тяжёлой работы в фон и независимое масштабирование воркеров.
• Юнит-тест должен падать при нарушении контракта конкретной функции либо при ошибке в её реализации; тест-кейсы и модульные тесты — не взаимозаменяемые понятия.
• MVC и другие архитектурные паттерны стоит объяснять через разделение ответственностей, тестируемость, заменяемость компонентов и предотвращение «комка грязи», а не только через перечень слоёв.
• DRY в обсуждении трактуется прежде всего как недопущение дублирования бизнес-ответственности и риска рассинхронизации правил, а не как механический запрет одинаковых строк кода.
• При выборе между наследованием и композицией важно проверять отношение «является» и избегать длинных жёстко связанных иерархий; поведение можно делегировать отдельным стратегиям или компонентам.
• Для перехода к чистой архитектуре бизнес-логику отделяют от сценариев и инфраструктуры, а доступ к БД организуют через интерфейс репозитория и конкретную реализацию в инфраструктурном слое.
• Dependency Injection контейнер связывает реализации с абстракциями на этапе композиции приложения, сохраняя направленность зависимостей к домену и use cases.