Carta de presentación para programador: cómo describir tus proyectos en tres líneas

Lo que lee un equipo técnico

Quien revisa candidaturas de desarrollo suele hacerlo con dos pestañas abiertas: tu carta y tu repositorio (o tu web). Si la carta dice «apasionado de la tecnología» y el repositorio está vacío, el mensaje se contradice. Si dice «hice esta aplicación de reservas con un backend en X y la usan cuatro locales» y el enlace funciona, el mensaje se refuerza solo.

Por eso, en esta carta:

• Los enlaces (repositorio, demo, perfil público) van en el primer o segundo párrafo, no en una despedida.
• Cada proyecto se resume en tres líneas, con un patrón fijo (más abajo).
• Las tecnologías se nombran solo si las has usado de verdad; es habitual que en la entrevista te pidan que enseñes código.
• La extensión es corta. Con 150-200 palabras se cubre todo.

Plantilla de tres líneas para cada proyecto

Línea	Qué cuenta	Ejemplo
Problema	Para quién y por qué	«Una aplicación para que un club de pádel gestione reservas de pistas»
Qué hiciste tú	Tu parte, no la del equipo	«Hice el backend y la base de datos; el diseño era de un compañero»
Resultado verificable	Algo que se pueda comprobar	«Está desplegada en [enlace] y tiene pruebas automáticas»

Con dos proyectos descritos así la carta se sostiene sin necesidad de más. Si has trabajado en equipo, indica con claridad qué parte hiciste: en una entrevista técnica se nota si has exagerado.

Qué decir si eres junior o autodidacta

Hay tres frases que funcionan mejor que cualquier declaración de ganas de aprender:

1. Una cosa que has aprendido recientemente y cómo la aplicaste («Aprendí a escribir pruebas automáticas para el proyecto y detecté dos errores antes de publicar»).
2. Un error que corregiste, explicado en una línea («Mi primera versión cargaba toda la lista de reservas en cada pantalla; la paginé y la carga bajó a un instante perceptible»).
3. Qué esperas aprender en la empresa, concretando la tecnología o la práctica (revisión de código, despliegue continuo).

Evita listas largas de tecnologías con barras de nivel o «100 %». Una lista corta y ordenada por uso tiene más credibilidad.

Modelo: puesto junior en una agencia web

Directo y en un registro técnico moderado, con tuteo a la persona que lee si la oferta lo permite; aquí se mantiene el usted porque la oferta lo usa.

Frases que no aportan y sus alternativas

Evita	Escribe mejor
«Soy una persona autodidacta y apasionada»	«Aprendí [tecnología] construyendo [proyecto], disponible en [enlace]»
«Domino HTML, CSS, JavaScript, React, Angular, Vue, Python, Java…»	«Uso sobre todo JavaScript y React; uso Python en scripts de automatización»
«Soy un trabajador en equipo»	«Colaboro con Git: abro ramas y pido revisión antes de integrar»
«Resuelvo problemas complejos»	«Reduje el tiempo de carga al paginar los resultados» (solo si es verdad)

Si la empresa pide una prueba técnica

Algunas empresas piden un ejercicio previo. En la carta puedes aprovechar para decir si prefieres hacerlo en casa o en directo, y cuánto tiempo puedes dedicar. No hace falta más, y no conviene presentarla como una molestia.

Detalles de la ficha pública

Antes de dar el enlace al perfil público, mírate el perfil como lo vería un desconocido: foto, descripción, repositorios fijados, mensajes de código. Retira lo que no quieras que se vea: claves, datos personales de otras personas, proyectos de clase con enunciados copiados.

Variante corta para escribir a una startup

Cuando escribes directamente a quien fundó la empresa, el tono es más informal y la carta, aún más breve. Esta variante parte de que ya has mirado qué producto hacen.

Qué hace bien: demuestra que has usado el producto, propone algo concreto y deja la decisión en manos de quien lee. Qué conviene vigilar: que la propuesta sea correcta y respetuosa, que no critique el trabajo del equipo y que no utilices su código ni sus datos sin permiso.

Piezas para otros cuatro perfiles técnicos

El modelo de arriba parte de un desarrollador web junior. Estas aperturas, cuerpos y cierres adaptan la carta a otros perfiles. En todos, los enlaces van arriba y los proyectos se cuentan con el patrón de tres líneas.

Desarrollador de backend con experiencia en una empresa

Analista o científico de datos junior

Perfil de soporte técnico o sistemas

Cambio desde otro sector hacia desarrollo

Perfil técnico: afirmaciones que sustituir por pruebas

