Cómo preparar una entrevista técnica de programación

Una entrevista técnica no premia solo a quien sabe más algoritmos, sino a quien piensa con claridad bajo presión y sabe comunicarlo. Muchos programadores competentes fallan no por no saber resolver el problema, sino por bloquearse en silencio, saltar directo a escribir código sin plantear el enfoque o no explicar su razonamiento. En esta guía tienes un plan de estudio realista, las prioridades de estructuras de datos y algoritmos, la técnica de pensar en voz alta, cómo sobrevivir a un live coding compartiendo pantalla y una introducción al system design.

Un plan de estudio realista

Estudiar sin plan lleva a saltar de tema en tema sin dominar ninguno. Ordena la preparación en fases y respeta el orden, porque cada una se apoya en la anterior:

1. Empieza por Big O. Antes de resolver nada, entiende cómo se mide la eficiencia en tiempo y espacio. Es el idioma con el que justificarás cada decisión en la entrevista.
2. Domina las estructuras de datos base: arrays, strings, listas enlazadas, pilas, colas, tablas hash, árboles y grafos. Necesitas saber cuándo usar cada una y su coste.
3. Practica los patrones de algoritmos: dos punteros, ventana deslizante, búsqueda binaria, recursión, backtracking, BFS/DFS y programación dinámica básica.
4. Resuelve problemas de forma deliberada. Un objetivo razonable son entre 100 y 200 problemas de LeetCode repartidos en el tiempo, priorizando la variedad de patrones sobre el número bruto.
5. Simula entrevistas completas en voz alta, con reloj, para entrenar la comunicación además del código.

Más importante que la cantidad es la calidad: resolver 100 problemas entendiendo a fondo el patrón de cada uno vale mucho más que 400 copiando soluciones. Cuando termines uno, pregúntate qué patrón era y cuándo lo reconocerás la próxima vez.

En una entrevista técnica no compites por escribir la solución más rápida, sino por demostrar cómo piensas. El código es la prueba; el razonamiento es lo que te contratan.

La técnica de pensar en voz alta

El error más caro es quedarse callado pensando y soltar el código ya terminado. El entrevistador no puede leer tu mente: necesita oír tu razonamiento para evaluarte, y además ayudarte si te desvías. Verbaliza todo el proceso, desde que entiendes el problema hasta que pruebas la solución. Un método fiable en seis pasos:

• Leer y reformular: repite el problema con tus palabras para confirmar que lo entiendes.
• Preguntar: aclara casos límite, tamaño de la entrada, valores nulos o duplicados. Nunca asumas en silencio.
• Proponer un enfoque: explica la idea antes de escribir, empezando por una solución de fuerza bruta si hace falta y comentando su complejidad.
• Optimizar: identifica el cuello de botella y propón una mejora, justificando el nuevo Big O.
• Codificar: escribe hablando de lo que haces, con nombres claros.
• Probar: recorre tu código con un ejemplo y con casos límite, corrigiendo lo que falle.

Si te atascas, dilo en voz alta y razona alternativas; muchas veces el entrevistador te dará una pista si ve que piensas de forma estructurada. Quedarte mudo cinco minutos es peor que equivocarte hablando.

El live coding y la pantalla compartida

En el live coding resuelves el problema en directo mientras compartes la pantalla, y la presión de ser observado es real. Practica en condiciones parecidas: cronometrado, en un editor sencillo y verbalizando, porque hacerlo en tu IDE cómodo y en silencio no entrena lo mismo. Comparte solo la ventana del ejercicio y cierra antes lo que no quieras enseñar. Gestiona el tiempo: dedica los primeros minutos a entender y plantear, no te lances a teclear de inmediato. Y si la plataforma no tiene autocompletado, acostúmbrate a escribir sintaxis a mano.

Bases de system design

A partir de perfiles semi-senior aparecen preguntas de diseño de sistemas: "diseña un acortador de URLs", "diseña un feed de noticias". No buscan una respuesta perfecta, sino ver cómo estructuras un problema abierto. Un esquema para empezar, incluso siendo junior:

