Cómo reclutar desarrolladores de software si no eres técnico

Reclutar desarrolladores de software puede ser difícil cuando reclutamiento no viene de tecnología. No porque el reclutador tenga que programar, sino porque muchas vacantes técnicas llegan con lenguaje ambiguo, listas largas de herramientas y poca claridad sobre lo que la persona realmente hará en el equipo.

El resultado suele ser un filtro débil: se buscan palabras clave, se descartan perfiles por no traer una tecnología exacta o se avanza a candidatos que suenan bien en el CV, pero no resuelven el problema del puesto.

La meta no es convertir al reclutador en ingeniero. La meta es darle una forma más clara de entender el rol, hacer mejores preguntas y evitar decisiones basadas solo en nombres de tecnologías.

Empieza por entender qué se va a construir

Antes de publicar o buscar candidatos, reclutamiento necesita una conversación breve pero concreta con el hiring manager. No basta con pedir “un backend senior con Node, AWS, PostgreSQL y microservicios”.

Preguntas útiles:

• ¿Qué problema va a resolver esta persona en los primeros tres meses?
• ¿Va a construir algo nuevo o mantener algo existente?
• ¿Trabajará sola o dentro de un equipo técnico?
• ¿Qué decisiones podrá tomar sin supervisión?
• ¿Qué parte del sistema es más crítica para este rol?
• ¿Qué tecnologías son obligatorias y cuáles se pueden aprender?

Estas preguntas cambian el filtro. No es lo mismo contratar a alguien para mantener un sistema estable que para rediseñar una arquitectura, migrar infraestructura o lanzar un producto desde cero.

Separa lenguaje, framework y experiencia real

Un error común es tratar todas las tecnologías como si pesaran igual.

No es lo mismo:

• lenguaje: JavaScript, Python, Java, Go, PHP
• framework: React, Vue, Django, Spring, Laravel
• base de datos: PostgreSQL, MySQL, MongoDB
• infraestructura: AWS, GCP, Azure, Docker, Kubernetes
• práctica de equipo: testing, code review, CI/CD, observabilidad

Un candidato puede no tener el framework exacto, pero sí tener experiencia fuerte en el tipo de problema. Por ejemplo, alguien con experiencia sólida en APIs, bases de datos y pruebas puede adaptarse de Express a FastAPI más rápido que una persona que solo ha usado una herramienta de forma superficial.

La pregunta correcta no siempre es “¿sabe esta tecnología?”. Muchas veces es: “¿ha resuelto problemas parecidos con herramientas comparables?”.

Define seniority por autonomía, no por años

En tecnología, los años ayudan, pero no explican todo. Un desarrollador con cuatro años en equipos exigentes puede tener más autonomía que alguien con ocho años haciendo tareas repetitivas.

Para filtrar mejor, define seniority con señales observables:

• junior: necesita guía frecuente y tareas bien definidas
• mid: puede resolver tareas completas con contexto claro
• senior: puede tomar decisiones técnicas, anticipar riesgos y guiar a otros
• lead: coordina diseño técnico, prioridades y calidad del equipo

Cuando el hiring manager pide “senior”, aclara qué espera. ¿Necesita alguien que programe rápido? ¿Que diseñe arquitectura? ¿Que mentoree? ¿Que hable con producto? ¿Que resuelva incidentes? Cada respuesta cambia el perfil.

No filtres solo por palabras clave

Las palabras clave ayudan a ordenar volumen, pero no deben decidir solas.

Un CV puede decir “microservicios, AWS, Docker, Kubernetes” y aun así no mostrar qué hizo la persona. Otro puede describir menos herramientas, pero explicar mejor responsabilidad, impacto y contexto.

Busca evidencia:

• qué parte del sistema construyó
• con qué escala trabajó
• qué decisiones tomó
• cómo colaboró con otros desarrolladores
• qué problemas corrigió
• qué aprendió al mantener código en producción

Ejemplo de mala señal: “participé en desarrollo de plataforma web”.

Ejemplo de mejor señal: “desarrollé APIs para pagos recurrentes, agregué pruebas automatizadas y reduje errores en conciliación”.

