¿Necesito carta de presentación para un puesto de analista de datos?

Dónde se lee realmente la carta

En muchas candidaturas para analista de datos, nadie lee la carta de presentación antes que el CV. Un reclutador o un ATS escanea SQL, Python, Tableau, Power BI, dbt, o cualquier tecnología que mencione el anuncio, y un humano solo abre la carta una vez que tu CV ha superado ese filtro. En ese momento la carta se lee rápido, a menudo por el responsable de contratación en lugar de RRHH, porque la contratación de analistas suele recaer en el líder del equipo que realmente trabajará contigo.

Esto cambia para qué sirve la carta. No es donde demuestras que sabes hacer SQL joins o escribir una window function. Tu CV, y cualquier portafolio o enlace a GitHub, hace eso. La carta es donde muestras que entendiste el problema específico que describía el anuncio y puedes decir, brevemente, por qué eres una respuesta plausible. Si el anuncio dice que el equipo necesita alguien que construya dashboards para marketing y arregle un proceso ETL que actualmente falla cada mes, un responsable de contratación quiere ver que notaste ambas cosas, no un párrafo sobre tu entusiasmo por la toma de decisiones basada en datos.

Donde la carta tiene peso real es cuando algo en tu trayectoria necesita explicación que el CV no puede dar por sí solo: un cambio desde finanzas o investigación académica hacia analítica, una pausa laboral, o un desajuste entre tu último título de puesto y la senioridad del rol al que aplicas. Donde casi no tiene peso es cuando eres un analista en activo aplicando lateralmente a un rol similar en una empresa similar con un CV sólido y un historial laboral limpio. En ese caso, una carta genérica pero competente no te costará mucho, y una brillante tampoco te comprará mucho — la prueba técnica y el ejercicio de SQL o caso práctico lo decidirán.

Las una o dos cosas que un responsable de contratación realmente quiere respondidas

Quita la convención de "di por qué quieres este trabajo" y realmente hay dos preguntas debajo, y ambas son sobre lo mismo: ¿puede esta persona convertir una pregunta de negocio en una respuesta de datos, y pueden convertir la respuesta de datos de vuelta en algo sobre lo que un stakeholder no técnico pueda actuar?

La primera usualmente se responde con un ejemplo concreto: una ocasión en que tomaste una solicitud ambigua — "por qué bajó la conversión el trimestre pasado" en lugar de una consulta especificada — y determinaste qué medir realmente, de qué tablas o flujos de eventos extraer, y cuáles eran los factores de confusión. Nombrar el mecanismo importa más que nombrar el resultado. "Trabajé con los datos de eventos sin procesar en BigQuery, verifiqué si hubo cambios en el tracking antes de confiar en la caída, luego segmenté por canal" le dice a un responsable de contratación cómo piensas. "Identifiqué insights clave que mejoraron el rendimiento" no le dice nada, porque sería igualmente cierto de cualquier trabajo con la palabra "analista" en él.

La segunda es la parte que los analistas a menudo omiten porque se siente menos técnica, pero usualmente es la brecha real que el equipo está intentando llenar. La mayoría de los anuncios de analista de datos, una vez lees más allá de la lista de herramientas, están describiendo un problema de comunicación: stakeholders que no confían en los números, dashboards que nadie mira, solicitudes que llegan sin ninguna pregunta clara adjunta. Si tienes una línea de evidencia de que has presentado hallazgos a personas que no eran analistas — un equipo de producto, un responsable de marketing, un director financiero — y cambiaste lo que hicieron después, ponlo en la carta. Eso frecuentemente vale más que otra frase sobre tu fluidez en SQL, porque la fluidez en SQL es para lo que sirve la prueba técnica.

Qué omitir

No reformules tu CV en prosa. Si tu CV ya lista "5 años de experiencia con SQL, Python, Tableau y Looker", repetir esa frase en la carta desperdicia los únicos dos párrafos que serán leídos atentamente. Usa la carta para añadir lo único que el CV no puede mostrar — criterio, contexto, o el razonamiento detrás de un proyecto — no para resumir lo que ya está ahí.

