Por Qué Buenos Ingenieros Fallan en Entrevistas Técnicas (Y Cómo Solucionarlo)

Una vez pasé tres semanas desenredando un deadlock distribuido entre cuatro microservicios. Desplegué un fix que aguantó años. Dos meses después, me quedé congelado con un problema de dificultad media en LeetCode durante un phone screen. Rechazado.

Cuanto más hablaba con otros devs senior, más escuchaba la misma historia. Una staff engineer que había diseñado un sistema de detección de fraude en tiempo real — rechazada porque su respuesta de system design “carecía de estructura.” Un backend lead que operaba una plataforma de pagos a cinco nueves, bloqueado por un problema de sliding window que no había tocado desde la universidad.

Ser buen ingeniero y ser bueno en entrevistas son habilidades diferentes. No ligeramente diferentes. Fundamentalmente diferentes.

El Desajuste Que Nadie Te Advierte

Tu trabajo real te da tiempo. Documentación, compañeros, la posibilidad de alejarte y volver después de un café. Una entrevista te quita todo eso. Cuarenta y cinco minutos. Un desconocido evaluándote. Sin atajos de IDE, sin “déjame pensarlo esta noche.”

Tres cosas destruyen silenciosamente a los candidatos con experiencia:

• Brecha de contexto. Las habilidades que usas a diario — navegar código legacy, hacer tradeoffs pragmáticos, desbloquear a compañeros — no son lo que se está midiendo. El músculo que se evalúa es uno que rara vez ejercitas.
• Inversión de la evaluación. En el trabajo, los resultados importan. ¿El sistema aguantó? En entrevistas, el proceso importa. ¿Hablaste sobre tu razonamiento? ¿Mencionaste edge cases antes de que te lo pidieran?
• El estrés haciendo lo que hace el estrés. Presión alta encoge tu memoria de trabajo. Eso no es un fallo personal. Es cómo funcionan los cerebros.

Nada de esto refleja lo bueno que eres en tu trabajo. Todo afecta si te contratan.

La Maldición de Saber Demasiado

Esto es lo que pasa. Los ingenieros junior tienen dificultades porque les falta conocimiento. Los senior tienen dificultades porque han internalizado tanto que se saltan la explicación.

Alguien te pide que diseñes una capa de cache. Dices “LRU con un hash map y doubly linked list” en unos cuatro segundos. Para ti, son años de experiencia hablando. Para el entrevistador, es una afirmación sin soporte. Querían escuchar por qué LRU y no LFU, qué motivó la elección de estructura de datos, cómo funciona el eviction bajo presión.

La solución suena casi demasiado simple: narra tu razonamiento como si le explicaras a un colega agudo que no ha visto este problema particular. Recorre el por qué, no solo la respuesta.

Lo opuesto también ocurre. Alguien pregunta “¿Cómo funciona HTTPS?” y te lanzas a una inmersión de doce minutos sobre TLS handshakes, cadenas de certificados y evolución del protocolo. El entrevistador quería noventa segundos.

Empieza desde arriba, luego ofrece profundidad: “Si quieres puedo profundizar en cualquiera de estos puntos — ¿qué te interesa más?” Esa sola frase muestra rango sin ahogar a nadie.

El Silencio No Es Tu Amigo

Esta me pegó personalmente. Me quedo callado cuando estoy trabajando algo difícil. Siempre ha sido así. En el trabajo, a nadie le importa — ven el commit después. En una entrevista, veinte segundos de silencio y el entrevistador empieza a escribir “el candidato parecía atascado” en sus notas.

No estás atascado. Estás pensando. Pero no tienen forma de saberlo.

Narra los movimientos grandes. No cada micro-pensamiento — eso agota a todo el mundo — sino los estructurales. “Creo que esto es un problema de camino más corto, así que me inclino hacia BFS. Déjame pensar a qué mapean los nodos y las aristas…” Ese tipo de cosas.

También abre una puerta. Si vas en una dirección poco productiva, el entrevistador puede redirigirte con una pista pequeña. Si estás en silencio, no pueden ayudarte aunque quieran.

