Cómo evaluar desarrolladores: guía técnica para CTOs y hiring managers

Contratar desarrolladores es la decisión más importante (y más difícil) de un CTO

En un mercado donde la demanda de talento IT sigue superando a la oferta, evaluar correctamente a candidatos técnicos es fundamental. Un mal hire no solo tiene un coste directo (salario, onboarding perdido) sino indirecto: código de baja calidad que acumula deuda técnica, ralentización del equipo, y potencial impacto en la retención de otros desarrolladores. Después de años construyendo equipos técnicos para startups y empresas, compartimos el framework que realmente funciona.

Más allá del CV: señales que importan

El CV de un desarrollador dice menos de lo que parece. Los años de experiencia no correlacionan linealmente con la competencia: un desarrollador con 3 años en proyectos exigentes puede superar a uno con 10 años haciendo lo mismo repetidamente. Las señales más fiables son: contribuciones a proyectos open source (demuestra iniciativa y capacidad de trabajar con código ajeno), calidad del portfolio o GitHub (no cantidad, sino cómo estructura el código), y la capacidad de explicar decisiones técnicas de proyectos anteriores con profundidad.

La entrevista técnica: estructura efectiva

La entrevista técnica ideal tiene tres fases: (1) Conversación técnica abierta (30 min) donde el candidato explica un proyecto complejo que haya liderado, las decisiones arquitectónicas que tomó y por qué. Esto revela pensamiento crítico y experiencia real. (2) Ejercicio práctico (60-90 min) con un problema real simplificado de tu dominio: no algoritmos de LeetCode, sino un mini-proyecto que refleje el trabajo diario. Evalúa estructura del código, manejo de edge cases, testing, y cómo comunica dudas. (3) Code review (30 min) donde el candidato revisa código con bugs intencionados. Esto muestra su ojo para la calidad y su capacidad de dar feedback constructivo.

Pruebas técnicas: qué funciona y qué no

Las pruebas de pizarra con algoritmos tipo LeetCode tienen una correlación débil con el rendimiento laboral real. Lo que sí funciona es un take-home project acotado (máximo 4 horas) que simule un escenario realista: implementar un API REST con tests, refactorizar un componente frontend, o diagnosticar un problema de rendimiento en una query SQL. Es importante que la prueba sea evaluada con una rúbrica objetiva: estructura del código, testing, manejo de errores, documentación inline, y uso de patrones apropiados. La rúbrica debe ser la misma para todos los candidatos.

Soft skills técnicas: el factor diferencial

Las soft skills más importantes en un desarrollador no son «trabajo en equipo» genérico, sino habilidades específicas del contexto técnico: capacidad de estimar tareas con precisión razonable, comunicar bloqueantes proactivamente, escribir PRs con descripciones claras, hacer code review constructivo, y documentar decisiones técnicas. Preguntas como «¿Cómo manejas una situación donde no estás de acuerdo con una decisión arquitectónica del equipo?» o «¿Cuál fue el último bug en producción que causaste y cómo lo resolviste?» revelan madurez profesional.

Red flags y green flags

Red flags: no puede explicar el «por qué» detrás de sus decisiones técnicas, habla solo de tecnologías y no de problemas resueltos, no muestra curiosidad por tu stack o producto, culpa a otros de los fracasos de proyecto. Green flags: hace preguntas inteligentes sobre tu arquitectura, admite lo que no sabe y explica cómo lo aprendería, muestra interés por el dominio de negocio además de la tecnología, y tiene opiniones formadas pero flexibles sobre herramientas y patrones.

Evaluar desarrolladores en la era de la IA (actualización julio 2026)

Desde que escribimos la primera versión de esta guía, el proceso de selección técnica ha cambiado más que en la década anterior. En 2026, gigantes como Google ya permiten usar asistentes de IA en parte de sus entrevistas técnicas, y empresas como Canva o Meta van en la misma dirección. El motivo es de sentido común: si el día a día de un desarrollador incluye trabajar con asistentes de código, evaluar a alguien prohibiéndole las herramientas que usará en el puesto mide una habilidad que ya no representa el trabajo real. De hecho, como contamos al analizar que cerca de la mitad de los desarrolladores ya programan con asistentes de código, la pregunta no es si el candidato usa IA, sino cómo la usa.

Esto no significa que todo valga. Recomendamos estructurar la evaluación con IA en tres niveles. Primero, transparencia: define desde el principio si la prueba permite IA y pide al candidato que documente los prompts que usa; cómo formula el problema a la máquina dice muchísimo de cómo piensa. Segundo, validación: lo diferencial ya no es generar código, sino detectar cuándo el código generado es incorrecto, inseguro o innecesariamente complejo. Un buen ejercicio es entregar una solución generada por IA con errores sutiles y pedir al candidato que la audite. Tercero, criterio arquitectónico: la IA acelera la escritura, pero las decisiones de diseño, los trade-offs y el contexto de negocio siguen siendo humanos. Las habilidades de IA que debería tener cualquier equipo técnico en 2026 son hoy parte del perfil a evaluar, al mismo nivel que el testing o el control de versiones.

