С чем именно приходилось бороться в производительности

Что проверяют

Был ли у вас реальный опыт разбора тормозов или вы знаете общие слова про оптимизацию. Смотрят на порядок действий: измерить, найти узкое место, поправить, перемерить. Заодно проверяют, понимаете ли вы, что в питоновском сервисе виноват чаще не питон.

Как отвечать

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

• cProfile для общей картины по вызовам, line_profiler построчно по одной подозрительной функции;
• py-spy цепляется к живому процессу и не требует его перезапуска;
• tracemalloc и memray для памяти, timeit для микрозамеров;
• EXPLAIN ANALYZE и логи медленных запросов, когда упирается в базу.

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

Где спотыкаются

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

Второе: называют красивую цифру ускорения и не могут сказать, что именно мерили, на какой нагрузке и сколько было прогонов. Заученная доля из резюме разваливается на первом уточняющем вопросе, и дальше интервьюер перестаёт верить и остальным числам.

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