¿Necesitas carta de presentación para un puesto de data engineer?

Dónde se lee realmente

La mayoría de contrataciones de data engineering siguen uno de dos caminos, y la carta de presentación importa de forma distinta en cada uno.

En empresas pequeñas y scale-ups, quien lee tu solicitud suele ser el responsable de data engineering o un ingeniero senior del equipo, no un reclutador. Tienden a revisar primero el CV, luego GitHub o un enlace a portfolio, y después la carta si hay tiempo. Si tu CV ya muestra el stack que necesitan —digamos, dbt, Airflow, Snowflake— es poco probable que la carta cambie la decisión en cualquier sentido.

En empresas más grandes que gestionan el proceso mediante un ATS (Workday, Greenhouse, Lever, SmartRecruiters), un reclutador suele cribar primero el CV contra las palabras clave de la oferta: el almacén específico (Snowflake, BigQuery, Redshift), la herramienta de orquestación (Airflow, Dagster, Prefect), el framework de procesamiento (Spark, Flink), y si has trabajado batch, streaming o ambos. El campo de carta de presentación es frecuentemente opcional y frecuentemente se omite en esta fase. Tiende a leerse más tarde, una vez que estás preseleccionado, por el hiring manager que decide a quién citar para la prueba técnica —y para entonces ya se ha formado una opinión desde el CV.

Donde la carta se ignora sistemáticamente: puestos con un ejercicio para casa o una prueba en vivo de SQL/Python en primera fase. Muchos procesos de data engineering pasan directamente de CV a tarea técnica —construir un pipeline pequeño, depurar un DAG, escribir una consulta contra un esquema de muestra— y la carta no tiene influencia en si superas esa fase. Si el anuncio menciona una evaluación técnica antes de cualquier conversación humana, asume que la carta hace muy poco.

Lo único o los dos únicos puntos que tiene que responder

Cuando la carta se lee, suele ser porque el CV solo deja un hueco que el lector tiene que rellenar por su cuenta. Dos huecos aparecen con suficiente frecuencia en este campo como para abordarlos directamente.

El primero es la transferencia de stack. Las herramientas de data engineering se agrupan en familias que no se corresponden uno a uno, y un hiring manager que busque "5 años de dbt" no necesariamente inferirá que tus 5 años de lógica de transformación basada en procedimientos almacenados en un stack de Microsoft cubren el mismo terreno. Si tu experiencia está en Azure Data Factory y solicitas un puesto donde usan Airflow, o tu experiencia en warehouse es Redshift y el puesto es BigQuery, di claramente cuál es la habilidad subyacente —carga incremental, diseño de tareas idempotente, backfilling de un DAG, gestión de dimensiones que cambian lentamente— en lugar de dejar que el lector adivine si la diferencia de sintaxis es un hueco real o cosmético. Esta es la frase de mayor valor que puede contener una carta de presentación de data engineering, y la mayoría no la tienen.

El segundo es el ajuste de dominio, cuando es genuinamente relevante. Un pipeline que mueve eventos de clickstream para atribución en ad-tech tiene exigencias distintas de latencia y deduplicación que uno que mueve datos de reclamaciones para una aseguradora, que a su vez tiene exigencias distintas de genómica o datos de operaciones financieras. Si el anuncio especifica un dominio y tu último puesto fue en uno diferente, una frase sobre cómo manejaste una restricción análoga —datos que llegan tarde, manejo de PII, una auditoría exigida por cumplimiento— dice al lector que entiendes qué es realmente difícil de sus datos, no solo que puedes escribir un DAG.

Más allá de esos dos, no hay mucho más que un hiring manager de data engineering busque en una carta específicamente. Este no es un campo donde se espere que la carta transmita personalidad o motivación como podría ocurrir en, digamos, un puesto de cara al cliente o de misión corporativa. Mantenla en dos párrafos cortos que respondan la cuestión del stack y, si es relevante, la del dominio, y para ahí.

Qué no incluir

No repitas lo que ya está detallado en el CV —"construí y mantuve pipelines ETL/ELT usando Python y SQL" no dice al lector nada que la sección de habilidades del CV no haya dicho ya, y repetirlo se lee como relleno.

No enumeres herramientas por enumerarlas. El filtrado de palabras clave del ATS, donde existe, trabaja sobre tu CV y formulario de solicitud, no sobre la carta de texto libre. Nombrar Airflow, dbt, Spark y Kafka en un párrafo no te ayuda a superar un filtro de palabras clave que ya has superado o fallado en el CV.

No escribas entusiasmo genérico —"apasionado por los datos" o "entusiasmado por la oportunidad de aprovechar datos para generar valor empresarial" es relleno que todo hiring manager de data engineering ha leído cien veces y omite. Si quieres señalar interés genuino, sé específico: un problema particular en su plataforma de datos en el que querrías trabajar, basado en algo del anuncio o su blog de ingeniería, vale más que un adjetivo.

Donde genuinamente tiene poco peso

Vale la pena ser directo sobre esto en lugar de fingir que toda solicitud se beneficia igual de una carta bien elaborada. Para un data engineer con un historial claro y coincidente que solicita un puesto que especifica el stack que ya usa, la carta es casi irrelevante. El CV y la prueba técnica hacen el filtrado real. Pasar una tarde puliendo una carta de presentación para ese tipo de solicitud es tiempo que haría más bien dedicado a la tarea para casa, o a asegurar que un proyecto de pipeline en tu portfolio sea uno del que puedas hablar en detalle.

La carta gana más peso en situaciones específicas: cuando el formulario de solicitud la hace obligatoria y tienes que escribir algo; cuando te estás moviendo a data engineering desde un puesto adyacente —data analyst, backend engineer, DBA— y el CV solo no hace obvias las habilidades transferibles; cuando hay un hueco, un movimiento de contrato a permanente, o un cambio de carrera sobre el que el CV plantea preguntas; o cuando solicitas a una empresa pequeña donde la persona que lee todo es la misma que será tu manager, y dos párrafos genuinamente bien dirigidos pueden empujar un CV límite hacia una entrevista.

Fuera de esas situaciones, trata la carta como de bajo impacto. Escríbela competentemente, mantenla corta, y no dejes que se convierta en aquello en lo que gastas tiempo desproporcionado respecto a lo que probablemente hará.

Qué hacer a continuación

Comprueba primero si la solicitud requiere realmente una carta —muchos formularios ATS la marcan como opcional, y si lo es, solo escribe una si tienes algo que decir que el CV no puede decir por sí solo. Si la escribes, pon la frase de transferencia de stack en el primer tercio: nombra la herramienta o plataforma que pide el anuncio y la que realmente usaste, y di directamente cómo la habilidad se transfiere. Añade la frase de dominio solo si el anuncio nombra un dominio y el tuyo difiere de él. Corta todo lo que repita el CV o declare entusiasmo sin especificidad. Y si la primera fase del puesto es un ejercicio para casa o prueba técnica, pon tu tiempo restante ahí —ahí es donde realmente se decide este tipo de solicitud.

jobmarket.pro lee el anuncio completo contra un perfil de candidato y redacta la carta desde lo que es realmente cierto de ese perfil, en lugar de desde una plantilla, cuando se solicita una carta.