Frase débil	Qué falla	Frase mejor
«Apasionado por la tecnología»	Nadie lo comprueba	«Mantengo desde hace un año una herramienta de línea de comandos que usa un grupo de compañeros»
«Conocimientos de Python, Java, C++, SQL…»	Lista sin contexto	«Uso Python a diario y SQL para consultas; Java solo en proyectos de clase»
«Experiencia en metodologías ágiles»	Etiqueta	«Trabajé en sprints de dos semanas con revisión al final de cada uno»
«Resuelvo problemas con eficacia»	Sin ejemplo	«Reduje de 12 a 3 segundos un informe paginando las consultas» (si es real)
«Aprendo rápido»	Autodeclaración	«Aprendí Docker para desplegar mi proyecto y lo documenté en el repositorio»
«Buen nivel de inglés»	Sin dato	«Leo documentación técnica en inglés y escribo mis commits y mi README en inglés»

Qué mira un equipo técnico y en qué orden

Cómo preparar el repositorio que vas a enlazar

Antes de dar un enlace conviene dejarlo en orden. Estos cuatro pasos llevan una hora y mejoran mucho la primera impresión.

1. Escribe un README breve que diga qué hace el proyecto, cómo se ejecuta y qué tecnologías usa.
2. Fija en tu perfil los dos o tres repositorios que mejor te representan, en lugar de dejar que se muestren por fecha.
3. Revisa el historial de cambios para comprobar que no contiene claves, contraseñas ni datos personales.
4. Añade una captura o una demo en línea, de modo que quien lee vea el resultado sin instalar nada.

Trabajo remoto, híbrido o presencial: qué decir

Muchas ofertas de desarrollo mencionan la modalidad de trabajo y la carta es un buen sitio para dejar claro qué te encaja, sin convertirlo en una exigencia. Conviene ser concreto y breve.

Modalidad de la oferta	Qué puede decir tu carta	Qué evitar
Remoto	«Trabajo en remoto desde hace dos años, con reuniones diarias breves y documentación escrita de las decisiones»	Prometer disponibilidad en cualquier zona horaria sin comprobarlo
Híbrido	«Puedo acudir a la oficina los días que el equipo necesite y trabajar en remoto el resto»	Imponer condiciones antes de conocer la dinámica del equipo
Presencial	«Resido en la ciudad y puedo incorporarme sin necesidad de reubicación»	Dejar sin explicar si necesitarías mudarte

Si la oferta es remota, menciona cómo te organizas: herramientas de comunicación, horarios solapados con el equipo y forma de dejar el trabajo documentado. Es lo que más preocupa a quien contrata a distancia y casi nadie lo cuenta.

Prepararse para la prueba técnica que suele venir después

Muchas candidaturas pasan por un ejercicio. Si en la carta dices que lo harás con gusto, te conviene llegar con una rutina de preparación y no improvisar.

• Repasa tu propio código: vuelve a leer los proyectos que has enlazado, porque te pedirán que expliques decisiones concretas.
• Prepara tres historias técnicas: un problema que resolviste, un error que cometiste y algo que cambiarías de un proyecto.
• Practica a explicar en voz alta, sin pantalla, el flujo principal de tu mejor proyecto en dos minutos.
• Aclara las condiciones del ejercicio: tiempo, herramientas permitidas y criterios de evaluación. Preguntar es normal y muestra criterio.

Cómo hablar de un proyecto de equipo sin quedarte con el mérito de todos

En una entrevista técnica es habitual que te pregunten qué hiciste tú y qué hicieron los demás. La carta ya puede marcar esa frontera con naturalidad.

• Usa «yo» para tus tareas y «nosotros» para las decisiones compartidas.
• Nombra tu parte exacta: módulo, componente, pruebas, despliegue, documentación.
• Reconoce el trabajo de otros con una mención breve: «el diseño fue de un compañero».
• Enlaza el repositorio original, no una copia, para que se vea el historial de cambios.
• Prepara una explicación de dos minutos de una decisión técnica que tomaste y de por qué.

Esta honestidad no resta valor, lo aumenta: quien lee tu carta entiende que sabes trabajar en equipo y que no necesitas apropiarte de lo que no es tuyo.

Revisión final

• Hay al menos un enlace funcional a código o a una demo.
• Cada proyecto se describe en tres líneas: problema, mi parte, resultado.
• Las tecnologías mencionadas las puedo explicar en una entrevista.
• No hay claves, datos privados ni código ajeno en lo que enlazo.
• La carta cabe en menos de una pantalla.