La segunda frase da contexto, responsabilidad y resultado. Eso vale más que una lista larga de herramientas.

Haz preguntas de screening que no requieran programar

El reclutador no necesita evaluar código. Pero sí puede hacer preguntas que separen experiencia real de discurso superficial.

Preguntas útiles para una llamada inicial:

• Cuéntame un proyecto reciente donde hayas construido una funcionalidad completa.
• ¿Qué parte hiciste tú directamente?
• ¿Con qué equipo colaborabas: producto, diseño, QA, operaciones?
• ¿Cómo revisaban código?
• ¿Qué pasaba cuando algo fallaba en producción?
• ¿Qué tipo de pruebas usaban?
• ¿Qué tecnología te costó aprender y cómo la resolviste?
• ¿Qué tipo de tareas prefieres evitar?

Las respuestas no tienen que ser perfectas. Lo importante es escuchar claridad, ownership y contexto. Un buen desarrollador normalmente puede explicar su trabajo sin esconderse detrás de términos técnicos.

Ajusta el mensaje de búsqueda

Los desarrolladores reciben muchos mensajes genéricos. Si el outreach dice “tenemos una excelente oportunidad para un programador full stack”, es fácil que no respondan.

Un mensaje más útil debe incluir:

• producto o tipo de problema
• stack principal
• modalidad de trabajo
• rango salarial si es posible
• nivel esperado
• por qué el rol puede ser interesante
• siguiente paso simple

Ejemplo:

Estamos buscando un desarrollador backend con experiencia en APIs y PostgreSQL para un producto B2B en crecimiento. El reto inicial es mejorar integraciones y estabilidad de servicios. Modalidad híbrida en Ciudad de México. Si te interesa, la primera llamada es de 20 minutos para revisar experiencia y expectativas.

No es un mensaje perfecto, pero es claro. Reduce fricción y evita perder tiempo con candidatos que no encajan.

Calibra con el equipo técnico antes de entrevistar a muchos

Antes de revisar 80 perfiles, toma 5 o 10 CVs y revísalos con el hiring manager. Pregunta:

• ¿Este perfil avanza o no?
• ¿Qué señal técnica te importa aquí?
• ¿Qué falta validar?
• ¿Qué requisito estamos sobrevalorando?
• ¿Qué perfil descarté que sí valía la pena?

Esta calibración evita que reclutamiento filtre con una interpretación distinta a la del equipo técnico. También ayuda a convertir criterios vagos en señales concretas.

Cuidado con la vacante imposible

Muchos procesos fallan desde la descripción del puesto. Se pide backend, frontend, cloud, mobile, data, seguridad, liderazgo y disponibilidad inmediata, todo en una sola persona.

Eso produce tres problemas:

• atrae candidatos que no encajan
• espanta candidatos buenos
• obliga a reclutamiento a buscar un perfil que casi no existe

Una vacante técnica debe separar lo crítico de lo deseable. Si todo es indispensable, nada está priorizado.

Cómo Reclu ayuda a resolver esto

Reclu ayuda a convertir vacantes técnicas en criterios más claros para filtrar y comparar candidatos. En lugar de depender solo de palabras clave, ayuda a ordenar la información del CV contra lo que el rol necesita: experiencia real, herramientas relevantes, señales de seniority, posibles dudas y nivel de ajuste.

Esto le da a reclutamiento una base más objetiva para conversar con el hiring manager y decidir a quién avanzar. El reclutador no tiene que saber programar para hacer un mejor primer filtro. Necesita estructura, contexto y evidencia.

Cierre

Reclutar desarrolladores de software no se resuelve memorizando tecnologías. Se resuelve entendiendo el problema del puesto, separando requisitos reales de deseos, preguntando mejor y documentando señales.

Para la siguiente vacante técnica:

• define qué se va a construir
• separa tecnologías obligatorias de aprendibles
• mide seniority por autonomía
• busca evidencia, no solo keywords
• calibra temprano con el hiring manager
• escribe mensajes de búsqueda concretos
• usa herramientas que ayuden a ordenar el criterio

Un buen proceso técnico no depende de que reclutamiento se vuelva experto en software. Depende de que el equipo traduzca mejor lo que necesita y filtre con menos ruido.