La peor entrevista técnica que vi

Hay entrevistas técnicas que te ayudan a entender si encajas con un equipo. Y hay otras que te dejan pensando que el problema no eras tú, sino el proceso completo.

La peor entrevista técnica que vi no falló por una sola cosa. Falló por acumulación: preguntas mal pensadas, expectativas invisibles, personas que no sabían qué estaban evaluando y una dinámica que parecía diseñada para medir resistencia, no capacidad. Si alguna vez saliste de una entrevista con la sensación de que te hicieron perder el tiempo, este artículo te va a sonar familiar.

Qué pasó en esa entrevista

La entrevista arrancó tarde. No 5 minutos tarde, sino casi 20. Ya con eso te das una idea de la prioridad que le daban al proceso. Cuando por fin entraron a la sala, eran tres personas: una de recursos humanos, una persona que parecía liderar el área técnica y otra que no habló casi nada durante toda la sesión. Eso importa más de lo que parece, porque una entrevista con demasiada gente sin roles claros suele convertirse en una mezcla rara de improvisación y validación social.

La primera parte fue normal. Me pidieron que me presentara, que explicara mi experiencia y que contara en qué tipo de productos había trabajado. Hasta ahí, todo bien. El problema empezó cuando la conversación saltó sin aviso de arquitectura a memorizar detalles de sintaxis, de ahí a preguntas de trivia sobre algoritmos y, luego, a un ejercicio en una pizarra que no tenía ninguna relación con el puesto.

No era un rol de investigación, ni de sistemas distribuidos, ni de performance a nivel de kernel. Era un puesto de desarrollo web con foco en producto. Aun así, la entrevista parecía salida de un checklist genérico de internet, como si alguien hubiera mezclado preguntas de varias vacantes y las hubiera lanzado sin revisar si tenían sentido para ese trabajo.

Lo más frustrante no fue que me hicieran preguntas difíciles. Lo difícil es normal. Lo frustrante fue que no había criterio visible. No se explicaba por qué una respuesta era mejor que otra, no había contexto del problema real del equipo y, sobre todo, no había señal de que la conversación estuviera conectada con el día a día del puesto.

La pregunta trampa que no medía nada

Hubo una pregunta que me quedó grabada: me pidieron que explicara cómo implementaría una estructura de datos específica desde cero, en la pizarra, sin editor, sin documentación y sin tiempo para pensar en voz alta. No porque eso fuera necesario para el trabajo, sino porque querían ver si “salía rápido”.

Ese tipo de ejercicio dice más sobre la cultura del entrevistador que sobre tu capacidad. Si tu trabajo diario consiste en leer código, discutir trade-offs, usar herramientas de búsqueda, revisar PRs y colaborar con otras personas, evaluar tu valor solo por lo que recuerdas de memoria es una mala señal.

La entrevista técnica no debería parecer un examen oral de universidad. Debería parecer una simulación razonable del trabajo real. Y si el trabajo real no se parece a escribir una estructura de datos en una pizarra, entonces la prueba está mal diseñada.

El problema no era la dificultad, era la arbitrariedad

Lo peor de todo es que no te daban feedback útil. Si te quedabas corto en algo, no te ayudaban a aterrizar el error ni a explorar cómo piensas. Solo seguían con otra pregunta, como si estuvieran tachando casillas.

Eso genera una dinámica absurda: el candidato siente que debe adivinar qué respuesta quieren oír, y el entrevistador cree que está midiendo “seniority”. En realidad, está midiendo qué tan bien toleras un proceso confuso.

Señales de alerta que puedes detectar como candidato

No todas las entrevistas malas son tan obvias desde el minuto uno. A veces empiezan bien y se degradan con el tiempo. Por eso conviene que tú también evalúes el proceso, no solo que te evalúen a ti.

Hay señales que, juntas, te dicen bastante sobre cómo trabaja una empresa. Una sola señal puede ser un accidente. Varias señales en la misma entrevista suelen ser un patrón.

