La primera vez que te enfrentas a una entrevista técnica suele dar más miedo del que debería. Parte del problema es que se prepara mal: mucha gente memoriza soluciones a problemas concretos de plataformas de práctica, y cuando la pregunta cambia ligeramente en la entrevista real, se bloquean. Una entrevista técnica no evalúa si conoces la solución exacta a un problema concreto, evalúa cómo razonas cuando no la conoces de memoria.
Esto cambia por completo cómo deberías prepararte. En vez de acumular decenas de ejercicios resueltos, conviene entender el proceso: cómo se estructura la entrevista, qué tipo de preguntas vas a encontrar y qué comportamiento espera ver quien está al otro lado.
Cómo se estructura una entrevista técnica típica
La mayoría de procesos siguen un patrón parecido, aunque el orden y el número de fases varían según la empresa:
- Screening inicial: una llamada corta, normalmente con RRHH, para confirmar experiencia, expectativas salariales y disponibilidad.
- Entrevista técnica en vivo: resolver uno o varios ejercicios de código, a veces en un editor compartido, a veces en pizarra virtual.
- Entrevista de diseño o arquitectura: más habitual a partir de perfiles con algo de experiencia, donde se discute cómo diseñarías un sistema concreto.
- Entrevista con el equipo o el manager: preguntas de encaje, forma de trabajar y motivación.
Si estás empezando y aún no tienes claro qué perfil se espera de ti en cada fase, conviene tener en mente las diferencias reales entre un perfil junior y uno senior: la entrevista se ajusta a lo que se espera de cada etapa, no todos los entrevistadores buscan lo mismo.
Preguntas de algoritmos y estructuras de datos
Es la parte que más ansiedad genera, pero también la más entrenable. No buscan que resuelvas el problema al primer intento con la solución óptima; buscan ver cómo llegas hasta ahí. Un ejemplo típico: dado un array de números, encontrar dos que sumen un valor objetivo.
def encontrar_pareja(numeros, objetivo):
vistos = {}
for i, n in enumerate(numeros):
complemento = objetivo - n
if complemento in vistos:
return (vistos[complemento], i)
vistos[n] = i
return None
print(encontrar_pareja([2, 7, 11, 15], 9)) # (0, 1)
La solución ingenua (comparar cada par con dos bucles anidados) también es válida como punto de partida: decirla en voz alta, calcular su complejidad (O(n²)) y luego proponer la versión optimizada con un diccionario (O(n)) demuestra exactamente el razonamiento que se busca. Llegar callado a la solución óptima sin explicar el camino puntúa peor que llegar hablando a una solución que funciona, aunque no sea la más eficiente.
Preguntas sobre tu código y tus decisiones técnicas
Además de ejercicios nuevos, es habitual que te pregunten sobre proyectos de tu portfolio: por qué elegiste tal librería, cómo estructuraste el repositorio o si el proyecto tiene tests. Aquí es donde se nota si tu flujo con Git y GitHub es sólido y si el código que subes está cuidado, no solo funcional. Cada vez es más frecuente también que pregunten por tu proceso de pruebas: si nunca has escrito un test automatizado, vale la pena dedicar un rato a una introducción práctica a testing con Jest antes de una entrevista, aunque solo sea para poder hablar del tema con propiedad.
Preguntas de comportamiento y encaje en el equipo
No son "relleno": para muchos equipos pesan tanto como la parte técnica. Preguntas del tipo "cuéntame un conflicto técnico que hayas tenido con un compañero" o "describe un momento en el que tuviste que aprender algo rápido para un proyecto" buscan entender cómo trabajas en equipo, no solo si sabes programar en solitario. Un formato útil para prepararlas es la estructura situación → tarea → acción → resultado: describe brevemente el contexto, qué se esperaba de ti, qué hiciste y qué pasó al final. Evita respuestas vagas tipo "trabajo bien en equipo"; cuenta un caso concreto.
Ponte a prueba
Antes de seguir, comprueba cómo reaccionarías en algunas situaciones reales de entrevista.
¿Qué responderías en esta situación?
Errores comunes que alargan el proceso
Hay patrones que se repiten en candidatos que no pasan de la primera fase técnica: no preguntar para aclarar el enunciado antes de empezar a escribir código, asumir requisitos que no se han dicho, y no probar la solución con ningún ejemplo antes de darla por terminada. Ninguno de estos errores tiene que ver con el nivel técnico real de la persona, sino con el proceso que sigue durante la entrevista. Practicar ese proceso —aclarar, pensar en voz alta, probar, revisar— es tan importante como repasar algoritmos.
Por último, si estás valorando dar el salto al mundo freelance en vez de (o además de) buscar una entrevista tradicional, el proceso de selección cambia bastante: en ese caso te será más útil leer sobre cómo conseguir tus primeros clientes como programador freelance, donde la "entrevista" suele ser una conversación mucho más informal centrada en resultados concretos.