Iniciar sesión Registrarse Panel

Todas las fichas de puesto

España Informática y tecnologías de la información Intermedio

Data Analyst

Descripción de puesto, salario, sourcing, 15 preguntas de entrevista y plan 30/60/90 para contratar un·a Data Analyst en pymes españolas.

Compilado por el equipo de Join a partir de datos públicos y de nuestra experiencia en contratación.

Actualizado

De un vistazo

  • Salario mediano 40.000 € 32.000 € – 52.000 €
  • Plazo de contratación 40–70 días
  • Experiencia 2–5 años

Cómo contratar a un·a Data Analyst para su pyme

Antes de redactar la oferta, plantéese tres preguntas de encuadre. Determinan qué perfil busca realmente y evitan los errores frecuentes en pyme de data en España.

Pregunta 1: ¿Data Analyst, Data Engineer o Data Scientist? El·la Data Analyst responde a preguntas de negocio con datos existentes (SQL, BI, análisis exploratorio, comunicación a stakeholders). El·la Data Engineer construye los pipelines que entregan esos datos (ingesta, transformación, orquestación, monitoring). El·la Data Scientist trabaja con modelos predictivos (machine learning, estadística inferencial, diseño de experimentos). En pymes pequeñas (menos de 30 personas), el primer perfil que contratar es casi siempre Data Analyst: entrega valor inmediato sobre datos ya disponibles y no requiere meses de instrumentación previa. Las pymes que arrancan por Data Scientist sin Data Analyst ni Data Engineer suelen acumular modelos que nadie utiliza, mientras los dashboards básicos siguen mal definidos.

Pregunta 2: ¿Stack-Fit o seniority? Un·a persona analista con experiencia sólida en SQL, dbt y Looker no se vuelve productiva de inmediato en SAS, Tableau y SQL Server; necesita 3-6 semanas de adaptación. Para un perfil mid-level pesa más la fit de stack que la seniority absoluta. Sea explícito·a con su stack en la oferta; eso ya filtra perfiles mal encajados. Si su stack es legacy (Excel avanzado, Tableau aislado, SQL Server clásico) y planea modernizarla, asúmalo y busque perfiles a los que les guste construir la nueva capa en lugar de atraer perfiles decepcionados tras la incorporación.

Pregunta 3: ¿Qué porcentaje del tiempo dedicará a la comunicación con negocio? En pyme early-stage (menos de 5 personas en data), un·a Data Analyst pasa el 40-60 por ciento del tiempo hablando con PMs, marketing, finanzas y dirección: clarificando preguntas, presentando resultados, formando a stakeholders en lectura de datos. En pyme más consolidada con equipo de data estructurado, ese porcentaje baja al 20-30 por ciento porque parte de la traducción la absorbe la capa Head of Data o Analytics Engineer. El perfil ideal cambia: comunicación y pedagogía en el primer caso, profundidad técnica y rigor de modelado en el segundo. Encuadre esta dimensión desde la propia oferta.

Si las tres respuestas convergen hacia un·a Data Analyst a jornada completa (y no a un·a Data Engineer, Data Scientist o BI Developer puro), pase al modelo de oferta a continuación.

Modelo de descripción de puesto

Descargar .docx

Data Analyst: análisis de producto y negocio en pyme

[Nombre de empresa], pyme B2B del sector [sector] con sede en [ciudad], [X] personas en plantilla y [X] M€ de facturación, busca incorporar un·a Data Analyst al equipo de [data / producto / operaciones] de [X] personas.

Misión

Transformar preguntas de negocio en respuestas accionables sobre datos: SQL, modelado en dbt o equivalente, dashboards de producto y negocio, análisis ad hoc y presentación de resultados a stakeholders. La persona reporta a [Head of Data / Head of Product / CTO].

