Error #1: Lanzarte a programar sin aclarar los requisitos
Llega la pregunta. Tu instinto es empezar a programar de inmediato para demostrar velocidad y confianza. Esto casi siempre es un error.
Los problemas de entrevista técnica casi nunca son tan simples como parecen a primera vista. Las restricciones están ocultas, los casos límite se omiten deliberadamente, y la interpretación «correcta» a menudo depende de información que todavía no tienes. Lanzarte directamente a implementar el problema tal como lo entendiste — antes de confirmar que lo entendiste bien — es la forma en que los candidatos pasan 20 minutos resolviendo el problema equivocado.
Más importante aún, los entrevistadores dejan deliberadamente ambiguos los requisitos para ver si reconoces la ambigüedad y haces buenas preguntas. Un candidato que pregunta «¿Debo asumir que el arreglo de entrada está ordenado?» antes de programar demuestra el mismo criterio que un buen ingeniero aporta a proyectos reales. Un candidato que asume en silencio que el arreglo está ordenado — y construye su solución sobre esa suposición — demuestra lo contrario.
Antes de escribir una sola línea de código, verbaliza tu comprensión del problema y haz al menos dos preguntas aclaratorias: una sobre restricciones (tamaño de entrada, tipos de datos esperados, casos límite) y otra sobre requisitos (¿qué debería devolver la función para una entrada vacía? ¿qué pasa si hay duplicados?). Luego confirma: «Entonces mi objetivo es devolver X dado Y — ¿es correcto?». Solo entonces empieza a programar.
Error #2: Quedarte en silencio mientras resuelves el problema
Este es el error que más ofertas cuesta porque es invisible para el candidato que lo comete. Estás pensando. Duro. Estás avanzando de verdad. Pero lo haces todo en tu cabeza, y el entrevistador te observa escribir en silencio, sin poder saber si vas por buen camino, si estás completamente perdido, o simplemente eres lento.
Los entrevistadores técnicos no solo evalúan tu solución — evalúan cómo sería trabajar contigo. Un miembro del equipo que se queda callado ante un problema difícil es alguien con quien no puedes calibrar, no puedes ayudar y no puedes colaborar. El candidato silencioso envía exactamente esa señal, incluso si su solución final es correcta.
Piensa en voz alta. Di qué estás considerando y por qué lo descartas: «Estoy pensando primero en un enfoque de fuerza bruta O(n²) solo para establecer corrección, y luego buscaré optimizar». Di cuándo te atascas: «Sé que necesito registrar qué elementos he visto — estoy decidiendo entre un mapa hash y un arreglo ordenado para eso». Esta narración permite al entrevistador ver tu proceso de pensamiento, ayudarte si te desvías, y evaluar tu enfoque de resolución de problemas independientemente de si llegas a la solución óptima.
Si el silencio es un hábito bajo presión, practica con una herramienta de entrevista simulada en vivo — InterviewAce puede avisarte cuando te quedas demasiado callado y animarte a verbalizar tu pensamiento.
Error #3: No probar ni depurar tu solución
Muchos candidatos escriben su solución, la miran brevemente y dicen «Creo que esto está bien» — y luego la entregan. Esto señala que no tienes el instinto de probar tu propio trabajo, uno de los instintos más importantes en ingeniería de software.
Los entrevistadores en empresas fuertes suelen tener una política tácita: una solución que el candidato no ha probado se considera incompleta, sin importar si parece correcta. Quieren verte aplicar los mismos hábitos que aportarías a un pull request real.
Después de escribir tu solución, recórrela siempre manualmente con al menos dos casos de prueba: un caso normal y un caso límite. Ve línea por línea, registra los valores de las variables y verifica la salida. Narra mientras lo haces: «Bien, si la entrada es [3, 1, 4], en este paso i es 0 y current_max es 3, así que...». Este proceso detecta errores reales y demuestra madurez de ingeniería. Para los casos límite, piensa sistemáticamente en: entrada vacía, entrada de un solo elemento, elementos todos iguales, números negativos (si aplica), y el tamaño de entrada máximo posible.
Error #4: Comunicación débil en System Design
Las entrevistas de System Design son distintas de las entrevistas de programación en un aspecto crucial: no hay una única respuesta correcta. El entrevistador evalúa tu proceso de razonamiento, tu conciencia de los trade-offs y tu capacidad de dirigir una conversación de diseño. Los candidatos que presentan un solo diseño con confianza, sin explorar alternativas ni reconocer trade-offs, a menudo fallan las rondas de System Design incluso cuando su arquitectura es técnicamente sólida.
Errores comunes: saltar directamente a diagramas de componentes antes de establecer requisitos y escala, usar palabras de moda («usaremos Kafka para el event stream») sin explicar el razonamiento, y no mencionar los trade-offs («una base de datos relacional funciona aquí, pero a 10 veces la escala actual empezaríamos a ver contención de escritura en esta tabla»).
Estructura cada respuesta de System Design con el mismo enfoque de cinco pasos: (1) Aclarar requisitos y restricciones — funcionales y no funcionales, expectativas de escala. (2) Estimar la escala — QPS, volumen de datos, ratio de lectura/escritura. (3) Proponer un diseño de alto nivel — componentes principales, flujos de datos. (4) Profundizar en las partes interesantes — allí donde vive la complejidad. (5) Discutir trade-offs y alternativas — qué elegiste y por qué no elegiste las alternativas.
Practica decir «Elegí X sobre Y por el trade-off Z» como hábito. Los entrevistadores en niveles sénior evalúan si entiendes por qué tu diseño hace los trade-offs que hace — no solo que funciona.
Error #5: Rendirte en lugar de pensar en voz alta
Cuando los candidatos chocan con un muro genuino — no ven el camino a seguir — a menudo se quedan callados, se paralizan y terminan diciendo «No estoy seguro de cómo continuar». Esto cierra la entrevista y acaba con las posibilidades del candidato de recuperarse, incluso si lo habría resuelto con 2 minutos más de pensamiento estructurado.
Aquí hay algo que la mayoría de los candidatos no sabe: la mayoría de los entrevistadores quieren dar pistas. No están ahí para verte fallar — están tratando de evaluar cuál es tu techo, y un buen entrevistador te guiará más allá de un bloqueo para ver hasta dónde puedes llegar con apoyo. Pero solo pueden ayudarte si saben dónde estás atascado.
En lugar de quedarte en silencio cuando te atascas, narra tu situación: «Sé que necesito registrar algún estado entre iteraciones, pero no veo de inmediato la estructura de datos correcta. Déjame pensar qué propiedades importan aquí...». Esto señala que sigues implicado, le da al entrevistador la oportunidad de ayudarte, y a menudo desencadena tu propia solución — el acto de articular en qué estás atascado a menudo saca a la luz la respuesta.
Si de verdad necesitas una pista, pídela directamente y sin vergüenza: «Creo que necesito un empujón aquí — ¿hay alguna propiedad de la estructura de datos en la que debería estar pensando?». Esto es profesional. Quedarte en silencio no lo es.
Extra: cómo prepararte para que estos errores no ocurran
Conocer estos errores intelectualmente no evita cometerlos bajo la presión de la entrevista. Por eso importa tanto practicar en condiciones realistas. Algunos principios de preparación de entrevistas técnicas que funcionan:
- Practica en una pizarra o un documento compartido, no en tu IDE. Tu IDE tiene autocompletado, resaltado de sintaxis y retroalimentación instantánea de errores. Las plataformas de entrevista no. Practica sin esa red de seguridad para no depender de ella.
- Cronométrate siempre. Una solución que consigues en 45 minutos relajado podría tomarte 20 minutos en una entrevista — o podría tomarte 55. Conoce tu velocidad real en problemas de dificultad media antes de estar en un entorno real.
- Haz al menos 5 entrevistas simuladas con una persona o un entrevistador de IA — no solo LeetCode en solitario. Los hábitos de comunicación (pensar en voz alta, aclarar requisitos, probar) deben construirse mediante práctica realista, no ejercicios de programación en solitario.
- Haz un balance después de cada sesión. ¿Cuál de estos cinco errores cometiste? ¿Dónde te quedaste callado? ¿Qué asumiste sin preguntar? Cada error en la práctica es uno que no cometerás en la entrevista real.
Para practicar entrevistas técnicas asistidas por IA, InterviewAce ofrece sesiones técnicas simuladas donde puedes practicar pensar en voz alta con una IA que evalúa tanto tu solución como tu proceso de comunicación. Combínalo con la guía de preparación de entrevistas más amplia para cubrir también el lado del comportamiento y la logística.