1. La entrevista empieza tarde y nadie lo reconoce.
2. No te explican quiénes están en la sala ni qué rol cumple cada persona.
3. Las preguntas cambian de tema sin relación con el puesto.
4. Nadie define qué están evaluando exactamente.
5. Te piden resolver en vivo algo que no se parece al trabajo real.
6. El feedback es vago, tipo “queremos ver más profundidad” sin ejemplos.
7. Te hacen repetir la misma información en varias rondas porque el equipo no se coordinó.

Si ves dos o tres de estas señales, vale la pena frenar y hacer preguntas. No con actitud defensiva, sino con claridad profesional. Por ejemplo: “¿Qué competencias quieren validar en esta etapa?” o “¿Este ejercicio se parece a una tarea real del equipo?”. Si la respuesta es confusa, ya tienes información valiosa.

Preguntas que sí vale la pena hacer

Antes de entrar a una entrevista técnica, puedes preguntar cosas concretas. No para ponerte difícil, sino para entender el juego.

• ¿Qué tipo de problemas resuelve este equipo en un día normal?
• ¿Esta entrevista evalúa código, diseño, debugging o comunicación?
• ¿Habrá pair programming o pizarra, o todo será conversado?
• ¿Qué esperan de una persona en los primeros 90 días?
• ¿Cómo se toman las decisiones de contratación?

Estas preguntas no solo te ayudan a prepararte. También filtran empresas que improvisan frente a empresas que sí tienen un proceso razonable. Si se molestan porque preguntas, eso también te dice algo.

Qué revela un proceso roto de contratación

Un proceso roto casi nunca es solo un problema de recursos humanos. Muchas veces refleja desorden técnico, falta de alineación entre managers y una cultura que confunde rigor con dureza.

En la entrevista que vi, cada persona parecía evaluar una cosa distinta. Una quería ver comunicación. Otra quería ver precisión técnica. Otra parecía estar ahí porque “tocaba”. El resultado fue una conversación fragmentada donde nadie tenía una definición clara de éxito.

Eso pasa más de lo que debería. Según la documentación de entrevistas estructuradas de Google, definir criterios antes de entrevistar ayuda a reducir sesgos y mejora la consistencia de la evaluación. Puedes revisar su guía pública sobre entrevistas estructuradas aquí: https://rework.withgoogle.com/guides/hiring-use-structured-interviewing/steps/introduction/

También vale la pena mirar el marco de entrevistas estructuradas de la Society for Human Resource Management: https://www.shrm.org/topics-tools/tools/toolkits/structured-interviewing

La idea no es copiar una receta de Silicon Valley. La idea es básica: si no sabes qué estás midiendo, vas a tomar decisiones pobres con mucha confianza.

Cuando la entrevista castiga más de lo que evalúa

Hay empresas que convierten la entrevista en una prueba de aguante. Te interrumpen, te corrigen por detalles menores, te cambian el rumbo a mitad de respuesta y luego esperan que sigas como si nada. Eso no mide colaboración. Mide tolerancia al caos.

Y ojo: trabajar en tecnología sí implica presión, bugs, deadlines y conversaciones incómodas. Pero una entrevista no debería simular un mal ambiente de trabajo para ver si “aguantas”. Si el proceso ya se siente hostil, imagina cómo será el día a día.

En Latinoamérica esto pega más fuerte porque muchas personas no tienen el lujo de escoger entre 10 ofertas. A veces aceptas una entrevista mala porque necesitas el trabajo. Justamente por eso conviene reconocer patrones temprano y no normalizar procesos que te dejan agotado antes de empezar.

Lo que una empresa pierde cuando entrevista así

Una mala entrevista no solo espanta candidatos buenos. También le cuesta tiempo al equipo, daña la reputación y reduce la probabilidad de contratar a la persona correcta.

