La preparación real: mucho más que practicar algoritmos
Una preparación sólida empieza por investigar el formato concreto: algunas empresas apuestan por preguntas clásicas de algoritmos y estructuras de datos (arrays, árboles, grafos), otras se centran en diseño de sistemas, proyectos para hacer en casa o programación en pareja sobre código realista. Averigua qué formato te espera —las reseñas de candidatos en plataformas como Glassdoor o una pregunta directa al equipo de selección suelen revelar la estructura. Dedica varias semanas a la preparación técnica, no solo un fin de semana: practica 1-2 ejercicios al día dentro de una categoría (arrays, luego cadenas de texto, luego árboles) en lugar de practicar de forma aleatoria. Igual de importante: repasa los fundamentos de tu herramienta principal (lenguaje, framework, base de datos), ya que los entrevistadores suelen preguntar por los compromisos técnicos (trade-offs) —por ejemplo, '¿por qué un hash map en lugar de un array?'. Quien conoce la solución pero no el razonamiento detrás suele sonar inseguro al explicarla, aunque el código sea correcto.
Programación en vivo: verbaliza tu proceso de pensamiento
La mayor diferencia entre una sesión de código en vivo sólida y una débil rara vez está en el código en sí, sino en la comunicación durante el proceso. Los entrevistadores no pueden leer tu mente: quedarte en silencio diez minutos mientras escribes parece una caja negra para la mayoría de los evaluadores, incluso si la solución final es correcta. En su lugar, establece una rutina clara: repite el enunciado con tus propias palabras, haz preguntas aclaratorias (¿tamaño de la entrada? ¿se permiten duplicados? ¿la entrada está ordenada?), esboza verbalmente 1-2 posibles enfoques junto con su complejidad temporal y espacial antes de escribir código, y narra brevemente qué estás haciendo y por qué mientras programas. Esta estructura —aclarar, planificar, implementar, probar— demuestra un pensamiento sistemático, aunque tu primera solución no sea la óptima. Un paso a menudo infravalorado: repasar activamente 1-2 casos de prueba al final, incluyendo un caso límite (entrada vacía, un único elemento, números negativos).
Cuando te quedas atascado: cómo reaccionar con seguridad
Casi todas las entrevistas técnicas incluyen un momento en el que el camino hacia la solución no está claro de inmediato —esto es algo esperado, no una señal de alarma. Lo que importa es cómo reaccionas. No te quedes en silencio: verbaliza el bloqueo: 'Mi primer enfoque con un bucle anidado sería O(n²); estoy pensando si un hash map podría reducirlo a O(n)'. Esto le da al entrevistador la oportunidad de orientarte en la dirección correcta, algo que forma parte explícita de la mayoría de los procesos. Usa las pistas de forma activa en lugar de verlas como un fracaso: los candidatos que toman una pista y avanzan con rapidez demuestran capacidad de aprendizaje y colaboración —ambos criterios clave, especialmente para roles de equipo. Lo mismo aplica a las preguntas de diseño de sistemas: empieza por los requisitos y las suposiciones (número de usuarios, carga de lectura frente a escritura) antes de esbozar la arquitectura, y piensa en voz alta sobre los compromisos técnicos (consistencia frente a disponibilidad, SQL frente a NoSQL) en lugar de buscar una única respuesta 'perfecta'.
Errores comunes incluso entre candidatos sólidos
El error más frecuente es empezar a programar de inmediato sin haber entendido bien el problema —esto suele obligar a descartar todo el enfoque a mitad de camino, con la consiguiente pérdida de tiempo valioso. Igual de arriesgado es ignorar por completo los casos límite (listas vacías, valores nulos, entradas muy grandes): los entrevistadores preguntan activamente por ellos si no los mencionas tú primero. Otro error clásico es el perfeccionismo excesivo: pulir demasiado tiempo la solución óptima en lugar de entregar primero una solución de fuerza bruta que funcione y optimizarla después —una solución que funciona, aunque no sea óptima, es casi siempre mejor que ninguna solución. Evita también esquivar las preguntas sobre compromisos técnicos con respuestas vagas como 'depende' sin justificación: sé concreto en su lugar: 'con un conjunto de datos pequeño elegiría X, pero con millones de registros me inclinaría por Y porque...'. Por último, no subestimes el cierre: prepara 2-3 preguntas bien pensadas para el equipo (stack tecnológico, proceso de revisión de código, frecuencia de despliegue) —esto demuestra interés genuino y se evalúa explícitamente en muchos procesos de selección.
En resumen
Prepárate de forma sistemática para el formato concreto de la entrevista, verbaliza tu proceso de pensamiento en todo momento, usa las pistas de forma activa en lugar de verlas como un retroceso, y entrega primero una solución funcional antes de optimizarla.