Portfolio Projects for Data Engineer

Tienes tres certificados, un par de tutoriales terminados y sigues sin llamadas para puestos de Data Engineer. El problema no es tu esfuerzo: es que los certificados y los tutoriales copiados casi no pesan en una revisión técnica.

Lo que pesa es un proyecto donde se ve que tomaste decisiones, que hubo datos sucios, que elegiste una herramienta por una razón y que puedes explicar por qué. Tres proyectos bien construidos superan a seis certificados. Aquí van tres ideas concretas, qué mira quien evalúa y cómo presentarlas sin humo.

Qué mira realmente quien revisa tu perfil#

El revisor dedica menos de un minuto a tu GitHub antes de decidir si sigue leyendo. Busca tres cosas. Que el proyecto resuelva algo concreto. Que haya trabajo propio visible, no solo el código del tutorial. Que el código y la documentación se entiendan sin que tú estés ahí para explicarlos.

También mira señales de ingeniería: cómo manejas errores, si hay tests, si el pipeline se puede ejecutar de nuevo sin romperse, si documentaste decisiones y límites. No espera un sistema de producción a escala. Espera criterio.

Proyecto 1: un pipeline de ingesta con datos reales y sucios#

Agarra una fuente pública con datos desordenados: registros de movilidad municipal, datos abiertos de compras públicas, o una API con límites de tasa y respuestas inconsistentes. El objetivo es ingerir, limpiar, validar y dejarlo consultable.

Que se vea tu trabajo en:

• Un extractor con reintentos y manejo de rate limits, no un requests.get suelto.
• Validaciones de datos con esquema, por ejemplo con Great Expectations o validaciones propias. Qué pasa si llega una fecha nula o un valor negativo donde no debe.
• Un almacenamiento en capas, crudo, limpio y curado, en Postgres o un lakehouse local con DuckDB o Parquet.
• Un registro de ejecuciones: cuántos registros entraron, cuántos fallaron y por qué.

Ejemplo de bullet para el CV:

Antes: "Construí un pipeline de datos con Python y Airflow". Después: "Diseñé un pipeline de ingesta diaria de 1,2 millones de registros de movilidad con Airflow y Postgres, con validación de esquema y reintentos automáticos, reduciendo los fallos por datos inválidos de un 9% a menos del 1% tras tres iteraciones".

Los números no tienen que ser enormes. Tienen que ser tuyos y verificables.

Proyecto 2: un modelo de datos y transformaciones para un caso de negocio#

Aquí el reto es modelar, no solo mover datos. Toma el dataset del primer proyecto, o uno nuevo, y responde preguntas de negocio: coste por unidad, tendencia mensual, ranking de proveedores, anomalías.

Construye un modelo dimensional con dbt: staging, intermediate, marts. Documenta las métricas. Escribe tests de dbt para unicidad, nulidad y relaciones. Deja un dashboard sencillo o un notebook de análisis al final.

Lo que convence aquí:

• Definiste métricas y discutiste ambigüedades. "Ingreso" puede significar tres cosas distintas.
• Particionaste y materializaste tablas pensando en el rendimiento.
• Explicaste por qué dimensional y no un star schema plano, o al revés.
• El proyecto tiene un README que responde qué pregunta de negocio resuelve.

Proyecto 3: orquestación, calidad de datos y despliegue#

Este proyecto demuestra que piensas en operar sistemas, no solo en escribir SQL. Toma los dos proyectos anteriores y añade orquestación, monitorización y despliegue.

• Orquesta con Airflow, Dagster o Prefect. Programa, define dependencias y política de reintentos.
• Añade pruebas de calidad de datos que fallen el pipeline si algo se sale de rango.
• Publica métricas en un log o un dashboard simple: volumen, latencia, tasa de error.
• Despliega en un entorno accesible. Un contenedor Docker corriendo en una VM pequeña basta. No hace falta Kubernetes.
• Añade CI con GitHub Actions que corra tests y lint en cada push.

Este proyecto responde a la pregunta que todo entrevistador tiene: ¿esta persona puede mantener esto en producción?

Cómo presentarlos en tu CV#

Una línea por proyecto, máximo dos. Estructura: acción, herramienta, escala, resultado. Verbo de acción al inicio. Herramientas concretas, no "tecnologías modernas". Escala real, aunque sea modesta. Resultado medible o al menos observable.

Si no tienes experiencia laboral, crea una sección "Proyectos de datos" por encima de la formación. Trátala con seriedad: nombre del proyecto, una línea de contexto, dos bullets de logros, enlace al repositorio.

Usa un verificador de compatibilidad con ATS para comprobar que el formato no se rompe y que las palabras clave del puesto aparecen de forma natural. Y si tienes dudas sobre qué pide realmente una oferta, decodifica la descripción del puesto antes de adaptar tu CV.

