Red flags al contratar programadores: señales de alarma en CV y entrevista

Una mala contratación técnica no se nota el primer día: se nota tres meses después, cuando el proyecto va tarde y el equipo ha perdido confianza. La buena noticia es que la mayoría de esas contrataciones fallidas dejaban señales claras mucho antes de la oferta. Saber detectar red flags al contratar programadores te ahorra tiempo, dinero y algún que otro disgusto. Esta guía recoge las señales de alarma más habituales en el CV, en la entrevista y en la prueba técnica, y qué hacer cuando aparecen.

1. Red flags en el CV

El currículum es el primer filtro y ya contiene mucha información si sabes leerlo:

• Cambios de empresa constantes sin progresión. Saltar de trabajo no es malo en tecnología; lo revelador es hacerlo siempre al mismo nivel, sin crecer en responsabilidad ni en tipo de proyecto.
• Listas infinitas de tecnologías. Un CV con veinte lenguajes y frameworks suele esconder conocimiento superficial. Un buen candidato destaca lo que domina, no todo lo que ha tocado.
• Experiencias sin resultados. "Trabajé en el desarrollo de una app" no dice nada. "Reduje el tiempo de carga un 40%" o "mantuve el servicio de pagos de 200.000 usuarios" sí. La ausencia de números suele significar que no hay impacto que contar.
• Descuido en la forma. Faltas de ortografía, fechas que no cuadran o un PDF desordenado en alguien que se dedica a escribir código preciso son una señal de falta de atención al detalle.
• Perfil público que no respalda el discurso. Si el candidato presume de proyectos personales o open source, su GitHub debería mostrarlo. Un enlace vacío o abandonado desde hace años resta credibilidad.

2. Red flags en la entrevista

La entrevista confirma o desmiente lo que prometía el CV. Estate atento a estas señales:

• La culpa siempre es de otros. Si en cada experiencia anterior el problema fue la empresa, el jefe o los compañeros, el denominador común es el candidato. Las personas sólidas también cuentan qué harían distinto.
• "Utilizamos" en lugar de "hice". Cuando todo se narra en plural y nunca puede concretar qué parte construyó él, es posible que su contribución real fuera menor de la que sugiere el CV.
• Respuestas técnicas que se evaporan. Rodeos, generalidades o cambios de tema ante preguntas concretas de su supuesta especialidad indican que el conocimiento no es profundo.
• Contradicciones con el currículum. Fechas, tecnologías o responsabilidades que cambian entre el papel y la conversación son una alarma directa.
• Cero preguntas sobre el proyecto. Un programador con criterio quiere saber cómo es el código, el equipo y los procesos a los que se incorpora. El desinterés total suele repetirse después en el trabajo.

Matiz importante: que un candidato pregunte por salario, horario o teletrabajo no es una red flag; es una conversación sana. La señal de alarma es que las condiciones sean lo único que le interesa durante todo el proceso.

3. Red flags en la prueba técnica

La prueba técnica es el detector definitivo, porque el código no discursa. Presta atención a estos comportamientos:

• No sabe explicar su propio código. Si entrega una solución que no puede razonar línea a línea, probablemente no la escribió él o la generó sin entenderla.
• Retrasos constantes con excusas. Pedir más tiempo una vez es razonable; convertir una prueba de una semana en un mes anticipa cómo gestionará los plazos en el puesto.
• Copia literal de soluciones públicas. Encontrar el mismo código en un repositorio o foro, sin adaptación ni comprensión, descarta al candidato por sí solo.

4. Una red flag no es un descarte automático

Ninguna señal aislada debería decidir sola. Las personas cambian de trabajo por mil motivos, los nervios juegan malas pasadas y un CV poco pulido no siempre esconde a un mal profesional. La regla práctica es verificar: si algo te hace ruido, pregunta directamente y dale al candidato la oportunidad de explicarlo. Una sola red flag explica; dos o tres acumuladas suelen confirmar.

El atajo: valida antes de entrevistar

Detectar estas señales exige tiempo y, sobre todo, criterio técnico. Si no tienes en tu equipo a alguien que pueda evaluar a un programador con garantías, externalizar la selección te lo resuelve: recibes solo candidatos ya validados, con el nivel técnico comprobado y las red flags descartadas antes de llegar a tu mesa.