Piensa en esto: si tu proceso obliga a 4 personas a participar en 6 rondas mal coordinadas, estás gastando muchas horas para tomar una decisión con poca señal. Si además el candidato sale confundido, probablemente no acepte la oferta aunque sea buena.

Las empresas suelen hablar de “candidate experience” como si fuera marketing. En realidad es eficiencia operativa. Un proceso claro reduce fricción, ahorra tiempo y mejora la calidad de la decisión.

Cómo debería verse una entrevista técnica más sana

No existe una única forma correcta de entrevistar. Pero sí hay principios bastante claros. La entrevista debe parecerse al trabajo real, tener criterios visibles y respetar el tiempo de ambas partes.

Una estructura sana suele incluir menos improvisación y más intención. Por ejemplo, una conversación inicial para contexto, una prueba práctica alineada con el rol y una etapa final donde se discuten trade-offs o diseño. No necesitas 7 rondas para saber si alguien puede trabajar contigo.

Aquí va una versión más razonable de un proceso para un puesto de desarrollo web:

Ese tipo de estructura no garantiza una buena contratación, pero sí reduce el ruido. Y reduce el riesgo de que alguien brillante quede fuera por nervios o por una pregunta mal planteada.

Diseñar mejor la entrevista

Si tú participas del lado de contratación, estas son prácticas que ayudan bastante:

1. Define 3 a 5 competencias máximas para evaluar.
2. Asigna una competencia por bloque de entrevista.
3. Usa una rúbrica simple con ejemplos de comportamiento.
4. Prefiere ejercicios cercanos al trabajo real.
5. Limita la cantidad de entrevistadores por sesión.
6. Documenta qué evidencia te llevó a decir sí o no.

No necesitas un sistema perfecto. Necesitas un sistema que permita comparar candidatos de forma consistente. Si cada entrevistador improvisa su propia prueba, luego nadie puede defender la decisión con claridad.

Qué puede hacer el candidato para cuidarse

Tú también puedes protegerte un poco mejor sin sonar agresivo. No se trata de pelear con el entrevistador, sino de hacer preguntas que te ayuden a entender si vale la pena seguir.

• Pide una descripción concreta del trabajo real.
• Pregunta cómo se ve el éxito en los primeros 3 meses.
• Aclara si la entrevista incluye código en vivo, pizarra o take-home.
• Si cambian las reglas a mitad del proceso, pregunta por qué.
• Si el trato es desordenado desde el inicio, toma nota.

La clave está en no romantizar la mala experiencia. Que una empresa tenga marca conocida o pague bien no compensa un proceso que te trata como un número más.

Lo que aprendí de esa experiencia

Después de esa entrevista entendí algo simple: una mala entrevista no siempre significa que eres un mal candidato. A veces significa que la empresa no sabe contratar bien. Y eso cambia por completo cómo interpretas el resultado.

También aprendí a prestar más atención a la forma, no solo al contenido. La puntualidad, la claridad de las instrucciones, la coherencia entre preguntas y rol, y la calidad del feedback dicen muchísimo sobre la organización.

Si tú estás buscando trabajo en tecnología, no te obsesiones solo con “pasar”. También evalúa si quieres entrar a un lugar donde entrevistar ya se siente desordenado. Porque si el proceso de entrada es caótico, el trabajo probablemente también lo sea.

Y si tú contratas talento, vale la pena hacer la pregunta incómoda: ¿esta entrevista nos ayuda a elegir mejor o solo nos hace sentir más exigentes? Si la respuesta honesta es lo segundo, toca rediseñar.

Tabla resumen

La peor entrevista técnica que vi no fue memorable por ser dura. Fue memorable porque dejó claro cuánto daño hace un proceso cuando nadie se pone de acuerdo sobre qué está evaluando. Y esa lección sirve tanto si estás buscando trabajo como si estás armando entrevistas para contratar.