Responsabilidades

  • Entregar análisis ad hoc de principio a fin: clarificación de la pregunta de negocio, extracción de datos, exploración, recomendación accionable, presentación al·a stakeholder.
  • Construir y mantener dashboards de producto y negocio sobre la BI tool corporativa [Looker / Metabase / Tableau / otra], garantizando coherencia de métricas entre vistas.
  • Contribuir al layer semántico de datos: modelos dbt o equivalentes, documentación de métricas clave, tests automatizados de calidad de datos.
  • Detectar y comunicar inconsistencias o derivas en los datos antes de que afecten decisiones de negocio.
  • Formar de manera informal a perfiles no técnicos (PMs, marketing, dirección) en lectura de dashboards y formulación de preguntas de datos accionables.
  • Participar en la definición de la instrumentación de producto en colaboración con producto e ingeniería.
  • Documentar supuestos, decisiones de modelado y casos límite identificados en los análisis.

Perfil

  • Imprescindible: [2 a 5] años de experiencia profesional como Data Analyst, BI Analyst o equivalente; dominio sólido de SQL (joins múltiples, agregaciones, window functions); experiencia con al menos una BI tool moderna (Looker, Metabase, Tableau, Power BI, Mode); capacidad de comunicar resultados a perfiles no técnicos.
  • Valorable: familiaridad con dbt y un data warehouse moderno (Snowflake, BigQuery, Redshift); experiencia con Python para análisis (pandas, notebooks); fundamentos de instrumentación de producto (Segment, Mixpanel, Amplitude); contribuciones a comunidades o proyectos públicos.
  • Excluyente: ausencia de práctica SQL en autonomía; postura exclusivamente de reporting sin pregunta de negocio asociada; rechazo a participar en sesiones con stakeholders no técnicos.

Qué ofrecemos

  • Retribución bruta anual: fijo [32-52] mil euros según experiencia y especialización. Sin variable estructural; eventualmente phantom shares o stock options según la fase de la sociedad.
  • Modalidad: [jornada completa, híbrido 2-3 días por semana en oficina, base en [ciudad] / remote-friendly].
  • Beneficios: [seguro médico, ticket restaurante, cheque transporte, días adicionales de vacaciones, política de teletrabajo, presupuesto de material, presupuesto de formación y conferencias de data].
  • Stack de datos: [a completar: warehouse, BI tool, herramienta de transformación, instrumentación de producto, lenguajes de análisis].

Banda salarial

Salario fijo bruto anual

Percentil 25
32.000 €
Mediana
40.000 €
Percentil 75
52.000 €

Salario bruto anual de referencia para un·a Data Analyst de nivel intermedio (2 a 5 años de experiencia profesional) en pyme española. Madrid y Barcelona en entorno SaaS, fintech o scale-up tiran hacia arriba (45-60 k€); resto del territorio y sectores tradicionales tiran hacia abajo (28-36 k€). Stack moderno (dbt, Snowflake o BigQuery, Looker o Metabase, Python) tira hacia arriba; stack legacy (Excel avanzado, Tableau aislado, SQL Server clásico) tira hacia abajo. La especialización (analytics engineering, product analytics, marketing analytics) añade 3-6 k€ frente al perfil generalista. Los puestos de data en pyme española rara vez incluyen retribución variable estructural.

Fuentes: INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) ; InfoJobs, Estado del Mercado Laboral en España 2025 ; Spain Tech Salary Report 2025, Manfred

