Cómo leer un CV de programador si no eres técnico

Un currículum de desarrollador está diseñado, sin querer, para despistar a quien no programa. Trae una lista de veinte tecnologías, unos cuantos nombres de empresa y frases que suenan idénticas en el candidato excelente y en el mediocre. La reacción natural es buscar en el texto las palabras del anuncio y descartar al resto. Es exactamente lo que produce las peores contrataciones. Esta guía explica qué mirar en su lugar, sin necesidad de saber programar.

La lista de tecnologías es la parte menos informativa

Casi todos los CV técnicos abren con un bloque de veinte o treinta nombres: lenguajes, librerías, bases de datos, herramientas. Ese bloque casi nunca miente, pero tampoco dice nada útil, porque no distingue entre haber usado algo tres años en producción y haberlo tocado un fin de semana en un tutorial. Un candidato honesto y uno que infla escriben la misma lista.

La señal real no está en la lista, está en el cuerpo. Si alguien pone Kubernetes arriba, busca dónde aparece Kubernetes en la descripción de un trabajo concreto y qué hizo con ello. Si solo aparece en la lista y en ningún sitio más, es conocimiento de superficie. Esta comprobación —contrastar cada tecnología clave contra una experiencia concreta— es la que más ruido elimina y no exige saber para qué sirve la tecnología.

Seis años de experiencia o un año repetido seis veces

Es la distinción que más dinero decide y la más fácil de ver una vez sabes mirarla. Recorre los puestos en orden cronológico y pregúntate si lo que hace la persona cambia de tamaño. Un desarrollador que crece pasa de tocar una parte a diseñar un sistema, de trabajar solo a coordinar a otros, de recibir el problema resuelto a decidir cómo resolverlo. Si los tres últimos puestos describen la misma tarea con distinto logotipo al lado, tienes un año de experiencia repetido tres veces.

Ojo con juzgar los cambios de empresa por la vara de otros sectores. En tecnología, estancias de dos a tres años son normales y no son una señal de alarma. Lo que sí merece una pregunta es la estancia de menos de un año repetida varias veces seguidas, o el salto lateral constante sin que crezca la responsabilidad.

Las cinco señales que sí valen

• Números concretos. "Reduje el tiempo de carga de ocho segundos a menos de dos" o "pasamos de un despliegue al mes a varios al día" son afirmaciones que alguien puede desmentir, y por eso quien las escribe suele haberlas vivido. Las frases sin cifra no significan nada.
• Producto real que puedes abrir. Una app publicada, un repositorio público, un sitio que carga. Que puedas verlo con tus propios ojos vale más que cualquier descripción.
• Continuidad. Haber mantenido algo durante años, no solo haberlo lanzado. Construir es la parte fácil; lo que enseña de verdad es convivir con lo que construiste.
• El porqué de una decisión. Un CV que dice "migramos a X porque Y se nos quedó corto con el crecimiento" muestra criterio. Uno que solo enumera tecnologías, no.
• Rastro público. Charlas, artículos, contribuciones a proyectos abiertos, respuestas en comunidades. No es obligatorio y hay grandes profesionales sin nada de esto, pero cuando está, es verificable.

Lo que la gente descarta por error

Hay tres motivos de descarte muy comunes que tiran a la basura buenos candidatos. El primero es que falte una tecnología concreta del anuncio: alguien con cinco años en un lenguaje similar aprende el tuyo en semanas, y ese requisito filtra por vocabulario, no por capacidad. El segundo es el título universitario: en desarrollo es un indicador flojo, y una parte considerable de los buenos perfiles viene de bootcamps o es autodidacta. El tercero es el CV feo. Muchos desarrolladores excelentes escriben currículums mediocres porque casi nunca los necesitan; el diseño del documento no te dice nada sobre la calidad de su trabajo.

Si descartas por una palabra que falta, estás filtrando por vocabulario, no por capacidad.

Las dos preguntas que convierten el CV en información

Ningún currículum se sostiene solo. Con dos preguntas en la primera llamada averiguas más que releyéndolo diez veces. La primera: pide que te explique un proyecto suyo sin usar nombres de herramientas —qué problema había, qué decidió y qué salió mal. Quien ha construido algo lo cuenta en lenguaje llano y admite la parte que falló sin que se lo pidas. Quien pasó de largo se refugia en siglas y en el nombre de la empresa donde estuvo.

La segunda: qué haría si algo se rompe un viernes por la tarde con clientes esperando. La respuesta separa a quien ha estado en producción de verdad de quien solo ha trabajado en entornos de prueba, y no necesitas ser técnico para notar la diferencia en cómo lo cuenta. Estas dos preguntas son la base de cualquier proceso de selección con evaluación técnica que funcione.

Y el sueldo, para calibrar

Un CV se lee distinto según lo que puedas pagar. Si tu banda está por debajo del mercado remoto en dólares, los perfiles que te van a responder son otros, y conviene saberlo antes de descartar a nadie por exigente. Los rangos por país y por seniority, con la diferencia entre mercado local y empresa extranjera, están en cuánto gana un desarrollador en LATAM.

Si esto es tu trabajo todos los días

Leer CV técnicos es una habilidad que se aprende y casi nadie la enseña en español. Estamos preparando un curso de reclutamiento IT que cubre esto en detalle: qué hace cada perfil de verdad, cómo leer el currículum, dónde buscar candidatos, cómo entrevistar sin ser técnico y cómo cerrar la oferta. Todavía no está a la venta, y quien esté en la lista entra primero y con precio de lanzamiento — apúntate aquí. Si prefieres delegar la criba entera, eso es lo que hacemos en reclutamiento IT.