Что конкретно писал в проекте
Что проверяют
Ваш ли это опыт. Вопрос идёт следом за рассказом о проекте и режет заученные описания: по резюме систему сделала команда, а интервьюеру нужна именно ваша часть. Заодно выясняют глубину: на любую названную технологию почти наверняка прилетит уточняющий вопрос.
Как отвечать
Взять одну-две задачи и описать их конкретно, по одной схеме: что за сервис и зачем он нужен, какая часть ваша, что было сложного, какое решение выбрали и почему не соседнее. Границы полезно называть честно: схему проектировал не я, я писал загрузку и разбор данных.
Держитесь предметности, характерной для задач на Python:
- за что отвечал ваш модуль: обработчики HTTP, фоновые задачи, обвязка вокруг данных, интеграция с внешним API;
- какие решения принимали: как разложили по слоям, где поставили границу транзакции, что делать при повторной доставке сообщения;
- как проверяли: какие тесты писали, что подменяли, как ловили ошибки на бою;
- где ошиблись и что переделали. Признанная и исправленная ошибка добавляет доверия больше, чем гладкая история.
Называйте только то, что готовы обсуждать: Celery в рассказе почти всегда тянет вопрос про повторы и идемпотентность, SQLAlchemy про сессию и ленивую загрузку.
Где спотыкаются
Рассказывают через «мы». После двух минут такого рассказа собеседующий по-прежнему не знает, что делал сам кандидат, и переспрашивает уже с недоверием.
Затыкают отсутствие деталей цифрами вроде ускорения на тридцать процентов. Дальше спрашивают, чем измеряли, что было узким местом и как выглядел профиль до изменения. Без ответа цифра работает против вас и выглядит строчкой из шаблона.
Перечисляют стек списком вместо задачи. Названия библиотек не показывают инженерных решений, а среди перечисленного всегда найдётся то, что кандидат видел мельком: один уточняющий вопрос, и доверие теряется ко всему рассказу целиком.