Dónde captar este perfil

  1. LinkedIn

    Recruiter Lite desde 170 € al mes; 200-400 € al mes adicionales para Job Slots

    Canal principal para perfiles de data en España, especialmente en Madrid y Barcelona. El sourcing activo (Recruiter Lite más InMails personalizados con referencia a un proyecto, una charla o un post de la persona candidata) supera ampliamente a la oferta pasiva: los buenos perfiles Data Analyst rara vez aplican en frío. Filtre por stack concreta (SQL más dbt más Python) y por dominio (product, marketing, finanzas) antes de contactar. Tasa de respuesta esperada: menos del 5 por ciento en secuencias genéricas, entre 15 y 25 por ciento en mensajes personalizados con contexto claro.

  2. InfoJobs

    Oferta destacada desde 199 € por publicación; packs multioferta desde 450 €

    Mayor volumen de candidaturas activas en España, especialmente fuera de Madrid y Barcelona (Valencia, Sevilla, Zaragoza, Bilbao) y en perfiles de data de pyme tradicional. Genera volumen, no siempre señal: filtre con un test técnico SQL breve (20-30 minutos) y un CV semiestructurado para no perder tiempo en el cribado. Más eficaz para perfiles generalistas (Excel avanzado, SQL clásico, Power BI) que para nichos modernos (analytics engineering, dbt). Útil como complemento de LinkedIn cuando se busca cubrir un puesto en plazo corto.

  3. Tecnoempleo y comunidades tech de nicho

    Tecnoempleo desde 295 € por oferta de 60 días; meetups y comunidades sin coste directo pero requieren presencia regular

    Audiencia tech española orientada a pyme y scale-up, con buena presencia fuera de los hubs principales. Complemente con comunidades especializadas: Slack de DataCraft España, meetups de Madrid Data Beers o Barcelona Data Engineers, canal de Telegram de Spain Data Community. Manfred (reverse recruiting español) funciona bien para perfiles senior que ya no usan LinkedIn activamente. Estos canales aportan menos volumen pero mejor cualificación; reserve el sourcing activo para perfiles con stack moderna o experiencia de analytics engineering.

Comparar todos los portales en este mercado →

Manual de evaluación

El puesto de Data Analyst se evalúa en cinco etapas. El ejercicio de SQL en vivo (etapa 3) es la prueba más predictiva: revela en 45 minutos la fluidez real con datos que dos horas de preguntas conceptuales no captarán. Acote el tiempo y prefiera consultas que se parezcan al día a día (joins, agregaciones, window functions, depuración de duplicados).

  1. Etapa 1: Lectura del CV

    Busque coherencia de stack (un·a perfil SQL más Python más dbt no se reinventa de la noche a la mañana en SAS legacy), naturaleza de los proyectos previos (product analytics frente a reporting financiero frente a marketing mix modelling) y señales de autonomía (proyectos públicos en GitHub, charlas en meetups, posts técnicos en Medium o blog propio). Una titulación específica (estadística, matemáticas, economía) tranquiliza en perfiles entry-level pero pierde peso a partir de 3 años de experiencia operativa real. Las certificaciones aisladas (Google Data Analyst, IBM) sin proyectos concretos detrás aportan poca señal.

  2. Etapa 2: Phone screen (30 min)

    Solo tres preguntas: (1) Describa el análisis o dashboard del que se sienta más orgulloso·a; ¿qué decisión de negocio cambió como consecuencia?, (2) ¿Qué métrica que haya construido le sigue generando dudas? (humildad y reflexión sobre el oficio), (3) ¿Por qué un cambio ahora? Salida: go o no-go en 5 minutos de debrief. Evite las preguntas técnicas tipo trampa en esta fase; busque la conexión entre datos y negocio en bruto.

  3. Etapa 3: Ejercicio de SQL en vivo (45-60 min)

    Pair coding sobre una base de datos real anonimizada (esquema de 4-6 tablas tipo e-commerce o SaaS): 3-4 preguntas crecientes que van de un select con filtros hasta una window function con CTE y depuración de duplicados. Evalúe la capacidad de razonar en voz alta, de pedir aclaraciones sobre el esquema, de detectar inconsistencias en los datos y de iterar. Acepte soluciones imperfectas si el razonamiento es sólido. Las personas que se bloquean en un join con 3 tablas o que no saben distinguir un INNER de un LEFT JOIN no operarán en autonomía.

  4. Etapa 4: Caso de análisis (presentación de 30 min más Q&A de 30 min)

    Caso real anonimizado: aquí tiene una caída del 12 por ciento en la activación de la semana pasada; investigue y proponga un plan de acción. La persona candidata recibe el dataset y el contexto 48 horas antes, prepara un análisis corto (3-5 láminas o un notebook) y presenta en 30 minutos seguidos de 30 minutos de preguntas. Pondere mucho esta etapa: revela la capacidad de encuadrar un problema, segmentar hipótesis, comunicar resultados a una audiencia mixta (técnica y de negocio) y reconocer zonas de incertidumbre. Quienes solo presentan métricas descriptivas sin hipótesis ni recomendación se quedan en la capa reporting.

  5. Etapa 5: Referencias (verificación estructurada)

    Llame a dos referencias: una persona ex-responsable directo·a (head of data, CTO o CPO) y un·a antiguo·a stakeholder de negocio (PM, marketing, finanzas) que haya consumido sus análisis. Plantee a ambas las mismas cuatro preguntas: ¿En qué destaca más?, ¿Para qué contrataría a una persona complementaria?, ¿Volvería a contratarle mañana y por qué?, ¿Un ejemplo concreto en el que su análisis cambió una decisión de negocio? La cuarta pregunta es la que revela el impacto real frente al trabajo invisible.