Cómo organizar GitHub#

Cada repositorio necesita lo mismo. Un README que empiece con qué hace el proyecto y por qué existe. Arquitectura en un diagrama simple, aunque sea ASCII. Instrucciones de ejecución que funcionen en una máquina limpia. Ejemplo de datos o cómo obtenerlos. Decisiones técnicas y alternativas descartadas. Límites conocidos.

Evita el error más común: un README de tres líneas y un notebook suelto. Si el proyecto no se puede ejecutar siguiendo tu README, para el revisor no existe.

Ejemplo de sección "Decisiones técnicas":

"Elegí Postgres sobre BigQuery porque el volumen, 1,2 millones de registros al mes, no justifica un warehouse gestionado y quería controlar el coste. Probé Airflow y Prefect; me quedé con Airflow por la comunidad y porque el equipo objetivo ya lo usa. Descarté Kafka porque el volumen no justifica streaming."

Eso demuestra criterio. Es lo que separa un proyecto de un tutorial.

Errores que delatan que copiaste un tutorial#

• El README dice "proyecto del curso de X" o no menciona el problema que resuelve.
• Los nombres de tablas y columnas son genéricos, table1, col_a. Nadie modela así.
• No hay manejo de errores. Todo funciona a la primera.
• Los datos son el CSV de ejemplo del curso, con 200 filas perfectas.
• No hay tests ni validaciones.
• El commit history es un único commit gigante con "initial commit".
• El proyecto es idéntico al de otros cien candidatos que hicieron el mismo curso.

Si vienes de un tutorial, está bien. Reconstrúyelo con otros datos, cambia el modelo, añade validaciones y documenta qué cambiaste y por qué. Eso ya es trabajo tuyo.

Cómo hablar de los proyectos en entrevistas#

Prepara una respuesta de dos minutos por proyecto: el problema, tus decisiones, un obstáculo y el resultado. Después, listo para el detalle.

Ejemplo de respuesta:

"Construí un pipeline de ingesta de datos de movilidad municipal. El problema era que la fuente cambiaba el formato sin aviso y el 9% de los registros fallaban la validación. Añadí un esquema versionado y reintentos con backoff, y dejé los registros inválidos en una tabla de cuarentena para revisión manual. Tras tres iteraciones, los fallos bajaron a menos del 1%. Si tuviera que rehacerlo, empezaría con contratos de datos desde el día uno."

Los entrevistadores preguntan mucho "¿qué harías distinto?". Tener una respuesta preparada y honesta vale más que defender el proyecto como perfecto.

También prepárate para preguntas de fondo: por qué esa herramienta y no otra, qué pasa si se duplican los datos, cómo harías backfill, cómo monitorizarías el pipeline. Si quieres practicar con ofertas reales, busca vacantes en el buscador de empleo y compara lo que piden con lo que ya sabes hacer.

Qué tanta escala necesitas#

No necesitas procesar terabytes. Necesitas demostrar criterio a escala realista. Un pipeline que procesa un millón de registros al mes con validaciones, tests y documentación vale más que un "proyecto big data" con Spark sobre 500 filas y sin lógica de negocio.

Si vas a usar Spark o Kafka, que sea porque el caso lo requiere y puedas justificarlo. Si no, herramientas simples bien usadas ganan. Puedes encontrar más ideas y plantillas en nuestro blog.

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ántos proyectos necesito para buscar mi primer empleo?

Con tres proyectos bien documentados tienes suficiente para empezar. Es mejor tener dos repos impecables que cinco a medias. La calidad de la documentación y de las decisiones pesa más que la cantidad.

¿Sirve usar datos de un tutorial si no tengo otros?

Sirve como punto de partida, no como proyecto final. Cambia la fuente de datos, modifica el modelo, añade validaciones y documenta qué cambiaste. Si el resultado es indistinguible del tutorial, no suma.

¿Necesito desplegar en la nube con AWS o GCP?

No para el primer empleo. Un entorno local con Docker y CI en GitHub Actions demuestra lo mismo: que sabes empaquetar, testear y desplegar. Si usas cloud, aprovecha el tier gratuito y documenta el coste estimado.

¿Cuánto tiempo debo dedicar a cada proyecto?

Entre dos y cuatro semanas por proyecto si trabajas unas 10 horas semanales. Más tiempo suele significar que estás añadiendo complejidad sin necesidad. Fija un alcance cerrado y cúmplelo.

¿Pongo los proyectos en el CV si no tengo experiencia laboral?

Sí, en una sección específica arriba de la formación. Trátalos como experiencia: verbo de acción, herramientas, escala y resultado. Enlaza al repositorio solo si el README está listo para que lo lea un desconocido.