Вернуться в видеотеку

Python: техническое собеседование Lead-инженера

Техническое интервью на позицию Lead Python Engineer. Интервьюер проверяет опыт кандидата в SDLC и методологиях разработки, веб-протоколах и TLS, безопасности, ООП, тестировании, Git/CI/CD, инфраструктуре и внутреннем устройстве Python. Практическая часть включает SQL-задачи с JOIN и агрегациями, а также рефакторинг сервиса денежных переводов с транзакциями, блокировками и архитектурными границами.

Источник: Python Mentor

Открыть на YouTube

Таймлайн

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

Запись построена как полноценное техническое интервью на Lead Python Engineer: интервьюер уточняющими вопросами проверяет как широту знаний, так и ход рассуждений кандидата. Обсуждаются SDLC, Agile/Scrum/Kanban, REST/GraphQL/gRPC, HTTP/TCP/TLS, веб-уязвимости, ООП и SOLID, тесты, Git, CI/CD, Docker/Kubernetes, AST и байткод Python, GIL, сборка мусора и дескрипторы. В практической части кандидат составляет SQL-запросы к таблицам devices и files с JOIN, SUM и HAVING, затем разбирает рефакторинг сервиса перевода денег: транзакции, уровни изоляции, SELECT FOR UPDATE, deadlock, репозиторий и Unit of Work. В разговоре есть уточнения и исправления неполных ответов, поэтому ролик полезен как пример проверки технического мышления на интервью.

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

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

  • Различайте Agile как набор подходов, Scrum как фреймворк и Kanban как метод управления потоком работ; не меняйте их местами в ответе.
  • При объяснении HTTPS отделяйте TCP three-way handshake от TLS handshake: асимметричная криптография помогает аутентифицировать стороны и согласовать секрет, а трафик обычно шифруется симметричными алгоритмами.
  • В SQL выбирайте INNER JOIN, если записи без дочерних сущностей не нужны, и LEFT JOIN, если их требуется сохранить; фильтры по агрегатам задавайте через GROUP BY и HAVING.
  • Для перевода денег нужны атомарная транзакция, осознанный выбор изоляции и блокировок, например SELECT FOR UPDATE, а также стратегия обработки конфликтов и deadlock.
  • Рассказывая о Python internals, связывайте AST, байткод, GIL и дескрипторы с практическими сценариями, а не ограничивайтесь определениями.
  • Разделяйте unit-, интеграционные и end-to-end-тесты по проверяемой границе и выбирайте объём тестирования с учётом критичности домена.

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