Preguntas de entrevista estructuradas

  1. Conductual Impacto de negocio

    Describa el análisis del que se sienta más orgulloso·a. ¿Qué decisión de negocio cambió como consecuencia y cómo se midió el impacto?

    Lo que revela una buena respuesta

    Conexión clara entre análisis y decisión: pregunta de negocio explícita, método de análisis adecuado, comunicación a stakeholders, decisión efectivamente tomada y resultado medido a posteriori. Bonus: la persona candidata cita el plazo entre la entrega del análisis y la decisión, y reconoce si la decisión final difirió de su recomendación. Quienes describen un dashboard bonito sin decisión asociada revelan postura de reporting más que de analítica.

  2. Conductual Rigor y verificación

    Cuénteme un análisis que entregó y del que más tarde descubrió un error. ¿Cuál era, cómo lo detectó y qué hizo a continuación?

    Lo que revela una buena respuesta

    Humildad técnica y rigor de verificación. Bonus: la persona candidata describe el proceso de comunicación del error a stakeholders (rápido, transparente, con corrección documentada) y la mejora de proceso que instaló después (revisión cruzada, tests de datos, documentación de supuestos). Quienes afirman no haber cometido nunca un error de análisis mienten o no han trabajado el tiempo suficiente con datos reales.

  3. Conductual Independencia analítica

    Describa una situación en la que un·a stakeholder le pidió un análisis con una conclusión ya esperada. ¿Cómo reaccionó?

    Lo que revela una buena respuesta

    Independencia analítica: capacidad de mantener el rigor frente a la presión, comunicar resultados que contradigan la hipótesis inicial, proponer alternativas en lugar de fabricar el resultado esperado. Quienes describen haber buscado el ángulo que confirmara la hipótesis muestran una debilidad crítica de integridad analítica que envenena la confianza en datos a medio plazo.

Cómo reconocer a un·a excelente Sales Manager