Evita nombrar herramientas que no has usado realmente solo porque el anuncio las lista. Si el trabajo quiere dbt y solo has usado scripts SQL sin procesar para transformaciones, dilo claramente en lugar de implicar lo contrario; un equipo de datos lo descubrirá en la primera conversación técnica, y un desajuste descubierto ahí te cuesta más credibilidad que admitirlo de entrada.

Omite la línea sobre ser "apasionado por los datos". Se dice con suficiente frecuencia que ha dejado de significar algo, y no te distingue de los demás candidatos que también lo escribieron. Si quieres señalar interés genuino, hazlo referenciando algo específico sobre los datos de la empresa — su producto, su cadencia de reportes, una declaración pública sobre cómo usan analítica — en lugar de una afirmación sobre tus sentimientos hacia las hojas de cálculo.

No te disculpes por brechas en el stack. Si el rol quiere modelado estadístico avanzado y tu experiencia es principalmente reportes descriptivos y dashboarding, no pases un párrafo explicando lo que te falta. O bien el CV y la carta juntos hacen un caso de que tus fortalezas superan esa brecha, o no, y ninguna cantidad de salvedades cambia eso.

Si tienes un portafolio, un GitHub, o un caso práctico que has hecho antes

Muchos procesos de contratación de analista de datos ahora incluyen una prueba de SQL, un caso de estudio, o un análisis breve para hacer en casa antes o en lugar de una primera entrevista. Si tienes trabajo público — un dashboard que construiste para un proyecto personal, un análisis en Kaggle, un repositorio de GitHub con consultas limpias y comentadas — un solo enlace en la carta vale más que un párrafo describiendo tus habilidades, porque le permite al responsable de contratación verificar tus afirmaciones directamente en lugar de creerte la palabra. Solo enlázalo si es genuinamente representativo de tu nivel; un repositorio desordenado o a medio terminar enlazado desde una carta de presentación hace más daño que ningún enlace.

Si el anuncio nombra una herramienta específica para reportes — Power BI, Looker, Tableau, Mode — y has construido algo en ella, dilo con un detalle específico: "construí un dashboard en Tableau usado por el equipo de ventas para rastrear el pipeline semanal" en lugar de "experiencia con Tableau". La especificidad es lo que lo hace verificable y creíble; afirmaciones vagas sobre experiencia con herramientas son lo más fácil de escribir en una carta de presentación y lo menos persuasivo de leer.

Qué hacer a continuación

Lee el anuncio dos veces antes de escribir nada. La primera vez para las herramientas y el nivel de senioridad; la segunda vez para el problema real escondido en la sección de responsabilidades — el dashboard en el que nadie confía, el proceso de reportes que toma tres días y debería tomar uno, el grupo de stakeholders que sigue pidiendo números diferentes. Escribe tu línea de apertura sobre ese problema, no sobre la declaración de misión de la empresa.

Luego escribe dos párrafos cortos: un ejemplo concreto de convertir una pregunta ambigua en una respuesta respaldada por datos, usando las herramientas reales de tu CV, y un ejemplo concreto de poner esa respuesta frente a alguien no técnico y hacer que cambiara una decisión. Cierra en dos líneas. Si no puedes llenar ninguno de los párrafos con algo específico y verdadero, esa es información más útil que una carta pulida que lo disimula — te dice qué parte de tu experiencia construir a continuación, o a qué roles dejar de aplicar hasta que la tengas.

Si lo que realmente está fallando es el volumen — enviar candidaturas más rápido de lo que puedes adaptar cada una a la solicitud real del anuncio — ese es un problema diferente de la carta en sí, y vale la pena nombrarlo honestamente en lugar de arreglarlo con una mejor plantilla. jobmarket.pro está construido para ese caso: lee cada anuncio completo, establece dónde encaja tu perfil y dónde no, y redacta la candidatura desde un perfil en el que no puede inventar experiencia.