Un currículum creíble para un desarrollador junior sin experiencia remunerada todavía empieza por lo que realmente puedes demostrar, no por una sección de experiencia vacía estirada artificialmente. Los proyectos personales, los trabajos de curso, un proyecto final de bootcamp o cualquier contribución real a una base de código se convierten en la sección que de otro modo ocuparía la experiencia, construida de la misma forma que una entrada laboral: un título claro, fechas, el stack usado y una breve descripción de lo que cambió gracias a ello. La formación respalda eso, y un breve resumen al principio indica con claridad tu nivel actual y el tipo de puesto al que aspiras, en lugar de disfrazar con un lenguaje vago la falta de un empleo remunerado.
Coloca los proyectos donde normalmente iría la experiencia
Para un currículum de desarrollador junior sin experiencia remunerada, un buen cambio estructural es dar a la sección de proyectos el mismo peso y posición que suele tener el historial laboral: primero el encabezado y el resumen breve, luego proyectos, después formación, luego una sección de habilidades y solo entonces cualquier cosa extraacadémica. Los reclutadores y responsables de selección suelen leer rápidamente de arriba abajo, así que el contenido más fuerte y relevante para el puesto debe ir primero, y para alguien cuyo mayor activo es un portafolio de cosas que ha construido, eso son los proyectos, no unas prácticas o un trabajo a tiempo parcial sin relación con el desarrollo. Dos o tres proyectos, elegidos por su relevancia para el puesto objetivo y no por lo recientes que sean, se leen mejor que cinco o seis apretujados. Un proyecto hecho para una asignatura universitaria, un proyecto final de bootcamp y una herramienta personal tienen cabida aquí, siempre que cada uno reciba el mismo tratamiento: un nombre, una breve descripción, el stack y qué hace, no solo una lista de nombres de asignaturas.
Escribe cada entrada de proyecto como un empleo, no como una afición
Cada entrada de proyecto funciona mejor con los mismos campos que tendría una entrada laboral: un título, un periodo, las tecnologías usadas, y de una a tres líneas describiendo qué hace el proyecto, qué parte construiste tú si fue un trabajo en grupo, y cualquier cambio o resultado que se derivó de ello. Nombrar el stack concreto, un lenguaje, un framework, una base de datos, una plataforma de despliegue, importa más aquí que en una entrada laboral, ya que suele ser la prueba más clara que tiene el lector de lo que realmente sabes hacer. Si un proyecto se construyó con otras personas, indica qué parte fue específicamente tuya en lugar de describir el proyecto en su conjunto dejando tu contribución poco clara; un proyecto de equipo que solo menciona el logro colectivo se lee más vago, no más impresionante. Un proyecto aún en curso merece incluirse si está lo bastante avanzado como para describirlo de forma concreta, pero un proyecto que nunca pasó de la idea es mejor dejarlo fuera del todo, ya que una entrada de currículum necesita tener algo concreto que decir sobre lo que realmente se construyó.
Una contribución al código de otra persona también cuenta, y suele leerse como más creíble que un proyecto en solitario porque demuestra que sabes trabajar dentro de un código que no escribiste tú. Si arreglaste un error, añadiste una pequeña función o mejoraste la documentación de un proyecto de código abierto, nombra el proyecto, describe el cambio concreto en una línea, y explica qué hizo falta para que se aceptara, como entender una suite de pruebas ya existente o seguir por primera vez un proceso de contribución. Una entrada así, aunque sea pequeña, demuestra algo que un proyecto en solitario de fin de semana no puede: trabajar dentro de las restricciones de otra persona, no de las tuyas.
Ejemplo ilustrativo: una línea de proyecto vaga reescrita como entrada
Antes: «Hice una página web con unos amigos para un trabajo de clase».
Después: «Task Tracker, proyecto de equipo, asignatura universitaria, marzo-mayo de [año]. Construí la API del backend en Node.js y Express, encargándome de la autenticación y la asignación de tareas para un equipo de cuatro personas; el frontend lo construyeron dos compañeros con React. Desplegado en un plan de alojamiento gratuito para la sesión de demostración de la asignatura».
La versión reescrita mantiene el mismo hecho de base, un pequeño proyecto de equipo de una asignatura, pero ahora indica el stack, la parte concreta que se construyó, el tamaño del equipo y lo que resultó de ello, lo que le da al lector algo concreto que valorar en lugar de una frase plana.
Habilidades y formación, con honestidad
Lista las habilidades agrupadas por categoría, lenguajes, frameworks, herramientas, nube, en lugar de en una única línea larga sin ordenar, de forma parecida a como puede agruparse una sección de habilidades en la plantilla para desarrolladores de CVBuilderKit. Limita la lista a cosas de las que podrías hablar en una entrevista con una profundidad razonable; una lista larga rellena con herramientas tocadas una sola vez en un tutorial hace más daño que una lista más corta pero precisa, ya que un entrevistador que pregunte por una entrada inflada notará el vacío enseguida. La formación se mantiene, indicando el título, la institución y la fecha de graduación prevista o real, junto con cualquier asignatura directamente relevante para el puesto objetivo si esta sección se queda algo escasa por sí sola.
Antes de enviar la primera versión
Una vez la estructura está lista, lee todo el documento como lo haría un reclutador: ¿dice la primera entrada de proyecto lo suficiente como para merecer una segunda mirada, y el resumen expresa un objetivo real en lugar de uno genérico? Vale la pena leer el resumen por separado, aislado del resto del documento, y preguntarte si nombra un tipo de puesto concreto, como «desarrollador backend junior» o «desarrollador frontend centrado en React», en lugar de una frase genérica como «desarrollador motivado en busca de oportunidades» que podría describir a casi cualquiera. Escribir un currículum con poca o ninguna experiencia laboral como recién graduado trata el mismo problema desde un ángulo más amplio si la sección de proyectos por sí sola aún no tiene suficiente peso, especialmente en cómo plantear la formación y las prácticas. Cuando la estructura te parezca correcta, empieza a construirlo y ajusta la redacción a medida que añadas cada proyecto nuevo; un currículum construido así es fácil de ampliar cuando por fin llega el primer empleo remunerado, ya que la sección de proyectos simplemente baja de posición en lugar de tener que reconstruirse desde cero.