Competencia Por debajo En el nivel Por encima
Fundamentos SQL y modelado Se bloquea en un join con 3 tablas o con un GROUP BY con HAVING. No distingue INNER de LEFT JOIN. Desconoce las window functions. Modela datos por copia y pega sin pensar en la estructura. Domina SQL operativo: joins múltiples, agregaciones, subconsultas, window functions básicas (ROW_NUMBER, LAG, LEAD). Sabe leer un esquema relacional y diseñar una consulta legible y mantenible. Comprende los principios de modelado (star schema, normalización frente a denormalización). Referente SQL del equipo: window functions avanzadas, optimización de consultas costosas (EXPLAIN, índices, particionado), patrones de modelado en dbt o equivalente. Forma a perfiles junior y revisa PRs SQL con feedback técnico claro.
Impacto de negocio Entrega dashboards o informes sin pregunta de negocio explícita asociada. No mide el efecto de sus análisis en decisiones tomadas. Habla de actividad (entregables) en lugar de impacto (decisiones cambiadas). Cada análisis arranca con una pregunta de negocio clara. Sabe traducir una intención difusa de stakeholder en una pregunta analítica precisa. Comunica resultados orientados a decisión, no a metodología. Operador·a estratégico·a: anticipa preguntas que el negocio no ha formulado todavía, propone análisis proactivamente sobre palancas de impacto, mide el efecto de sus recomendaciones a posteriori. Referente para PMs y dirección sobre cómo plantear preguntas de datos accionables.
Rigor y verificación Sin estrategia clara de verificación: confía en la primera consulta que devuelve un número plausible. No documenta supuestos. Sin tests de calidad de datos. Errores frecuentes detectados aguas abajo por stakeholders. Verifica sistemáticamente cifras clave antes de entregar: control de orden de magnitud, comparación cruzada con otra fuente, sanity checks sobre valores extremos. Documenta supuestos. Conoce los principios de tests de datos (dbt tests, Great Expectations). Disciplina de pipeline: tests automatizados sobre fuentes y modelos, monitoring de freshness y volumen, documentación versionada de modelos y métricas. Detecta errores aguas arriba antes que los stakeholders. Construye el andamiaje de calidad que el equipo hereda.
Comunicación con negocio Presenta análisis en formato técnico (gráficos densos, métricas brutas, jerga) sin adaptar al público. Empieza por la metodología y pierde a la audiencia ejecutiva. No anticipa las preguntas más probables. Adapta el formato al público: titular y recomendación claros para dirección, detalle técnico disponible bajo demanda. Anticipa las 2-3 preguntas más probables. Estructura en pirámide invertida (conclusión primero). Comunicador·a de datos referente: visualizaciones limpias y accionables, narrativa que conecta dato y decisión, dominio de los formatos (one-pager, dashboard, presentación oral, memo escrito). Stakeholders de negocio le piden análisis antes incluso de formular la pregunta porque saben que recibirán una respuesta útil.
Autonomía e iniciativa Se bloquea en cuanto la pregunta es ambigua. Espera instrucciones precisas. No propone análisis ni señala oportunidades de mejora del stack o de los procesos. Trabaja en autonomía sobre temas familiares. Pide aclaraciones cuando la pregunta es ambigua pero propone alternativas. Señala oportunidades de mejora (dashboard a refactorizar, métrica a redefinir, pipeline a estabilizar). Iniciativa estructurante: propone proyectos transversales (migración a dbt, definición de un layer semántico, plan de gobernanza de datos), pilota su ejecución y los argumenta ante la dirección. Construye y mantiene la cultura de datos en autonomía.

Plan de 30/60/90 días

Día 30

  • Setup completo del entorno (acceso a base de datos, dbt o equivalente, BI tool, repositorios) y entrega de una primera consulta SQL productivizada
  • Lectura y comprensión de los 3 dashboards y 3 modelos de datos más críticos del negocio
  • Primer 1:1 documentado con la persona responsable sobre métricas clave, deuda identificada y prioridades del trimestre
  • Primera entrevista con 3-5 stakeholders de negocio (producto, marketing, finanzas) para mapear sus preguntas de datos recurrentes

Día 60

  • Entrega autónoma de un análisis ad hoc completo (pregunta de negocio, datos, resultados, recomendación, presentación a stakeholder)
  • Primera revisión de un dashboard o modelo de datos existente con feedback estructurado y propuesta de refactor
  • Documentación redactada o actualizada sobre una métrica clave o un modelo de datos tocado recientemente
  • Primera propuesta de mejora de proceso (test de calidad de datos, alerta de freshness, alineación de definición de métrica)

