Errores que frenan a testers juniors en entrevistas

Hay testers juniors que saben testing. Que estudiaron, practicaron, hicieron proyectos. Y aun así, se quedan afuera en las entrevistas.

No porque les falte conocimiento. Porque cometen errores que son invisibles hasta que alguien te los señala.

Estos son los que veo una y otra vez. Tanto en entrevistas que hago yo para mis equipos acá en Kiwilandia, como lo que me cuentan ustedes mismos en las mentorías

Hablar de herramientas sin poder defenderlas

El CV dice Selenium, Jira, Postman, Cypress. El entrevistador pregunta: "¿Cómo lo usabas?"

Y ahí hacen agua.

Listar herramientas sin tener una historia concreta detrás es peor que no mencionarlas. Una herramienta bien explicada (cuándo la usabas, por qué, qué problema resolvía) vale más que cinco nombres tirados al aire.

Lo que funciona: por cada herramienta que ponés en el CV, prepará una historia. No técnica. Una historia: qué estabas haciendo, cómo la usabas, qué aprendiste, qué resolviste, qué NO resolvió...

No tener ejemplos de nada

"Tengo experiencia en testing funcional." Bien. ¿De qué producto? ¿Qué probabas? ¿Cuál fue el bug más importante que encontraste?

El candidato sin ejemplos parece alguien que hizo las cosas en piloto automático. Y eso es exactamente lo opuesto al perfil que busca un entrevistador.

Lo que funciona: antes de cualquier entrevista, preparate tres historias. Un bug crítico que encontraste. Una situación complicada que resolviste. Una decisión de testing que tomaste y por qué. Con eso cubrís el 80% de las preguntas de experiencia.

Decir "sí" a todo sin poder sostenerlo

"¿Conocés Cypress?" Vos: "Sí, sí, lo conozco."

La siguiente pregunta es siempre de seguimiento. Y si no podés explicar ni qué tipo de tests escribe Cypress ni en qué capa de la pirámide aplica, generaste una señal mucho peor que haber dicho que no lo usaste todavía.

La honestidad calibrada gana. La onda no es decir "no sé nada". Se trata de ser preciso con lo que sabés y lo que no. "No lo usé, pero entiendo qué hace y lo tengo en mi lista" es una respuesta sólida. Muchos piensan que no, pero creeme que si.

Confundir testing con ejecutar casos de prueba

Cuando le preguntás a alguien cómo enfoca el testing de una nueva feature y la respuesta es "ejecuto los casos del plan de testing", hay un problema.

Testing no es ejecutar pasos. Es pensar en riesgos. Cuestionar requerimientos. Explorar zonas grises. El que ejecuta pasos es un operador. El que piensa es un tester.

Lo que funciona: cuando te hagan esa pregunta, arrancá por las preguntas que harías antes de probar. ¿Qué no está especificado? ¿Dónde puede romperse? ¿Qué supone el equipo que va a funcionar? Eso muestra mentalidad de tester desde el primer segundo.

No hacer preguntas al final

"¿Tenés alguna pregunta para nosotros?" — "No, creo que está todo claro."

Error.

Las preguntas que hacés al final dicen tanto de vos como tus respuestas anteriores. Muestran si investigaste la empresa, si te importa el rol, si pensás más allá del primer mes.

Tres que siempre funcionan:

• ¿Cómo está integrado el equipo de QA en el proceso de desarrollo?

• ¿Cuál es el mayor desafío de calidad que enfrenta el equipo hoy?

• ¿Cómo es el onboarding para alguien nuevo en el equipo?

No las tires todas juntas. Elegí la que más tenga sentido con lo que charlaron durante la entrevista.

Muchos piensan que si dicen que no tienen preguntas están dando a entender a los entrevistadores que explicaron muy bien todo. Pero no...están dando a entender que no sos los suficientemente inquisitivo.

Subestimar la parte soft

Muchos candidatos se preparan para las preguntas técnicas y se olvidan de que la primera mitad de casi toda entrevista es completamente soft: quién sos, cómo trabajás, cómo manejás conflictos.

En QA especialmente, la habilidad de comunicarte con devs, product owners y stakeholders es tan importante como saber testing. Un tester que no puede explicar un bug de forma clara, o que genera fricción cada vez que rechaza código, es un problema para el equipo.

Preparate igual de bien para las preguntas blandas. No son el relleno. Son parte del criterio de decisión.

No investigar la empresa antes de entrar

Esto se nota de inmediato. El candidato llega sin saber a qué se dedica la empresa, qué producto tiene, en qué industria opera.

Eso dice que no te importó lo suficiente como para dedicarle 20 minutos. Y si no te importó antes de entrar, ¿por qué les importaría a ellos?

Mínimo que tenés que saber: qué hace la empresa, cuál es su producto principal, a quién le vende, y si podés, cómo es el área de tecnología. Con eso podés conectar tus respuestas al contexto de ellos, y eso marca diferencia.

Entiendo que a veces estás con mil aplicaciones al mismo tiempo y es un quilombo tener a mano la información de todas. Yo lo que hago es armarme un excel o Notion con el nombre de la empresa, el link a la web, una frase con lo que hace o entendí que hacen y el nombre del contacto con el que estoy hablando. Cortita y al pie.

Lo que tienen en común todos estos errores

Fijate algo interesante: Ninguno es un error de talento. Son todos errores de preparación.

El candidato que llega con ejemplos concretos, que es honesto con lo que sabe y lo que no, que hace preguntas inteligentes y que investigó la empresa, ya eliminó la mayoría de las razones por las que los entrevistadores descartan candidatos.

No tenés que ser el más técnico de la sala. Tenés que ser el más preparado.

Si querés llegar listo a tu próxima entrevista

Eso es exactamente lo que trabajamos en QA Job Ready: el curso para testers que ya saben algo de testing pero no saben cómo mostrarlo, defenderlo y comunicarlo en una entrevista real.

No es un curso de teoría. Es un programa de seis bloques con criterios de avance claros: razonamiento de tester, diseño de casos, APIs, mentalidad de automation, entrevistas técnicas y cómo venderte aunque tengás poca experiencia.

Al final incluye feedback asincrónico personalizado y un roadmap con tu próximo paso concreto.