Lo que un reclutador realmente escanea primero
Un reclutador dedica unos segundos al tercio superior de un currículum de ingeniero de software antes de decidir si sigue leyendo: tu título más reciente, los lenguajes y frameworks en tu línea de habilidades, y la primera viñeta bajo tu puesto más reciente. Todo lo que hay debajo confirma la impresión que ya causó la parte superior de la página, o hace que el lector pierda del todo la atención.
Eso significa que el encabezado y la primera experiencia laboral pesan más que cualquier otra parte de la página. Pon tu línea más fuerte y específica primero bajo cada puesto en lugar de esconderla como la tercera o cuarta viñeta, y mantén la línea de habilidades cerca del principio para que una mirada rápida la alcance antes de pasar al siguiente currículum de la pila.
Un ejemplo junior: proyectos en lugar de experiencia
Un ingeniero junior con unas prácticas y algunos proyectos personales aún puede escribir un currículum completo y específico tratando cada proyecto como una entrada laboral. Bajo un proyecto llamado "Order Tracker", un candidato junior podría escribir: "Construí una app de seguimiento de pedidos con React y Node para una cafetería local; añadí un filtro de búsqueda que redujo el tiempo medio de búsqueda de 12 segundos a menos de 2." Esta es una ilustración concreta y citada del patrón, no una afirmación sobre un resultado típico.
La entrada de prácticas sigue la misma regla: nombra lo que cambió, no solo lo que se te asignó. Una línea como "Corregí 14 errores reportados en el flujo de pago durante unas prácticas de 10 semanas, tres de los cuales bloqueaban el lanzamiento" le dice más a un lector que "Ayudé al equipo de ingeniería con correcciones de errores." Limita esta sección a dos o tres proyectos, cada uno con una o dos viñetas, en lugar de listar cada repositorio que alguna vez publicaste.
Un ejemplo de nivel medio: viñetas de impacto con un antes y un después
Un ingeniero de nivel medio con tres a seis años de experiencia debería reemplazar las viñetas basadas en tareas con una cifra de antes y después dondequiera que exista realmente. Para un puesto backend, eso podría decir: "Reduje la latencia p95 del pago de 1.8 s a 620 ms agrupando tres consultas secuenciales en una, en un servicio que maneja unas 40,000 peticiones diarias." La cifra hace el trabajo de convencer; la frase alrededor solo da contexto.
Un segundo ejemplo para otro tipo de contribución: "Lideré la migración del módulo de autenticación de un monolito a un servicio separado, coordinando con otros dos equipos durante seis semanas sin tiempo de inactividad durante la transición." No todas las viñetas necesitan un porcentaje: una declaración de alcance como "coordinando con otros dos equipos" sigue siendo concreta, porque nombra quién estuvo involucrado y cuánto tiempo tomó, en lugar de solo llamar al trabajo "colaboración entre equipos."
Cuándo mantener una sección de proyectos aparte
Una sección de proyectos dedicada tiene sentido cuando tienes trabajo paralelo que muestra algo que tu historial laboral no muestra: un lenguaje que usas fuera del trabajo, una contribución de código abierto, o una herramienta personal que construiste y sigues manteniendo. Para un candidato junior a menudo hace más trabajo que la propia sección de experiencia; para uno senior suele ser opcional a menos que el proyecto sea inusualmente relevante para el puesto al que aplicas.
Mantén cada entrada de proyecto en una línea de contexto y una o dos viñetas, la misma densidad que una entrada laboral, y enlaza el repositorio o una demo en vivo si alguno existe. Una sección de proyectos que lista diez elementos sin detalle se lee como relleno; tres elementos con una viñeta específica cada uno se leen como evidencia.
Habilidades y herramientas: específicas, no exhaustivas
Enumera los lenguajes, frameworks y herramientas sobre los que realmente te sentirías cómodo respondiendo en una entrevista, agrupados de una manera que tenga sentido para el puesto: lenguajes, frameworks, infraestructura, etcétera. Omitir una tecnología que usaste una sola semana está bien; la lista debe reflejar aquello sobre lo que puedes hablar, no todo lo que alguna vez tocó tu currículum.
Ajusta la redacción a la oferta cuando sea honestamente precisa: si la oferta dice "PostgreSQL" y lo usaste, escribe "PostgreSQL" en lugar de solo "bases de datos SQL", ya que tanto un sistema de seguimiento de candidatos como un lector humano suelen buscar el término exacto. No añadas una tecnología que no has usado solo porque una oferta la menciona: ese vacío sale a la luz en la primera conversación técnica.
Preguntas frecuentes
- ¿Un currículum junior de ingeniero de software debe listar primero proyectos o experiencia?
- Proyectos primero si tienes poca experiencia remunerada, ya que ahí está tu evidencia más fuerte y específica; mueve la experiencia por encima de los proyectos en cuanto tengas unas prácticas o un empleo real que mostrar, y mantén la sección más fuerte más cerca del principio de la página.
- ¿Cuántas viñetas debería tener cada proyecto o puesto?
- Dos a cuatro viñetas por entrada suele ser suficiente para mostrar qué construiste y qué cambió como resultado. Más que eso empieza a diluir la página, y un lector tiende a recordar mucho mejor la primera o segunda línea bajo cada entrada que la cuarta o quinta.
- ¿Está bien reutilizar el mismo currículum para cada empleo de ingeniería de software?
- La estructura puede mantenerse igual, pero la línea de habilidades y el orden de tus viñetas deberían cambiar para coincidir con los requisitos de cada oferta, ya que tanto un lector humano como un filtro automático suelen buscar los términos específicos que usa esa oferta de trabajo.
- ¿Qué debería recortar un ingeniero de nivel medio si el currículum supera dos páginas?
- Recorta los puestos de hace más de unos diez años a menos que sean directamente relevantes, reduce cualquier viñeta que solo describa una responsabilidad en lugar de un resultado, y conserva la sección de proyectos solo si muestra algo que tu historial laboral realmente aún no cubre.