Día 90

  • Cadencia regular de entrega (1-2 análisis sustantivos por semana, cierre de tickets ad hoc en menos de 48 horas)
  • Primera contribución estructurante al stack de datos (refactor de modelo dbt, nueva métrica documentada, pipeline estabilizado)
  • Pedagogía instalada: al menos una sesión de formación informal a un equipo no técnico (PMs, marketing, dirección) sobre lectura de dashboards o formulación de preguntas de datos
  • Balance formal con la persona responsable: rampa validada, plan de progresión sobre 1-2 ejes prioritarios (analytics engineering, product analytics, comunicación ejecutiva)

Errores comunes al contratar para este puesto

  1. Contratar por dominio de herramienta en lugar de por razonamiento sobre datos

    Una persona candidata que enumera 8 herramientas en su CV (Tableau, Power BI, Looker, Mode, Metabase, dbt, Airflow, Snowflake) no necesariamente razona mejor sobre datos que otra con dominio profundo de SQL más una BI tool. La fluidez analítica vive en la capacidad de encuadrar una pregunta de negocio, segmentar hipótesis y diagnosticar inconsistencias; las herramientas se aprenden en 2-4 semanas. Pondere el ejercicio de SQL en vivo y el caso de análisis por encima de la lista de herramientas del CV.

  2. Confundir Data Analyst, Data Engineer y Data Scientist

    El·la Data Analyst responde a preguntas de negocio con datos existentes: SQL, BI, análisis exploratorio, comunicación a stakeholders. El·la Data Engineer construye y mantiene los pipelines que entregan esos datos: ingesta, transformación, orquestación. El·la Data Scientist trabaja con modelos predictivos: machine learning, estadística inferencial, experimentación. Muchas pymes mezclan los tres roles en una sola oferta (buscamos perfil que haga SQL más dbt más Airflow más modelos predictivos), lo que produce frustración por parte de la persona candidata o fracaso por parte de la empresa. Encuadre el scope de forma explícita en la oferta; si necesita varios perfiles, contrate de forma secuencial empezando por Data Analyst.

  3. Subestimar la importancia de la comunicación con negocio

    Un·a Data Analyst en pyme habla casi a diario con PMs, marketing, finanzas y a veces directamente con dirección. Contratar un perfil técnicamente sólido pero flojo en comunicación produce dashboards densos que nadie usa, análisis brillantes que no cambian decisiones y frustración por parte de los stakeholders. Evalúe la comunicación explícitamente en la entrevista (presentación del caso de análisis a una audiencia mixta, prueba de simplificación de un concepto técnico) y no solo el SQL.

  4. Pedir pruebas técnicas de 8 horas o más para perfiles entry o mid

    Una prueba take-home de 8 horas se transforma en la práctica en 16-24 horas (con inversión emocional incluida), desmotiva a los mejores perfiles (que tienen otras opciones en paralelo) y no aporta mejor señal que un ejercicio de SQL en vivo de 45 minutos más un caso de análisis acotado a 4 horas de preparación. Mida la calidad del razonamiento, no la exhaustividad. Acote el tiempo esperado de forma explícita y acepte soluciones incompletas pero bien argumentadas.

  5. Ignorar el match entre stack y perfil

    Un·a Data Analyst sólido·a en SQL más Looker más Snowflake no se vuelve productivo·a de inmediato en SAS más Tableau más SQL Server; necesita 3-6 semanas de adaptación. Un perfil con stack cercana a la suya estará operativo·a en 1-2 semanas. Para un perfil mid-level pesa más la fit de stack que la seniority absoluta. Sea explícito·a con su stack en la oferta; eso ya filtra perfiles mal encajados y reduce el ratio de incorporaciones que fracasan a los 6 meses.

