Вернуться в каталог собеседований

Очень сильный Middle в 22 года?? / Техсобес студента на позицию Middle Python Developer

Mock-собеседование по Python и чистой архитектуре: теория, разбор Flask-кода интернет-заказа и подробная обратная связь кандидату.

Python Mentor
  • Опубликовано на YouTube:
  • Просмотры на YouTube: 28,9 тыс.
  • Лайки на YouTube: 566
Открыть на YouTube

Таймлайн

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

Это тестовое mock-собеседование на позицию Middle Python Developer. Кандидат рассказывает о текущем проекте, который он называет распределённым монолитом, затем обсуждает слои чистой архитектуры, зависимости, SRP, DI, Unit of Work и DRY. Основная практическая часть посвящена разбору учебного Flask-сервиса с созданием заказа, клиента и инвойса, транзакциями, PDF и email-уведомлениями; в финале интервьюеры дают развёрнутую обратную связь.

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

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

  • Перед критикой архитектуры или кода сначала выясняйте контекст, требования и дочитывайте весь код; интервьюеры отдельно указали, что кандидат слишком рано предлагал решения.
  • Различайте направление вызовов и направление зависимостей: в чистой архитектуре внешние слои зависят от внутренних, а управление и зависимость — не одно и то же отношение.
  • Для HTTP-обработчика сначала проверяйте валидацию входных данных и обработку ошибок, а уже затем переходите к архитектурному рефакторингу.
  • Создание связанных Order, Customer и Invoice требует атомарной границы транзакции; для такого сценария на интервью полезно уметь назвать и объяснить Unit of Work.
  • SRP стоит объяснять через независимые причины изменения и акторов, а не через простое количество методов в классе.
  • Генерацию PDF, отчётов и отправку писем не следует смешивать с инициализацией доменной сущности; их можно выделять в отдельные сервисы или сценарии.
  • Если уведомления не критичны для успешного создания заказа, обсуждайте отделение их от основной транзакции, ретраи и событийный подход с учётом конкретных бизнес-требований.
  • DI предполагает передачу готовой зависимости в потребляющий код; получение её методом контейнера внутри сценария ближе к service locator и требует отдельного обоснования.

Рекомендуем посмотреть