Cómo explicar tu código en una entrevista técnica (sin quedarte en blanco)

He visto a candidatos resolver el ejercicio perfecto y suspender la entrevista. Y a otros que no lo terminaron y la aprobaron. La diferencia casi nunca es el código: es cómo lo explican mientras lo escriben.

En una entrevista técnica te evalúan dos cosas a la vez: si resuelves el problema y cómo piensas. Lo segundo solo se ve si lo dices en voz alta. Aquí tienes la estructura, las frases concretas y, sobre todo, qué hacer cuando te quedas en blanco — que le pasa a todo el mundo.

Esto cierra el clúster de entrevistas. Para la parte técnica: las 20 preguntas, los patrones de coding interview y Big-O.

Por qué importa tanto como el código

El entrevistador no está solo comprobando si llegas a la solución. Está imaginando cómo sería trabajar contigo: ¿explicas tus decisiones?, ¿escuchas una pista?, ¿te bloqueas en silencio o piensas en alto? Un código correcto explicado de forma confusa transmite peor que un código a medias explicado con claridad.

Dicho de otra forma: el silencio es lo que más penaliza. Si piensas callado, el entrevistador no ve nada que evaluar y, peor, no puede ayudarte cuando te desvías.

La estructura para pensar en voz alta

Sigue siempre el mismo guion. Te da algo que decir aunque la cabeza vaya en blanco:

1. Reformula el problema. “Vale, lo que me pides es, dada una lista, encontrar… ¿correcto?” Confirma que entendiste.
2. Pregunta los casos límite. “¿Puede haber duplicados? ¿La lista puede venir vacía? ¿Está ordenada?” Esto solo ya suma muchos puntos.
3. Pon un ejemplo pequeño a mano. “Si la entrada es [2, 7, 9] y el objetivo 9, espero [0, 1].”
4. Di tu plan antes de teclear. “Se me ocurre la fuerza bruta con dos bucles, O(n²). Pero creo que con un diccionario lo bajo a O(n). Voy con eso.”
5. Narra mientras escribes. “Recorro la lista, y para cada número miro si su complemento ya está en el diccionario…”
6. Prueba con tu ejemplo al terminar. “Lo paso con [2, 7, 9]… sale [0, 1]. Bien.”
7. Di la complejidad. “Es O(n) en tiempo y O(n) en espacio por el diccionario.”

Ese guion convierte una página en blanco en una conversación. Y una conversación es lo que aprueba.

Qué decir cuando te quedas en blanco

Te vas a bloquear. Es normal y el entrevistador lo sabe. Lo que evalúa es cómo reaccionas. En vez de callarte:

• Verbaliza el bloqueo: “Vale, me he atascado. Déjame pensar en alto lo que tengo.” Eso no es debilidad, es lo que hace un profesional.
• Vuelve al ejemplo concreto: resolverlo a mano para un caso pequeño casi siempre destapa el patrón.
• Plantea la fuerza bruta: “No veo aún la óptima, pero la fuerza bruta sería esto. Empiezo por aquí y luego optimizo.” Una solución que funciona vale más que el silencio esperando la perfecta.
• Piensa en voz alta sobre estructuras: “¿Me ayudaría un diccionario? ¿Un set para los vistos?” A menudo el propio entrevistador te da una pista si te oye razonar.

Frases que transmiten seniority

• “Antes de codificar, déjame confirmar que entiendo bien…”
• “Voy a empezar con la solución sencilla y luego la mejoro.”
• “Esto es O(n²); creo que puedo bajarlo, dame un segundo.”
• “¿Te parece bien este enfoque o prefieres que explore otro?”
• “Aquí asumo que no hay duplicados; si los hubiera, cambiaría esto.”

Fíjate que ninguna es sobre el algoritmo: son sobre cómo trabajas.

Errores que hunden entrevistas buenas

• Programar en silencio y enseñar el resultado al final. Aunque esté bien, perdiste la mitad de la nota.
• Lanzarte a teclear sin reformular ni preguntar casos límite.
• Defender una respuesta equivocada cuando te dan una pista. Escuchar y rectificar suma; cabezonear resta.
• Despreciar la fuerza bruta y quedarte atascado buscando la solución elegante.
• No probar el código antes de decir “ya está”.

El lado de comportamiento (no todo es código)

Casi todas las entrevistas tienen una parte de preguntas tipo “cuéntame un proyecto del que estés orgulloso” o “un problema técnico difícil que resolviste”. Prepárate 2-3 historias reales con estructura simple: situación → qué hiciste tú → resultado. Concretas, con tu papel claro y, si puedes, con un número. No hace falta más.

En resumen

Resolver el ejercicio es la mitad. La otra mitad es reformular, preguntar casos límite, decir tu plan, narrar mientras escribes, probar y dar la complejidad — y, cuando te bloquees, verbalizarlo en vez de callar. Eso es entrenable, y se nota más que un algoritmo perfecto. Repasa lo técnico con el cheatsheet del clúster.

Y si quieres llegar a la entrevista con la seguridad de quien domina Python de verdad —porque ha construido proyectos reales, no memorizado respuestas— ese es el camino del curso.