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.