El problema opuesto es el diseño flujo de consciencia. “Quizás una base de datos… o un cache… necesitaremos una cola…” Así funciona el diseño real — desordenado, exploratorio. Pero en una entrevista se lee como disperso. Declara los requisitos primero, esboza el enfoque, luego profundiza en los componentes. La estructura le gana a la brillantez cuando alguien te está evaluando en vivo.

Tus Algoritmos Se Oxidaron (Deja de Sentirte Mal Por Eso)

¿Honestamente? La mayoría de los ingenieros en activo no implementan algoritmos de ordenamiento a mano. Llamas funciones de librería. Usas patrones probados. Eso no es pereza — es buena ingeniería.

Pero las entrevistas evalúan implementación cruda. Si no has escrito manualmente un binary search en tres años porque has estado llamando a bisect.bisect_left() como una persona razonable… esos errores de off-by-one te van a encontrar. Eso es atrofia, no incompetencia.

Dos a cuatro semanas de práctica diaria lo traen de vuelta. Enfócate en patrones — sliding window, two pointers, BFS/DFS, DP básica — en lugar de memorizar problemas específicos. La fluidez vuelve más rápido de lo que esperarías.

“Diseño sistemas que sirven a millones de usuarios. ¿Por qué debería practicar problemas de juguete?” Mira, entiendo la frustración. Pero la entrevista es el juego tal como existe ahora. Negarte a prepararte porque el formato es imperfecto es una postura con principios — y también una forma estupenda de quedarte exactamente donde estás.

Cerrar la Brecha a Propósito

Si sigues siendo rechazado a pesar de ser bueno en tu trabajo, haz una mock interview y pide feedback honesto. No de un amigo que será amable. De alguien que te diga que murmuras cuando estás nervioso o que saltas a implementar antes de clarificar los requisitos.

Luego identifica la brecha real. ¿Débil en algoritmos? Practica a diario. ¿Malo comunicando tu proceso? Haz más mocks y grábate. ¿La ansiedad arruina tu memoria de trabajo? Eso necesita exposición a través de repetición más que cualquier otra cosa técnica.

La mayoría de los ingenieros solo estudian — resolviendo problemas solos en un escritorio. Eso es la mitad del trabajo. La otra mitad es rendir bajo presión de tiempo con alguien mirándote. Necesitas ambas.

Incluso cuando no estás buscando trabajo, una mock interview cada pocos meses mantiene el óxido a raya. Entrevistar es una habilidad que se degrada con el descuido.

FAQ

¿Por qué los ingenieros senior fallan en entrevistas más de lo esperado?

Porque la experiencia juega en tu contra de formas raras. Te saltas pasos en tus explicaciones, sobredimensionas las preguntas de diseño, o simplemente has dejado que los fundamentos de algoritmos se atrofien porque — razonablemente — no los has necesitado en años. El formato de entrevista penaliza las tres cosas.

¿Vale la pena practicar algoritmos si nunca los voy a usar en el trabajo?

Yo antes decía que no, por principio. Ahora creo que es el enfoque equivocado. No practicas algoritmos porque reflejen el trabajo real. Los practicas porque son el precio de entrada. Y las habilidades subyacentes — descomposición, debugging sistemático, reconocimiento de patrones — realmente se transfieren. No perfectamente, pero lo suficiente.

¿Cuánto tiempo toma realmente la preparación para entrevistas?

Depende de la brecha. Si tus fundamentos son sólidos y solo necesitas sacudir el óxido, dos a tres semanas de práctica diaria enfocada pueden llevarte ahí. Si estás cambiando de dominio o no has hecho esto en más de cinco años, presupuesta seis a ocho semanas. El error es crammar durante tres días y preguntarte por qué no funcionó.

¿Debería decirle al entrevistador que estoy nervioso?

Brevemente, sí. “Estoy un poco nervioso, tenme paciencia” es humano y la mayoría de los entrevistadores lo respetan. Pero no te quedes en ello. Reconócelo una vez y sigue adelante. Lo que ayuda más que admitir nervios es haber practicado lo suficiente para que tu preparación te sostenga incluso cuando aparece la ansiedad.

¿Quieres prepararte con estructura en vez de con suposiciones? Mira lo que estamos construyendo →