Entrevistas de Python backend cobrem detalhes internos da linguagem, programação assíncrona, Django ou FastAPI, e padrões de acesso a banco de dados. Abaixo estão as perguntas mais comuns com respostas modelo. Senior: arquitetura, trade-offs, mentoria e tomada de decisão.
De modo geral: tirar o trabalho do request para uma fila, paralelizar com processos em vez de threads, empurrar o loop quente para C ou Rust via uma extensão, ou trocar o algoritmo. Essa última é geralmente a mais barata e a que as pessoas pulam. Multiprocessing custa a serialização de tudo que cruza a fronteira; uma extensão custa complexidade de build e uma segunda linguagem no repositório.
Em etapas que sejam cada uma retrocompatíveis: adicione a nova coluna como nullable, escreva tanto na velha quanto na nova, faça backfill em lotes, mude as leituras, e só então remova a velha num release posterior. A razão é que durante um rolling deploy duas versões do código rodam contra o mesmo banco de dados. A falha mais comum é uma migration que trava uma tabela grande — no Postgres, adicionar um índice precisa de CONCURRENTLY.
Comece pelo que mudou, depois vá reduzindo por camada em vez de chutar: está lento para todos os usuários ou para um subconjunto? O tempo está no banco de dados, no Python, ou numa chamada externa? Traces de APM ou um profiler no hot path respondem isso em minutos. Só então otimize. A armadilha comum é fazer profiling localmente contra um dataset pequeno, onde o N+1 que domina em produção fica invisível.
Django quando o serviço é pesado em conteúdo e admin, ou quando o ORM, migrations, auth e admin economizam meses. FastAPI quando é uma API enxuta, quando o I/O assíncrono domina, ou quando o contrato tipado schema-first importa. Nenhuma escolha é sobre benchmark de velocidade. A pergunta que vale a pena fazer é qual sua equipe consegue operar às três da manhã.
O mais perto possível do que é caro, e não mais perto que isso — cachear uma página inteira renderizada esconde qual parte era realmente lenta. A invalidação explícita por chave na escrita é correta mas fácil de esquecer; um TTL curto está "errado" mas se autocorrige, e para a maioria dos dados pesados em leitura é o melhor trade-off. A falha que vale planejar é a estampida quando uma chave quente expira e cada requisição a reconstrói ao mesmo tempo.
Eles te dão um checker que pega classes inteiras de erros antes do runtime, autocompletar no editor, e documentação que não pode ficar desalinhada do código. Eles não te dão validação em runtime — nada valida um hint a menos que você adicione pydantic ou algo parecido. Num codebase grande, o valor vem de ser rígido nas fronteiras e pragmático por dentro; colocar hint em cada variável local custa mais do que retorna.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Senior Python Backend →