1. Aclara los requisitos y define el alcance: qué debe hacer el sistema y qué no.
2. Estima la escala: usuarios, peticiones por segundo, volumen de datos.
3. Dibuja los componentes de alto nivel: clientes, API, base de datos, caché, balanceador.
4. Profundiza en una o dos piezas y comenta compromisos: consistencia frente a disponibilidad, cómo escalar, dónde poner caché.

Preguntas de teoría que conviene dominar

Además de resolver problemas, muchas entrevistas incluyen preguntas cortas de fundamentos para comprobar que entiendes lo que usas. No requieren código, pero un titubeo aquí resta. Repasa hasta poder explicarlas con tus palabras y un ejemplo:

• ¿Qué es Big O y por qué importa? Sé capaz de dar la complejidad de las operaciones habituales sobre cada estructura.
• Diferencia entre un array y una lista enlazada, y cuándo elegir cada uno.
• Cómo funciona una tabla hash por dentro y qué pasa con las colisiones.
• Diferencia entre recursión e iteración, y qué es la pila de llamadas.
• Conceptos de tu lenguaje: paso por valor o por referencia, gestión de memoria, tipado, según lo que uses a diario.
• En preguntas web: qué ocurre al escribir una URL en el navegador, o la diferencia entre SQL y NoSQL.

Errores que hunden una entrevista técnica

Muchos suspensos no vienen de no saber, sino de tropezar en lo evitable. Vigila estos fallos, que se repiten una y otra vez:

• Lanzarse a codificar sin entender el problema ni preguntar por los casos límite.
• Quedarse en silencio al atascarse, en lugar de razonar en voz alta y pedir una pista.
• Ignorar la complejidad: escribir una solución que funciona pero es ineficiente sin siquiera mencionarlo.
• No probar el código: entregarlo sin recorrerlo con un ejemplo ni pensar en entradas raras.
• Discutir o ponerse a la defensiva cuando el entrevistador sugiere una mejora, en vez de tomarlo como una pista.
• Memorizar soluciones sin entenderlas: a la primera pregunta de seguimiento, el castillo se derrumba.

La parte de comportamiento también cuenta

Una entrevista técnica no es solo código. Casi siempre hay una parte en la que preguntan por tus proyectos, cómo trabajaste en equipo, un bug difícil que resolviste o una decisión técnica que defendiste. Prepárala con el método STAR igual que cualquier otra pregunta de comportamiento; tienes la guía completa del método STAR para estructurar esas historias. Ten a punto dos o tres relatos técnicos: un problema espinoso que depuraste, una vez que tuviste que aprender algo nuevo a contrarreloj y una discusión de arquitectura en la que llegaste a un acuerdo. Los equipos contratan a personas con las que da gusto trabajar, no solo a quien pasa el test.

Scan & solve: explicar, no pegar

Cuando te enfrentas a un ejercicio de código en pantalla, la función scan & solve de InterviewOS captura el problema y te devuelve una solución explicada paso a paso, con el razonamiento detrás de cada decisión y su complejidad. La clave es cómo la usas: la filosofía es explicar, no pegar. Sirve para entender el patrón, ver un enfoque razonado y aprender más rápido, no para copiar una respuesta que no sabrías defender. En una prueba, tu valor está en explicar tu propia solución; si sueltas código que no comprendes, la primera pregunta de seguimiento te delata.

La ventana de scan & solve, como el resto de la app de escritorio, permanece oculta de la captura y de la compartición de pantalla: es apoyo privado para ti mientras estudias o durante una prueba, invisible en la pantalla compartida. El objetivo es que aprendas y expliques tu propio razonamiento, solo que más rápido. Cada escaneo cuesta 5 créditos y una respuesta profunda 2, con un tope de gasto firme; tienes el desglose en precios.

Para cuidar la parte no técnica de la entrevista, repasa la guía sobre entrevistas por videollamada y su checklist, regístrate gratis en interviewoslab.com y explora la página en español.