Senior Python Backend — Preguntas de entrevista Python backend

Un endpoint limitado por CPU es demasiado lento. ¿Cuáles son las opciones y qué cuestan?

A grandes rasgos: mover el trabajo fuera del request a una cola, paralelizar con procesos en vez de hilos, empujar el loop caliente a C o Rust vía una extensión, o cambiar el algoritmo. Lo último suele ser lo más barato y lo que la gente se salta. Multiprocessing te cuesta la serialización de todo lo que cruza el límite; una extensión te cuesta complejidad de build y un segundo lenguaje en el repo.

¿Cómo despliegas una migration de schema sin downtime?

En etapas que sean cada una retrocompatibles: agrega la nueva columna como nullable, escribe tanto a la vieja como a la nueva, haz backfill en lotes, cambia las lecturas, y luego elimina la vieja en un release posterior. La razón es que durante un rolling deploy dos versiones del código corren contra una base de datos. El fallo más común es una migration que bloquea una tabla grande — en Postgres, agregar un índice necesita CONCURRENTLY.

Un endpoint se puso lento en producción. Cuéntame cómo averiguas por qué.

Empieza con qué cambió, luego reduce por capa en vez de adivinar: ¿es lento para todos los usuarios o un subconjunto?, ¿el tiempo está en la base de datos, en Python, o en una llamada externa? Los traces de APM o un profiler en el hot path responden eso en minutos. Solo entonces optimiza. La trampa común es perfilar localmente contra un dataset pequeño, donde el N+1 que domina en producción es invisible.

Django o FastAPI para un servicio nuevo — ¿cómo decides?

Django cuando el servicio es pesado en contenido y admin, o cuando el ORM, migrations, auth y admin te ahorran meses. FastAPI cuando es una API delgada, cuando el I/O async domina, o cuando importa el contrato tipado schema-first. Ninguna elección es sobre benchmarks de velocidad. La pregunta que vale la pena hacer es cuál puede operar tu equipo a las tres de la mañana.

¿Dónde pones el caché, y cómo lo invalidas?

Lo más cerca posible de lo costoso y no más cerca — cachear una página completa renderizada esconde qué parte era realmente lenta. La invalidación por clave explícita al escribir es correcta pero fácil de olvidar; un TTL corto está mal pero se autorepara, y para la mayoría de los datos pesados en lectura es el mejor trade-off. La falla que hay que planear es la estampida cuando una clave caliente expira y cada request la reconstruye a la vez.

¿Qué te dan los type hints, y qué no?

Te dan un checker que atrapa clases enteras de errores antes del runtime, autocompletado del editor, y documentación que no puede desalinearse del código. No te dan validación en runtime — nada valida un hint a menos que agregues pydantic o similar. En un codebase grande el valor viene de ser estricto en los límites y pragmático adentro; ponerle hint a cada variable local cuesta más de lo que devuelve.