Preguntas frecuentes

  • ¿Cuál es el salario de un·a Data Analyst en una pyme española?

    La horquilla de referencia para un·a Data Analyst de nivel intermedio (2 a 5 años de experiencia) en pyme española se sitúa entre 32 y 52 mil euros brutos anuales (mediana en torno a 40 mil). Madrid y Barcelona en entorno SaaS, fintech o scale-up tiran hacia arriba (45-60 mil); resto del territorio y sectores tradicionales tiran hacia abajo. La especialización (analytics engineering, product analytics, marketing analytics) añade 3-6 mil euros frente al perfil generalista. Este puesto no suele tener variable estructural en pyme; algunas scale-ups ofrecen phantom shares o stock options como complemento.

  • ¿Cuál es la diferencia entre Data Analyst, Data Engineer y Data Scientist?

    El·la Data Analyst responde a preguntas de negocio con datos existentes: SQL, BI, análisis exploratorio, comunicación a stakeholders. El·la Data Engineer construye y mantiene los pipelines que entregan esos datos: ingesta, transformación, orquestación, monitoring. El·la Data Scientist trabaja con modelos predictivos: machine learning, estadística inferencial, diseño de experimentos. En pymes pequeñas (menos de 30 personas), el primer perfil que contratar es casi siempre Data Analyst, porque entrega valor inmediato sobre datos ya disponibles. Las pymes que arrancan por Data Scientist sin Data Analyst ni Data Engineer suelen acumular modelos que nadie utiliza.

  • ¿Cuánto tiempo lleva contratar a un·a Data Analyst en España?

    Cuente con 40 a 70 días entre la publicación de la oferta y la firma para un perfil mid-level. El mercado español de data sigue tenso en 2025-2026, sobre todo para perfiles con stack moderna (dbt, Snowflake o BigQuery, Looker). Los plazos se alargan en agosto y en torno a las navidades. Reducir el plazo por debajo de los 40 días suele implicar sacrificar el ejercicio de SQL en vivo o el caso de análisis, lo que degrada considerablemente la calidad de la contratación. Si el plazo se acerca a los 70 días sin candidaturas finalistas, revise el sourcing antes de bajar el rigor.

  • ¿Es necesaria una titulación específica para contratar a un·a Data Analyst?

    No. El mercado de data en España acepta ampliamente perfiles procedentes de carreras cuantitativas (estadística, matemáticas, economía, ingeniería) y también perfiles autodidactas o procedentes de bootcamps (Le Wagon Madrid, Ironhack, 4Geeks Academy) cuando suman 2-3 años de producción sólida. La titulación tranquiliza en perfiles entry-level pero pierde peso a partir de los 3 años de experiencia operativa. Evalúe sobre el ejercicio de SQL en vivo y el caso de análisis, no sobre el pedigrí académico.

  • ¿Qué obligaciones legales tiene una oferta de Data Analyst en España?

    Cuatro obligaciones principales: (1) denominación neutra de género o con mención inclusiva (Estatuto de los Trabajadores y Ley de Igualdad); (2) registro horario obligatorio de la jornada (art. 34.9 del Estatuto de los Trabajadores, vigente desde 2019); (3) banda salarial visible en la oferta o comunicada antes de la primera entrevista (Directiva UE 2023/970 sobre transparencia retributiva, transposición antes del 7 de junio de 2026); (4) transparencia sobre cualquier herramienta de IA usada para el cribado de candidaturas y supervisión humana garantizada (EU AI Act, aplicable desde el 2 de agosto de 2026). Se aplica además el convenio colectivo correspondiente al sector.

  • ¿Conviene contratar un·a Data Analyst full remote, híbrido o presencial?

    El full remote es viable si el equipo de data, producto e ingeniería es también remoto y los rituales (revisiones de dashboards, sesiones de discovery con stakeholders, pair coding SQL) se mantienen con disciplina. En pyme española el modelo híbrido de 2-3 días en oficina sigue siendo el estándar, sobre todo en equipos pequeños donde la cercanía física acelera las preguntas de negocio. El presencial completo se justifica principalmente cuando el producto requiere interacción frecuente con funciones de campo (ventas, customer success) o cuando los datos contienen información sensible regulada (banca, sanidad).

Cubra este puesto con Join Sourcing, filtrado y entrevistas en un solo lugar.
Empezar a contratar

Hablar con Join