Preguntas de entrevista para Business Analyst: respuestas que funcionan

Llegas a la entrevista para Business Analyst y la primera pregunta ya te deja en blanco. No es que no sepas, es que no sabes qué quieren escuchar. Te ha pasado o te pasará. Las entrevistas para este rol son un filtro que va de lo técnico a lo personal, y te van a medir en tres frentes: si sabes hacer el trabajo, si sabes trabajar con gente y si encajas en la empresa. Vamos a desglosar las preguntas reales que te van a hacer, cómo responderlas y qué errores te pueden costar la oferta.

El primer filtro: preguntas generales y de motivación#

Antes de entrar en lo técnico, el entrevistador necesita saber si eres real, si has investigado la empresa y si tienes claro a qué te dedicas. Son preguntas sencillas, pero donde muchos se desmoronan.

• "Cuéntame sobre ti.": No quieren tu biografía. Quieren un resumen de 90 segundos que conecte tu experiencia con el puesto. Estructura: qué haces ahora, qué hiciste antes que sea relevante y por qué estás aquí. Nada de "desde pequeño me apasiona la tecnología".
• "¿Por qué quieres trabajar aquí/nosotros?": Si dices "porque son una gran empresa", has fallado. Investiga un proyecto reciente, un producto, un reto del sector. Menciona algo específico: "Vi que están expandiendo su plataforma de pagos en Latinoamérica y me interesa cómo gestionan los requisitos regulatorios en cada país."
• "¿Qué sabes de nosotros?": Mismo caso. Revisa su web, LinkedIn, noticias recientes. Si puedes mencionar algo que no sea de la página de "Sobre nosotros", sumas puntos.

Preguntas técnicas y de dominio: demuestra que sabes hacer el trabajo#

Aquí es donde separan a los que tienen el puesto de los que solo tienen el título. Van a poner a prueba tu proceso, tus herramientas y tu forma de pensar.

• "¿Cómo empezarías a analizar un nuevo proyecto o funcionalidad?": Quieren escuchar un proceso. No te lances a la solución. Empieza por preguntar: ¿cuál es el problema de negocio? ¿Quién es el usuario? ¿Qué éxito significa? Luego habla de identificar stakeholders, recopilar requisitos (entrevistas, workshops, análisis de datos), documentar y priorizar.
• "¿Cómo manejas a un stakeholder que cambia constantemente de requisitos?": Esta pregunta busca tu habilidad de comunicación y gestión de expectativas. Una buena respuesta implica entender el "por qué" del cambio, documentar el impacto (tiempo, coste, alcance), y usar un marco de priorización. Menciona herramientas como MoSCoW o RICE.
• "¿Cuál es la diferencia entre requisitos funcionales y no funcionales?": Parece básica, pero la respuesta debe ser clara y con ejemplo. Funcional: lo que el sistema hace (ej: "el usuario puede filtrar productos por precio"). No funcional: cómo lo hace (ej: "la página de resultados carga en menos de 2 segundos con 10.000 usuarios concurrentes").
• "¿Qué herramientas usas para documentar y gestionar requisitos?": Sé específico. Menciona Jira, Confluence, Azure DevOps, Miro, SQL para consultas básicas, y alguna herramienta de diagramas como Draw.io o Lucidchart. Si conoces alguna herramienta de análisis de datos como Tableau o Power BI, menciónala.

Respuesta modelo: cómo analizar un nuevo proyecto

"Lo primero que hago es entender el objetivo de negocio. Organizo una reunión con el sponsor o product manager para que me explique qué problema quiere resolver y qué métrica de éxito usaremos. Después, mapeo a los stakeholders clave y preparo entrevistas individuales. En esas reuniones, busco entender sus procesos actuales, sus puntos de dolor y qué esperan de la solución. Con esa información, documento los requisitos en Confluence, los priorizo con el equipo usando MoSCoW y creo las user stories en Jira con criterios de aceptación claros. Antes de avanzar, hago una revisión con todos para confirmar que estamos alineados."

Preguntas de comportamiento: cómo trabajas con la gente#

La mitad del trabajo de un BA es tratar con personas. Si no sabes comunicar, negociar o manejar conflictos, tus diagramas no sirven de nada.

• "Cuéntame un conflicto que tuviste con un desarrollador o un stakeholder y cómo lo resolviste.": Usan el método STAR (Situación, Tarea, Acción, Resultado). No culpes a nadie. Enfócate en cómo escuchaste, buscaste un punto medio y llegaste a una solución.
• "¿Cómo te aseguras de que todos los stakeholders entienden los requisitos?": Habla de técnicas de validación: workshops de revisión, prototipos, historias de usuario con ejemplos concretos, y la importancia de usar un lenguaje claro sin jerga técnica innecesaria.
• "¿Cómo priorizas cuando todo parece urgente?": Menciona un marco (RICE, valor vs. esfuerzo, MoSCoW) y, más importante, cómo lo comunicas. "Planteo la conversación con datos: si hacemos X primero, ganamos Y. Si cambiamos a Z, el impacto es W y retrasamos X en dos semanas. ¿Qué preferimos?"
• "Describe una situación donde los requisitos no estaban claros y cómo avanzaste.": Aquí buscan tu proactividad. ¿Hiciste preguntas? ¿Investigaste? ¿Propusiste un prototipo o un taller para desbloquear la situación?

