No existe una forma fiable de asignar un porcentaje a un trabajo de ingeniería que nunca se midió, e inventar una cifra para satisfacer el consejo genérico de "cuantifica tu impacto" es peor que dejar el número fuera, porque una estadística inventada o es falsa o es imposible de defender si alguien te pregunta de dónde salió. Lo que sí se puede describir con honestidad, incluso sin una métrica registrada, es el alcance: el tamaño del sistema, cuánta gente o cuántos servicios dependían de él, con qué frecuencia se ejecutaba y qué cambió realmente entre un estado anterior y uno posterior. Son hechos que normalmente puedes reconstruir de memoria, de un historial de tickets o de un informe posterior a un incidente, y resultan mucho más creíbles para quien lea tu currículum que una cifra salida de la nada.
Por qué el consejo de "simplemente añade un número" falla sin una métrica
La mayoría de los consejos sobre currículums dicen a los ingenieros que cuantifiquen cada línea, y el consejo no está mal en sí mismo: alguien que revisa docenas de currículums realmente responde mejor a algo concreto que a una afirmación vaga. El problema es que mucho trabajo de ingeniería real nunca se registró de una forma que produzca un porcentaje limpio. Muchos equipos no llevan un panel de control para cada cambio, mucho impacto se percibe en lugar de medirse, y muchos ingenieros cambian de puesto antes de que nadie vuelva a comprobar si el cambio del trimestre pasado realmente ayudó. Ante ese vacío, el atajo tentador es escribir una cifra que suene razonable y esperar que nadie pregunte de dónde salió. Ese es exactamente el error que este artículo busca ayudarte a evitar, porque una cifra que un entrevistador puede desmontar con una sola pregunta hace más daño que no dar ninguna cifra.
Medidas honestas que existen incluso sin una métrica registrada
Existen varios tipos de detalles concretos para casi cualquier trabajo de ingeniería, se haya registrado o no una métrica sobre él. El alcance describe el tamaño de lo que tocaste: cuántos servicios abarcó un cambio, el tamaño de la base de código, cuántos endpoints o tablas se vieron afectados. La escala describe cuánto soportaba el sistema: cuántas solicitudes atendía, cuántos registros almacenaba, cuántos equipos construían sobre él, expresado en términos que puedes afirmar con seguridad en lugar de una cifra que estás adivinando. La frecuencia describe con qué regularidad se ejecutaba o se usaba algo: un trabajo por lotes que se ejecutaba cada noche, una canalización de despliegue que usaba cada ingeniero del equipo, un informe generado al cierre de cada trimestre. El estado antes y después describe qué era cierto antes de tu cambio y qué lo fue después, en lenguaje llano en lugar de un porcentaje: qué solía fallar, qué solía requerir un paso manual, qué solía necesitar a alguien de guardia, y qué dejó de ser cierto una vez que el trabajo se desplegó. Quién dependía de ello nombra al público real: el equipo que usaba la herramienta que construiste, el servicio que llamaba a la API que mantenías, la guardia que ya no recibía avisos por el problema que arreglaste. Cada uno de estos puntos es algo que realmente viviste y puedes describir de primera mano, y eso es precisamente lo que lo hace mucho más defendible que un porcentaje redondeado.
Ejemplo ilustrativo: una línea reescrita en torno al alcance en lugar de un porcentaje
Antes, vaga y sin cuantificar: "Responsable del rendimiento del servicio de pago." Después, reescrita en torno al alcance y a un estado antes/después descrito en lugar de una cifra inventada: "A cargo de la capa de consultas de base de datos del servicio de pago, el único camino por el que pasaba cada compra del sitio; antes de la reescritura, las consultas lentas eran la causa más habitual de un pago atascado que el equipo de soporte tenía que escalar, y tras el despliegue, esa categoría de queja dejó de aparecer en la revisión semanal." Nada en la versión reescrita es una estadística adivinada. Indica de qué se encargaba el candidato, cuán central era esa parte para el sistema, cómo era el problema antes y qué cambió después, todo a partir de algo que el candidato realmente presenció y no de una cifra reconstruida a posteriori.
Qué dejar fuera de la reescritura
La línea que hay que mantener está entre una cifra que hoy puedes señalar, de un panel, de un informe posterior a un incidente o de una métrica que realmente seguiste en su momento, y una cifra que reconstruyes a partir de un recuerdo vago del tipo "se sentía que las cosas iban mucho más rápido". La primera se puede citar directamente sin problema. La segunda es precisamente la que merece reescribirse con lenguaje de alcance y de antes/después en su lugar, porque una impresión recordada y redondeada a una cifra que suena bien es exactamente el tipo de afirmación que se desmorona ante una sola pregunta concreta en una entrevista. La versión basada en el alcance de arriba resiste esa pregunta, porque cada parte de ella es algo que puedes describir con tus propias palabras sin depender de una cifra que nunca registraste realmente.
Cómo encaja esto con el patrón más amplio de convertir tareas en logros
Reescribir en torno al alcance en lugar de una estadística inventada es una aplicación concreta de un cambio más amplio, que se aplica mucho más allá de la ingeniería: convertir una descripción de aquello de lo que eras responsable en una descripción de lo que realmente cambió como resultado. Convertir tareas en logros en tu currículum trata ese patrón de reescritura más amplio con ejemplos de puestos fuera de la ingeniería, para cualquiera cuyas líneas se lean hoy como una lista de tareas asignadas en lugar de resultados.
Redactar esta línea
Cómo escribir un currículum trata las decisiones de redacción que llevan este tipo de reescritura al resto del currículum, y la plantilla developer de CVBuilderKit está pensada precisamente para este tipo de entrada centrada en el alcance y el proyecto. Empieza desde un documento existente o desde uno en blanco en el creador y reescribe cada línea usando el alcance y un estado antes/después descrito antes de recurrir a una cifra que en realidad no puedes defender.