Questions to Ask in a QA Engineer Interview

Terminas la entrevista y la reclutadora te pregunta: "¿Tienes alguna duda para nosotros?". Dices que no, o sueltas dos preguntas genéricas, y esa decisión comunica más de lo que crees. Un QA con experiencia sabe que el momento de preguntar es su mejor herramienta de evaluación. Ahí descubre si el puesto es viable o si va a pasar los próximos doce meses apagando incendios ajenos.

Preparar preguntas con criterio cambia la conversación. Dejas de ser alguien que espera que le den trabajo y pasas a ser alguien que decide dónde invertir su tiempo. Eso se nota, y se nota rápido.

Por qué las preguntas marcan la diferencia#

En QA, tu trabajo es encontrar lo que nadie más miró. Cuando preguntas con precisión sobre procesos, cobertura y riesgos, estás haciendo exactamente lo que harías el primer día en el puesto. El entrevistador técnico lo entiende sin que se lo expliques.

También proteges tu propio tiempo. Hay equipos donde el testing se hace al final, sin entornos estables y con fechas que nadie preguntó. Descubrirlo en la entrevista es gratis. Descubrirlo a los tres meses cuesta caro.

Preguntas sobre la realidad del equipo#

Estas preguntas te dicen cómo se trabaja de verdad, no cómo dice el manual que se trabaja.

1. ¿Cómo es un ciclo de release normal para ustedes, desde que se cierra el código hasta producción?

La respuesta te muestra si hay pipeline, si hay despliegues manuales y cuánto tarda el proceso. Si dudan al describirlo, es que no está definido.

2. ¿Quién define qué se prueba en cada historia y cuándo se prueba?

Aquí ves si QA participa desde el diseño o llega al final. Un equipo maduro incorpora al tester antes de escribir código.

3. ¿Cuántos QA hay y cuántos desarrolladores? ¿Cómo se reparten los módulos?

La proporción varía mucho entre equipos, pero la forma en que responden es reveladora. Si esquivan la cifra, suele ser porque la proporción es mala.

4. ¿Qué pasó la última vez que se detectó un bug grave en producción?

Esta es mi favorita. No preguntas por procesos teóricos, preguntas por un caso real. Escucha si buscan causas o culpables.

Preguntas sobre prioridades y criterios de éxito#

Te dicen qué valoran de verdad y cómo saben si lo estás haciendo bien.

5. ¿Cómo decidimos qué casos automatizar y qué dejamos manual?

La respuesta honesta suele incluir criterios como frecuencia de uso, estabilidad de la interfaz y coste de mantenimiento. Si dicen "automatizamos todo", hay trabajo pendiente.

6. ¿Qué métricas de calidad miran y quién las revisa?

Algunos equipos miran cobertura, otros miran escapes a producción o tiempo de ciclo. Lo importante es que miren algo y que se hable de ello en retrospectivas.

7. Si entro mañana, ¿qué tendría que haber conseguido a los tres meses para que digáis que ha ido bien?

Con esta pregunta les obligas a definir expectativas concretas. También te da un plan de ataque para tus primeras semanas.

8. ¿Cómo se decide lanzar con un bug conocido?

Aquí ves quién tiene la última palabra y cómo se maneja el riesgo. Un buen equipo tiene criterios escritos, aunque sean breves.

Preguntas sobre riesgos y fricción#

Estas preguntas incomodan un poco. Bien. Un equipo serio las agradece.

9. ¿Cuál es el mayor riesgo de calidad que tenéis ahora mismo y no habéis podido resolver?

Piden transparencia, y la respuesta te dice si conocen sus propios problemas. Nadie espera que tengas la solución en la entrevista.

10. ¿Cómo son las relaciones entre QA y desarrollo cuando hay discusión sobre un bug?

Los conflictos existen en todos lados. Lo que importa es si se resuelven con datos o con quién grita más.

11. ¿Qué parte del proceso de testing os gustaría cambiar este año?

Si no se les ocurre nada, o todo está perfecto, algo no encaja. Los equipos buenos siempre tienen una lista.

12. ¿Cómo se gestionan los entornos de prueba y los datos de testing?

Este es un dolor real en muchas empresas. Si comparten entorno con otros equipos o los datos se montan a mano cada vez, vas a perder tiempo ahí.

Cómo leer las respuestas#

No buscas respuestas perfectas. Buscas coherencia y honestidad. Un equipo que dice "esto está mal y queremos arreglarlo" es más atractivo que uno que presume de un proceso que no se sostiene.