Respuesta modelo: manejando un conflicto

"En mi puesto anterior, un stakeholder insistía en añadir una funcionalidad compleja a mitad del sprint. El equipo técnico veía el alcance comprometido. Mi tarea fue encontrar una solución que no descartara su idea ni retrasara todo. Organicé una reunión de 30 minutos con el stakeholder y el lead técnico. Le pedí al stakeholder que explicara el problema de negocio detrás de su petición, y al técnico que detallara el impacto real en tiempo y riesgos. Al final, acordamos implementar una versión simplificada en el sprint actual y planificar la versión completa para el siguiente ciclo. El stakeholder se sintió escuchado y el equipo mantuvo el compromiso."

Qué evalúa el entrevistador (y errores que te costarán la oferta)#

Más allá de la respuesta correcta, buscan patrones.

• Claridad de pensamiento: ¿Estructuras tu respuesta o divagas?
• Comunicación: ¿Explicas conceptos complejos de forma simple?
• Orientación a soluciones: ¿Te quejas del problema o propones caminos?
• Conocimiento técnico: ¿Usas las herramientas y metodologías del rol?
• Colaboración: ¿Hablas en "yo" todo el rato o mencionas al equipo?

Los errores más comunes: dar respuestas genéricas que aplicarían a cualquier puesto, no tener preguntas para el entrevistador (siempre ten al menos tres preparadas), hablar mal de empleos o compañeros anteriores, y no poder dar un ejemplo concreto de algo que afirmas saber hacer.

Checklist de preparación#

• Investiga la empresa: su producto, su mercado, sus últimos anuncios, su stack tecnológico si lo publican.
• Revisa la descripción del puesto y subraya las 5 habilidades clave que piden.
• Prepara 5 o 6 historias usando el método STAR para preguntas de comportamiento.
• Practica tus respuestas en voz alta. Suena ridículo, pero marca la diferencia.
• Prepara tres preguntas para el entrevistador sobre el equipo, los proyectos o la cultura.
• Ten a mano tu portafolio o ejemplos de trabajo (sin información confidencial) para mostrar si surge la oportunidad.

Puedes usar nuestro analizador de ofertas gratuito para desglosar la descripción del puesto y ver qué habilidades destacar. Y si quieres repasar más consejos sobre el proceso, nuestro blog tiene artículos específicos para analistas.

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ánto gana un Business Analyst en España?

Los rangos varían bastante según la ciudad, la empresa y la experiencia. En general, un Business Analyst con 2-4 años de experiencia puede esperar entre 30.000 y 45.000 euros brutos anuales en España. En empresas tecnológicas multinacionales o roles senior, la cifra puede superar los 55.000. Consulta fuentes actualizadas como Glassdoor o el informe de Robert Half para datos más precisos.

¿Necesito saber programar para ser Business Analyst?

No necesitas ser desarrollador, pero saber SQL para hacer consultas básicas a bases de datos es casi un requisito hoy. Entender conceptos de APIs, JSON o cómo funciona un sprint de desarrollo te da una ventaja enorme para comunicarte con el equipo técnico. Lo que sí es imprescindible es saber usar herramientas como Jira, Confluence y alguna de visualización de datos.

¿Qué diferencia hay entre un Business Analyst y un Product Owner?

El BA se centra en analizar, documentar y validar los requisitos de negocio. El PO es el dueño del producto, prioriza el backlog y toma decisiones de negocio. En la práctica, en empresas pequeñas a veces el mismo rol cubre ambas funciones. En organizaciones grandes, el BA apoya al PO con el análisis detallado y la documentación.

¿Cómo respondo si no sé la respuesta a una pregunta técnica?

No inventes. Di algo como: "No tengo experiencia directa con esa herramienta específica, pero conozco su propósito y he trabajado con [herramienta similar]. Estoy seguro de que podría aprenderla rápido." Luego, si puedes, redirige a algo que sí domines. La honestidad siempre gana puntos frente a una respuesta inventada.

¿Qué tipo de preguntas debo hacer al final de la entrevista?

Pregunta sobre el equipo: con quién trabajarías, cómo es un día típico, qué retos tienen ahora mismo. Pregunta sobre el proceso: cómo gestionan los requisitos, qué metodología usan, cómo miden el éxito de un BA. Evita preguntas sobre vacaciones o beneficios en la primera entrevista. Una buena pregunta final es: "¿Cuál es el mayor reto que tiene el equipo hoy y cómo contribuiría este puesto a resolverlo?"