Python tiene un modo de fallo muy suyo en las entrevistas: el lenguaje es lo bastante fácil como para ser productivo sin aprender nunca qué hace por debajo, así que los paneles han construido sus preguntas justo para encontrar ese hueco. Espera que te pregunten por qué una búsqueda en un diccionario es rápida, qué guarda en memoria un generador y qué impide realmente el bloqueo del intérprete. Aquí están las preguntas que salen una y otra vez, qué sondea cada una y cómo se construye una buena respuesta.
Estos son los patrones del puesto en general; si quieres la lista corta para una entrevista concreta, pega el anuncio real de la vacante en el Question Predictor gratuito y obtén las veinte preguntas con más probabilidad de salir en ese proceso concreto.
¿Qué evalúan de verdad las entrevistas de desarrollador Python?
Si tu comprensión va más allá de la sintaxis. En la práctica eso son cinco bloques: estructuras de datos y sus costes, evaluación perezosa (generadores e iteradores), la historia de la concurrencia incluido el bloqueo del intérprete, disciplina de tipado y testing. Envolviéndolo todo está la calidad del código, porque Python te deja escribir algo que funciona y que aun así es imposible de mantener, y los paneles contratan contra ese riesgo.
La seniority cambia las preguntas menos de lo que esperarías; lo que cambia es la profundidad de las repreguntas. A un júnior le preguntan qué es un generador; a un sénior, cómo acotaría la memoria con diez mil de ellos. Dos cosas se han movido hace poco: las anotaciones de tipo ya se esperan en código profesional en lugar de tratarse como adorno, y la respuesta sobre el bloqueo del intérprete que todo el mundo se memorizó ahora está incompleta.
¿Cómo es el proceso de entrevistas de Python?
De cuatro a seis etapas, normalmente repartidas en dos semanas: un filtro con el reclutador, un filtro de código, una ronda práctica más larga, una ronda de diseño o de revisión de código y una conversación conductual. El dominio le da forma al proceso, así que los equipos de web añaden preguntas de API y base de datos, los de plataforma de datos añaden preguntas de pipelines y SQL, y los de machine learning añaden trabajo numérico encima.
- Filtro con el reclutador (20 a 30 minutos). Stack, dominio, versiones, banda salarial. Ten preparada una descripción de dos frases de lo más interesante a nivel técnico que hayas entregado.
- Filtro de código (45 a 60 minutos). Un ejercicio en un editor compartido, normalmente de parseo o transformación, más fundamentos a ritmo rápido sobre estructuras de datos y sus costes.
- Ronda práctica (60 a 90 minutos). Ampliar un código base pequeño, o un ejercicio para casa seguido de una discusión. Los tests se puntúan muy a menudo, diga o no el enunciado que hay que ponerlos.
- Ronda de diseño o de revisión de código. O diseñas un servicio, o revisas un módulo con fallos puestos a propósito y dices qué cambiarías. El formato de revisión es popular porque es difícil de preparar.
- Responsable de contratación o ronda conductual. Responsabilidad, colaboración y si el nivel que dices tener se sostiene.
Si sabes con qué empresa te vas a entrevistar, los bancos de preguntas por empresa dan una lectura más rápida del estilo de la casa que rastrear foros.
¿Qué preguntas sobre estructuras de datos de Python salen?
Espera tener que justificar una elección entre list, dict, set y tuple, y decir el coste de la operación que acabas de escribir. El panel comprueba si sabes que una prueba de pertenencia contra una lista es lineal y contra un set es constante, lo que está detrás de buena parte del Python lento que hay suelto por ahí. Di la complejidad en voz alta según eliges.
¿Cómo está implementado un dict, y qué se deduce de eso? Qué sondea: si la estructura más rápida del lenguaje es una caja negra para ti. Cubre el hash de la clave para encontrar un hueco, el direccionamiento abierto para resolver colisiones, el redimensionado cuando la tabla se llena y las búsquedas de tiempo constante en promedio que se degradan con hashes malos. Y luego las consecuencias: las claves tienen que ser hashables y deberían ser inmutables, y el orden de inserción está garantizado desde la 3.7.
¿Cuándo eliges un set en lugar de una lista, y qué cuesta? Qué sondea: instinto para la complejidad. Los sets dan pertenencia en tiempo constante y deduplicación gratis, a cambio del orden y de exigir elementos hashables. Convertir una lista en set antes de un bucle de pruebas de pertenencia convierte un bucle cuadrático en lineal.
¿Qué preguntan los entrevistadores sobre generadores e iteradores?
Las preguntas sobre generadores evalúan si sabes trabajar con datos que no caben en memoria. Espera tener que explicar la diferencia entre un iterable, un iterador y un generador, y luego reescribir algo ansioso como perezoso. La señal de fondo es si piensas siquiera en la memoria, porque el estilo Python por defecto de ir construyendo listas funciona perfectamente hasta que la entrada crece.
¿Cuál es la diferencia entre un iterable, un iterador y un generador? Qué sondea: precisión sobre algo que casi todo el mundo usa a diario sin saber nombrarlo. Un iterable puede producir un iterador; un iterador guarda la posición y va devolviendo el siguiente elemento hasta que lanza StopIteration; un generador es un iterador producido por una función con yield o por una expresión generadora.
Reescribe una función que carga un fichero de log de 50 GB en una lista para que no se caiga. Qué sondea: evaluación perezosa en la práctica. Itera el objeto fichero línea a línea (ya es perezoso), devuelve registros parseados con yield desde una función generadora y guarda en memoria solo los agregados.
¿Cuál es la diferencia entre una comprensión de lista y una expresión generadora? Qué sondea: si la distinción está entendida o solo te has memorizado la sintaxis. La comprensión construye la lista entera de inmediato; la expresión generadora produce elementos bajo demanda y mantiene uno cada vez.
¿Qué evalúa realmente la pregunta del GIL?
Si sabes elegir la herramienta de concurrencia adecuada para una carga de trabajo. El bloqueo significa que solo un hilo ejecuta bytecode de Python a la vez en una build estándar, así que los hilos no te dan trabajo de CPU en paralelo, aunque siguen ayudando cuando los hilos esperan por operaciones de entrada/salida. La trampa es el candidato que se ha memorizado que el bloqueo hace lento a Python y se queda ahí.
¿Qué es el bloqueo del intérprete y cómo afecta a tu código? Qué sondea: exactitud. Sé concreto: protege el estado del intérprete, se libera durante la entrada/salida y dentro del código de extensiones que lo sueltan (por eso las librerías numéricas usan varios núcleos), y hace que los hilos sean inútiles para paralelismo con carga de CPU mientras siguen siendo útiles para entrada/salida concurrente. Ya existen builds sin GIL como opción, lo que cambia el tiempo futuro de la respuesta sin cambiar la mayoría de los despliegues de hoy.
Un trabajo con carga de CPU tarda 20 minutos. ¿Cómo lo haces más rápido? Qué sondea: si sabes actuar sobre la respuesta anterior. Perfila primero para ver a dónde se va el tiempo de verdad, luego plantéate un algoritmo mejor, luego vectorizar con una librería que libere el bloqueo, y luego varios procesos para usar varios núcleos, asumiendo su coste en serialización y memoria.
Hilos, procesos o asyncio: ¿cómo eliges? Qué sondea: un modelo mental limpio. Asyncio para entrada/salida con concurrencia muy alta donde controlas la ruta de llamadas y las librerías son asíncronas. Hilos para trabajo con entrada/salida donde las librerías bloquean y el número de tareas concurrentes es moderado. Procesos para trabajo con carga de CPU.
¿Qué preguntas sobre async salen en las entrevistas de Python?
Las rondas de async evalúan si entiendes la planificación cooperativa. El bucle de eventos ejecuta una tarea hasta que hace await, y entonces pasa a otra, así que cualquier cosa que bloquee sin esperar lo para todo. Espera preguntas sobre ese fallo, sobre ejecutar muchas tareas a la vez, y sobre cancelación y manejo de errores, que es donde viven de verdad la mayoría de los bugs reales de async.
¿Qué pasa si llamas a una función bloqueante dentro de una corrutina? Qué sondea: el concepto más importante de async. El bucle de eventos queda parado todo ese rato, así que el resto de tareas esperan y tu servicio de alta concurrencia degrada a serie. Nombra el arreglo: usa un cliente asíncrono, o empuja la llamada bloqueante a un executor de hilos.
¿Cómo ejecutas cien peticiones a la vez y manejas que una falle? Qué sondea: orquestación de tareas. Agrupar tareas con gather las ejecuta a la vez, y por defecto la primera excepción se propaga mientras el resto siguen sin esperarse, salvo que pidas que las excepciones se devuelvan. Es preferible un task group, para que los fallos cancelen a las hermanas de forma predecible y no quede nada huérfano.
¿Cómo acotarías la concurrencia al lanzar diez mil peticiones? Qué sondea: si has hecho esto en producción. Diez mil tareas de golpe agotan los sockets, inundan al destino y producen una ráfaga de timeouts que parecen un bug de tu propio código. Usa un semáforo o un pool de workers consumiendo de una cola, pon un timeout en cada petición y añade reintentos con backoff.
¿Qué preguntas de tipado hacen los entrevistadores de Python?
Las preguntas de tipado evalúan disciplina, no trivialidades. Las anotaciones no se comprueban en tiempo de ejecución; las comprueba una herramienta aparte en tu pipeline y las leen tu editor y tus compañeros. Los paneles quieren oír que ejecutas un comprobador de tipos en integración continua y que tipas primero las fronteras de las funciones.
¿Qué hacen realmente las anotaciones de tipo en tiempo de ejecución? Qué sondea: si conoces el límite. Esencialmente nada; se guardan como metadatos y el intérprete las ignora, y por eso una función anotada para devolver un entero devolverá tan tranquila una cadena. El valor viene del comprobador estático y de la legibilidad.
¿Qué es un Protocol y cuándo usarías uno en lugar de una clase base? Qué sondea: si entiendes el tipado estructural. Un Protocol describe la forma que algo tiene que tener sin exigir herencia, así que tipa el duck typing como es debido y funciona con clases que no son tuyas. Contrástalo con una clase base abstracta, que obliga a quien implementa a heredar.
¿Qué preguntas de testing salen en una entrevista de Python?
Las preguntas de testing a menudo deciden la nota del ejercicio para casa, así que trátalas como algo de primera clase. Los paneles quieren tests rápidos y aislados, fixtures usadas para la preparación en lugar de copiar y pegar, casos parametrizados en vez de funciones duplicadas, y una idea clara de cuándo un mock ayuda y cuándo está afirmando en silencio que tu propio mock funciona.
¿Cómo estructuras una suite de tests con fixtures? Qué sondea: si tus tests son mantenibles. Usa fixtures para la preparación y el desmontaje con el ámbito adecuado, guarda las compartidas en un fichero conftest y parametriza los casos que solo se diferencian por la entrada.
¿Cuándo es correcto usar mocks y cuándo son un mal olor? Qué sondea: criterio para testear. Haz mock en la frontera que no controlas (una API de terceros, el reloj, un proveedor de pagos) y parchea donde se usa el objeto en lugar de donde está definido, que es el error más común.
¿Cómo testeas código que ataca a una base de datos? Qué sondea: pragmatismo con la integración. Mejor una base de datos real en un contenedor desechable que un sustituto en memoria, porque cambiar el motor significa que nunca testeas las consultas que realmente despliegas. Envuelve cada test en una transacción que se revierte y deja el grueso de la suite como tests unitarios puros.
¿Qué preguntas de interioridades y trampas se siguen haciendo?
Un puñado de clásicos aparecen como calibración: argumentos por defecto mutables, decoradores y cómo se gestiona la memoria. Son rápidas, y lo que el panel comprueba en realidad es si te han mordido alguna vez, así que ata una consecuencia real a cada respuesta en lugar de recitar la regla de un tutorial.
¿Por qué es peligroso un argumento por defecto mutable? Qué sondea: si entiendes cuándo se evalúan los valores por defecto. El valor por defecto se crea una sola vez cuando se define la función, no en cada llamada, así que una lista por defecto se comparte entre todas las llamadas y se va acumulando.
Explica los decoradores y luego escribe uno que reintente una función. Qué sondea: si te manejas con soltura en funciones de orden superior. Un decorador es una función que toma una función y devuelve un envoltorio. Conserva los metadatos con functools.wraps y maneja los argumentos de forma genérica. Para el reintento, toma los intentos y el backoff como parámetros, captura solo las excepciones que merece la pena reintentar y vuelve a lanzarla tras el último intento.
¿Cómo gestiona Python la memoria? Qué sondea: conciencia más allá de "hay un recolector de basura". El conteo de referencias libera objetos en cuanto desaparece la última referencia, y un recolector de ciclos se encarga de los ciclos de referencias que el conteo por sí solo no puede resolver.
¿Qué errores hunden a los candidatos de Python?
Rara vez la sintaxis. Los candidatos pierden las rondas de Python produciendo código que funciona sin decir nunca lo que cuesta, saltándose los tests o quedándose callados mientras piensan. Los paneles compran tu razonamiento tanto como tu función, así que narra la contrapartida y el caso límite.
- Código que funciona sin decir su coste. Una respuesta correcta sin mención al tiempo o la memoria suena a alguien que solo ha trabajado con entradas pequeñas.
- Saberse a medias la respuesta del bloqueo del intérprete. "Python no puede hacer concurrencia" es falso, y la repregunta está diseñada para separar la respuesta memorizada de la entendida.
- Saltarse los tests en un ejercicio para casa. Si el enunciado es abierto, el código sin tests se suele puntuar como incompleto por elegante que sea.
- Ignorar los tipos por completo. Fronteras de funciones sin tipar en 2026 suenan a alguien que no ha trabajado en un código base compartido.
¿Cómo deberías prepararte para una entrevista de Python?
Escribe código en un editor pelado y sin asistente durante unas cuantas sesiones, porque en la prueba no vas a tener uno y la soltura se pierde rápido. Machaca las cuatro cosas que salen en casi todos los procesos: la complejidad de tus elecciones de estructura de datos, convertir código ansioso en perezoso, elegir un modelo de concurrencia y testear lo que has escrito. Y luego prepara dos historias, una sobre un problema de rendimiento y otra sobre una discrepancia por la calidad del código.
Antes del proceso en sí, pega la oferta de empleo real en el Question Predictor gratuito y trabájate las veinte preguntas que marca para ese puesto concreto, porque un equipo de Django, un equipo de plataforma de datos y un equipo de machine learning hacen entrevistas muy distintas bajo el mismo título.
Para las rondas en vivo, GhostPilot es un copiloto de entrevistas en tiempo real: un panel lateral de extensión de Chrome y una app de escritorio opcional para Windows que transcriben la llamada, cazan la pregunta según cae y tienen una respuesta estructurada lista unos dos segundos después. Donde más ayuda es en las preguntas con trampa dentro, como la de la concurrencia. Es un apunte, no un guion, y el detalle sigue saliendo de tu propio trabajo. El plan gratuito te da 10 minutos de entrevista en vivo a la semana, sin tarjeta.
FAQ de entrevistas de Python
¿Cuánto tiempo debería prepararme para una entrevista de desarrollador Python? De dos a tres semanas si escribes Python a diario: una semana de fundamentos y estructuras de datos, una semana de concurrencia, tipado y testing, y unos días de historias. Más tiempo si nunca te han revisado el código, porque la ronda de revisión es donde eso se nota.
¿Las entrevistas de Python siguen haciendo preguntas de algoritmos? Las empresas grandes suelen mantener una ronda de algoritmos, normalmente entre fácil y media. Los equipos más pequeños se han pasado en buena medida a ejercicios prácticos y revisión de código. En cualquier caso, conoce la complejidad de las operaciones integradas en las que te apoyas.
¿Necesito conocer un framework concreto? Si la descripción del puesto nombra uno, trátalo como un tema de primera clase y espera preguntas sobre el ciclo de vida de la petición, el ORM y el testing. Si no, con los fundamentos más un framework que puedas discutir a fondo basta; una lista superficial de cinco no impresiona a nadie.
¿Debería admitir cuando no sé algo? Sí. "No lo he usado en producción, pero así es como lo enfocaría y esto es lo que comprobaría primero" le gana a una respuesta equivocada dicha con mucha seguridad. Los paneles de Python repreguntan dos o tres niveles hacia abajo, así que el farol se derrumba enseguida.