Un formato que nos funciona especialmente bien es la sesión de pairing con IA permitida: 45 minutos, un problema real, y el candidato puede usar su asistente favorito. Observa si verifica lo que la IA propone, si escribe tests antes de aceptar el código, y si sabe cuándo dejar de iterar con la máquina y pensar por su cuenta. Los perfiles flojos aceptan la primera respuesta; los buenos la interrogan.

Cómo adaptar la evaluación según el seniority

Usar el mismo proceso para un junior y para un staff engineer es un error frecuente que genera falsos negativos en ambos extremos.

Perfiles junior

En un junior no evalúes conocimiento enciclopédico: evalúa capacidad y velocidad de aprendizaje. Funciona bien un ejercicio guiado donde el entrevistador va dando pistas y observa cómo las incorpora, si hace preguntas pertinentes y si razona en voz alta. Las bases (estructuras de datos elementales, control de versiones, nociones de HTTP) importan más que cualquier framework concreto, porque los frameworks cambian y las bases no. Un junior que entiende por qué funciona algo vale más que uno que ha memorizado diez recetas.

Perfiles mid-level

Aquí el foco es la autonomía: ¿puede coger una historia de usuario ambigua y convertirla en software funcionando sin supervisión constante? El take-home acotado es especialmente útil en este rango, complementado con preguntas sobre incidencias reales que haya resuelto. Busca experiencia genuina operando código en producción: deploys, rollbacks, debugging bajo presión.

Perfiles senior y staff

Con perfiles senior, el ejercicio de código pasa a segundo plano y gana peso la conversación de diseño de sistemas: cómo partiría un monolito, cómo diseñaría la capa de datos de un ecommerce con picos estacionales, qué haría ante un incidente de seguridad. También conviene evaluar el multiplicador de equipo: mentoring, calidad de sus code reviews, capacidad de decir que no a una mala idea con argumentos. Una referencia técnica de alguien que haya trabajado con esa persona vale más que cualquier prueba de pizarra.

El proceso completo: del screening a la oferta

La estructura de entrevista de tres fases que describimos arriba necesita un proceso alrededor para funcionar. El embudo que recomendamos a nuestros clientes tiene cinco pasos: screening de CV con criterios escritos (30 minutos por lote, no por candidato), llamada breve de 20 minutos para validar expectativas y comunicación, la entrevista técnica de tres fases, una conversación con el equipo con el que trabajará, y decisión con rúbrica compartida en un plazo máximo de 48 horas.

La velocidad es parte de la experiencia de candidato: los buenos perfiles están en varios procesos a la vez, y cada semana extra de indecisión reduce la probabilidad de cierre. Todo el proceso, desde el primer contacto hasta la oferta, no debería superar las tres semanas. Otro punto crítico es que todos los entrevistadores usen la misma rúbrica y puntúen por separado antes de debatir: evita el efecto arrastre del primero que opina y hace comparables a candidatos entrevistados por personas distintas.

Cuánto cuesta un mal hire y cómo reducir el riesgo

Diversos estudios sitúan el coste de una mala contratación técnica entre el 30% y el 150% del salario anual del puesto, según el seniority y el tiempo que se tarde en detectarla. A ese coste directo (salario, seguridad social, herramientas, tiempo de onboarding) hay que sumarle el indirecto, que suele ser mayor: deuda técnica que otros tendrán que pagar, ralentización del equipo que lo acompaña y, en el peor de los casos, la marcha de un buen desarrollador quemado por compensar el déficit. Lo vimos de cerca al repasar los errores técnicos que cometen las startups al pasar del MVP al producto escalable: buena parte nacen de decisiones tomadas por perfiles contratados sin la evaluación adecuada.

Para reducir el riesgo: usa el periodo de prueba de forma honesta, con objetivos escritos a 30, 60 y 90 días y feedback quincenal; pide referencias hablando tú directamente con antiguos responsables (dos llamadas de diez minutos detectan más problemas que cualquier test); y si la posición es crítica, plantea una colaboración freelance corta antes del contrato indefinido cuando sea viable.

¿Contratar in-house, freelance o partner tecnológico?

Evaluar bien también implica saber cuándo no contratar. Montar un proceso de selección serio como el descrito consume decenas de horas de las personas más caras de la empresa, y tiene sentido cuando construyes un equipo estable alrededor de tu producto. Pero si la necesidad es un proyecto acotado, un pico de trabajo o una especialidad que no forma parte de tu core (una migración, una auditoría, un desarrollo concreto), la alternativa de trabajar con un partner tecnológico con equipo ya formado y evaluado suele salir más barata que un proceso de contratación fallido.

