Ingeniero de Software
Un currículum de ingeniería lo suelen leer dos veces dos personas distintas que quieren cosas distintas. Alguien de selección compara el stack con el de la oferta y dedica bastante menos de un minuto. Después lo lee otra persona de ingeniería buscando el tamaño y la dificultad de los sistemas en los que has trabajado. Una página afinada solo para una de las dos falla con la otra, y casi todas están afinadas para la primera.
La lista de tecnologías te hace leer y ahí deja de ayudar
El cruce de palabras clave en la primera criba es real, y fingir lo contrario cuesta entrevistas. Si la oferta dice Kotlin y Postgres y tú has trabajado con ambos, esas palabras tienen que aparecer. Ese es todo el trabajo de la sección de tecnologías.
Y también todo su valor. En cuanto lee alguien de ingeniería, una lista de dieciocho tecnologías perjudica: invita a suponer que la mayoría se tocaron una vez, y hace imposible encontrar las dos en las que eres realmente fuerte. Separa aquello sobre lo que estarías cómodo en una entrevista técnica de lo que simplemente has usado, o elimina el segundo grupo.
Los números de versión, las tablas de años por lenguaje y las barras de nivel autoevaluadas se leen como relleno para quien va a entrevistarte. Ninguna sobrevive a la primera pregunta técnica.
Describe el sistema, no la tarea
«Desarrollé nuevas funcionalidades con React y Node.js» está en miles de currículums y no transmite nada sobre dificultad. Lo que quiere saber otra persona de ingeniería es escala y restricción: cuánto tráfico, cuántos datos, cuántos servicios, qué no podía caerse y quién más dependía de ti.
«Responsable del servicio de pagos —400 peticiones por segundo en pico, reintentos idempotentes contra tres proveedores— y reduje los reintentos por cobro fallido del 11 % al 3 %» dice en una línea qué clase de ingeniero eres. Además le regalas la pregunta de entrevista que iba a hacerte igualmente, lo que juega a tu favor.
Las incidencias también van aquí. Algo que rompiste y arreglaste, o una caída que diagnosticaste, se recuerda de una forma en que el trabajo de funcionalidades no, y demuestra el criterio operativo que separa a un perfil medio de uno senior mucho mejor que un título.
La seniority se ve en el radio de impacto
Los títulos son ruido entre empresas: un «senior» en una startup de doce personas y en un banco no son la misma afirmación, y quien lee lo sabe. Lo que sí viaja es el radio de tus decisiones: cuánta gente tuvo que convivir con ellas, y durante cuánto tiempo.
Documentos de diseño que se adoptaron, una migración que otros equipos tuvieron que seguir, una interfaz que llaman una docena de servicios, una cultura de revisión que cambiaste. Eso se lee como seniority en cualquier organización. «Mentoricé a desarrolladores junior» no, porque aparece en todos los currículums de nivel medio en adelante y nunca se desarrolla.
Si has sido la persona a la que otros preguntan antes de tocar cierta zona, esa es la frase que hay que escribir, y conviene ser concreto sobre la zona.
Dónde suelen descartarse estos currículums
El patrón más dañino es una página de responsabilidades que podría describir a cualquier desarrollador de cualquier empresa: participé en revisiones de código, trabajé en un entorno ágil, colaboré con equipos multidisciplinares. Todo cierto, todo compartido con el resto de candidatos, y en conjunto una página entera de nada.
El segundo es una sección de proyectos personales que pesa más que la profesional, en un currículum que sí tiene experiencia profesional. Los proyectos con forma de tutorial invitan a compararse con tu trabajo remunerado y pierden. Deja uno si es genuinamente inusual, y solo si te gustaría que te preguntaran por él.
El tercero es el silencio sobre por qué te fuiste cuando las fechas lo gritan. Las etapas cortas y los huecos son normales y solo se vuelven un problema cuando la página parece esquivarlos. Cuatro palabras —«fin de contrato», «disolución del equipo», «vuelta a estudiar»— eliminan la pregunta por completo.
Términos que aparecen en casi todas las ofertas.
- Lenguajes y frameworks concretos
- Un filtro literal en la primera criba. Incluye lo cierto y lo que nombra la oferta; no rellenes más allá.
- Diseño de sistemas
- Tráfico, volumen de datos, modos de fallo. «Escalable» no es evidencia.
- Nube e infraestructura
- Si la operabas o la consumías. Son trabajos distintos y en la entrevista se pregunta.
- Pruebas e integración continua
- Qué cambiaste en la forma de desplegar del equipo, no que existieran pruebas.
- Guardias / producción
- Una incidencia que diagnosticaste dice más sobre seniority que cualquier título.
Añade un término solo cuando tu propia experiencia lo respalde. ApplySpan señala los requisitos que no puedes acreditar en lugar de escribirlos por ti.
Preguntas
¿Cuánto debe medir un currículum de ingeniero de software?+
Una página hasta unos ocho años, dos después. No es tanto una regla como una observación: la primera criba es corta, y a la segunda página solo se llega si la primera se lo ganó.
¿Hace falta enlazar GitHub o un portafolio?+
Solo si contiene algo por lo que te apetecería que te preguntaran. Un perfil abandonado de forks y tutoriales es peor que ningún enlace, porque quien revisa te juzgará por lo más flojo que encuentre.
¿Debo listar tecnologías que apenas he usado?+
No en el mismo grupo que tus fortalezas. Quien entrevista elige de tu lista, y no hay nada que ganar con una pregunta sobre algo que tocaste una vez hace dos años.