Fíjate en tres señales. Primera: si describen procesos con ejemplos concretos, tienen experiencia real. Segunda: si mencionan retrospectivas o cambios recientes, aprenden de sus errores. Tercera: si te devuelven la pregunta, quieren saber cómo piensas, y eso suele ser buena señal.

Desconfía de las respuestas vagas. "Hacemos testing automatizado" sin saber cuánto, dónde ni con qué herramientas es casi lo mismo que no decir nada.

Qué preguntas evitar#

Algunas preguntas restan en lugar de sumar, sobre todo si las haces antes de tiempo.

• Evita preguntar por el salario en la primera entrevista técnica. Eso se trata con reclutamiento, y ya tendrás momento.
• No preguntes cosas que están en la web de la empresa o en la oferta. Dice que no investigaste.
• No pidas que te expliquen qué hace la empresa. Pregunta por cómo trabajan, no por qué existen.
• Evita el "¿cuántas vacaciones hay?" antes de tener oferta. Es legítimo, pero mal colocado resta.
• No lances preguntas de manual que podrías copiar y pegar a otra empresa sin cambiar una palabra.

Un buen test: si puedes usar la misma pregunta en cinco entrevistas distintas sin ajustar nada, casi seguro es una mala pregunta.

Cómo preparar tus preguntas#

Llega con más preguntas de las que vas a hacer. Elige según lo que ya sepas y lo que haya salido en la charla.

• Prepara ocho o nueve preguntas y elige tres o cuatro según el flujo de la conversación.
• Investiga la empresa antes: stack, sector, tamaño del equipo. Cuanto más sepas, mejor será tu pregunta.
• Apunta respuestas durante la entrevista. Te sirve para comparar empresas después.
• Revisa la oferta con un decodificador de ofertas de empleo para entender qué priorizan y ajustar tus preguntas.
• Filtra las ofertas por stack y seniority en el buscador de empleo antes de preparar entrevistas serias.
• Revisa tu CV con el verificador de ATS gratuito para que la primera parte del proceso no te frene.
• Escribe tus preguntas en un documento que puedas consultar en cada proceso. Verás patrones con el tiempo.

Un ejemplo concreto#

Imagina que la oferta menciona Selenium y Cypress. Puedes hacer la pregunta genérica de manual: "¿Qué herramientas de automatización usáis?". O puedes hacer esta:

"Veo que trabajáis con Selenium y Cypress. ¿Cómo decidís en qué casos usáis una u otra, y cómo mantenéis los tests cuando cambia la interfaz?"

La segunda pregunta demuestra que leíste la oferta, que entiendes el coste de mantener un framework y que piensas a largo plazo. Es la diferencia entre un candidato cualquiera y alguien que ya ha vivido el mantenimiento de una suite de tests.

Cómo cerrar la entrevista#

Termina con una pregunta que abra la puerta a lo que no se dijo: "¿Hay algo sobre este puesto que os haya hecho dudar de mi perfil?". Es incómoda, sí. También te da la oportunidad de corregir un malentendido en el momento, algo que no podrás hacer después por email.

Y pregunta siempre por los siguientes pasos y los plazos reales. No por cortesía. Porque necesitas saber si el proceso dura dos semanas o tres meses para seguir buscando en paralelo.

Si quieres seguir preparándote, en nuestro blog tienes más guías sobre entrevistas técnicas y procesos de selección en tecnología.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántas preguntas debo hacer en una entrevista de QA?

Tres o cuatro preguntas bien elegidas es lo normal. Si la entrevista técnica fue larga y rica, dos pueden bastar. Lo que cuenta es la calidad y que se noten preparadas, no el número.

¿Puedo preguntar por el salario en la primera entrevista?

Mejor no en la entrevista técnica. Esa conversación va con reclutamiento y suele abrirse en la segunda fase. Si te preguntan tus expectativas, da un rango razonable y di que lo ajustas según el paquete completo.

¿Qué hago si no entiendo la respuesta técnica?

Pide que te lo expliquen con un ejemplo. No pasa nada y se agradece la curiosidad. Lo que sí resta es fingir que entendiste cuando no es así.

¿Sirven las mismas preguntas para un puesto de QA manual y de automatización?

El núcleo sí, pero cambia el énfasis. En automatización insiste en mantenimiento de frameworks, cobertura y CI. En manual, en exploratory testing, gestión de entornos y criterios de aceptación.

¿Cómo sé si las respuestas son buenas o malas?

Busca ejemplos concretos, procesos que se revisen y cierta autocrítica. Desconfía de los "todo funciona perfecto" y de las respuestas que podrías copiar de un manual. La coherencia entre lo que dicen el técnico, el manager y la reclutadora es la mejor señal.