La ventaja de un partner no es solo la velocidad de arranque: es que la evaluación ya está hecha. Un buen proveedor responde con hechos a las mismas preguntas que harías a un candidato: cómo documenta, cómo testea, cómo gestiona incidencias. Exige ver ejemplos reales de su forma de trabajar, igual que pedirías el GitHub a un candidato: una documentación funcional bien hecha distingue a un equipo profesional de uno que improvisa. Y si dudas entre ampliar plantilla o externalizar, haz números con el coste total: salario, seguridad social, herramientas, gestión y el riesgo de rotación.

No evalúes solo código: seguridad y buenas prácticas

Un ángulo que casi ningún proceso de selección cubre y que cada vez pesa más: la cultura de seguridad del candidato. Pregunta cómo gestiona secretos y credenciales en sus proyectos, qué hace ante una dependencia con vulnerabilidad conocida, o cómo evitaría una inyección SQL en el código del ejercicio. No busca respuestas de manual, sino reflejos. Si tu empresa está certificada o en camino de certificarse en ISO 27001, cada persona que toca código forma parte del alcance del sistema de gestión: contratar a alguien sin higiene de seguridad es incorporar un riesgo directamente a tu SGSI. Incluir dos o tres preguntas de seguridad en la rúbrica cuesta poco y filtra mucho.

Cómo construir la rúbrica de evaluación

Hemos mencionado varias veces la rúbrica y merece sección propia, porque es la herramienta que convierte impresiones subjetivas en decisiones comparables. Una rúbrica útil tiene entre seis y diez criterios, cada uno con una escala de 1 a 4 y descripciones concretas de qué significa cada nivel. Para un perfil backend mid-level, por ejemplo: calidad y estructura del código, testing, manejo de errores, diseño de datos, comunicación técnica, uso y validación de IA, reflejos de seguridad y encaje con la forma de trabajar del equipo.

Tres reglas hacen que funcione. Primera: las descripciones de nivel se escriben antes de ver al primer candidato, no después; si defines qué es un 4 en testing cuando ya tienes un favorito, la rúbrica solo sirve para justificarlo. Segunda: cada entrevistador puntúa en solitario inmediatamente después de la entrevista y las notas se comparten a la vez; el orden en que la gente habla en una reunión no debería decidir una contratación. Tercera: la rúbrica se revisa cada pocos procesos con datos reales, comparando las puntuaciones de entrada con el rendimiento a los seis meses; los criterios que no predicen nada se quitan y dejan sitio a los que sí.

Un beneficio lateral poco valorado: la rúbrica también protege al candidato. Permite dar feedback concreto a quien no pasa el proceso (algo que cuida tu marca empleadora), y reduce el sesgo de afinidad, ese que hace que contratemos a gente que se nos parece en lugar de a gente que complementa al equipo. Si además documentas cada proceso, tendrás un histórico que mejora la calidad de tus decisiones con cada nueva incorporación.

Preguntas frecuentes

¿Debo permitir usar IA en la prueba técnica?

Sí, con reglas claras. Prohibirla mide una situación irreal y penaliza a quienes mejor trabajan con las herramientas actuales. Lo importante es pedir transparencia sobre su uso y evaluar la capacidad de validar lo generado, no la pureza del tecleo.

¿Cuánto debe durar un take-home project?

Máximo 4 horas de trabajo real. Más allá de eso, los mejores candidatos (que suelen tener trabajo y varios procesos abiertos) simplemente lo abandonan, y te quedas seleccionando entre quienes más tiempo libre tienen, no entre los mejores.

¿Sirven las certificaciones para evaluar a un desarrollador?

Como señal complementaria, sí; como criterio principal, no. Una certificación demuestra constancia y conocimiento teórico, pero no cómo escribe código en un proyecto real con plazos. Pesa siempre más un ejercicio práctico bien evaluado.

¿Qué hago si necesito cubrir la posición ya y el proceso va lento?

No bajes el listón: un mal hire por prisa cuesta más que la vacante abierta. Cubre el hueco con refuerzo externo temporal mientras mantienes el proceso de selección con calma, y convierte solo si el nivel es el adecuado.

¿Quién debe hacer la entrevista técnica si el CEO no es técnico?

Nunca la persona de recursos humanos a solas. Si no hay nadie técnico en plantilla, apóyate en un asesor externo de confianza para las fases técnicas: el coste de un par de horas de un CTO externo es marginal comparado con el coste de equivocarse.

Conclusión

Evaluar desarrolladores bien no es cuestión de trucos ni de acertijos: es un proceso estructurado, con fases claras, rúbricas compartidas y señales objetivas, adaptado al seniority del puesto y actualizado a una realidad donde la IA forma parte del trabajo diario. El CV importa menos que nunca; la capacidad de razonar, validar y comunicar importa más que nunca. Y cuando la mejor decisión no sea contratar, sino apoyarse en un equipo ya formado, tenerlo claro a tiempo también es una forma de acertar. Si estás construyendo o reforzando tu equipo técnico y quieres una segunda opinión experta, en Keliam llevamos años evaluando y formando desarrolladores para proyectos propios y de clientes.