Reconstruimos nuestro propio proceso de contratación con IA
Les decimos a los clientes que empiecen por ese proceso interno aburrido que pueden medir. Este es el nuestro.
Reclutamos ingenieros sénior a gran escala, y dos etapas de esa operación dependían del escaso tiempo disponible de especialistas: evaluar si un candidato es realmente tan bueno como dice su currículum y convertir a un candidato calificado en un perfil que un cliente quiera leer. Ambas eran lentas y costosas, y empeoraban a medida que crecíamos. Las rediseñamos en torno a la IA. Esto es lo que hay dentro.
Primera etapa: el entrevistador limitaba la evaluación
La evaluación técnica inicial requería reclutadores con suficiente conocimiento de ingeniería para evaluar a desarrolladores experimentados en varias tecnologías. Es un perfil de contratación muy específico, e incluso un buen profesional tiene límites: alguien que domina Python y Django termina evaluando a un ingeniero sénior de Node, y una conversación que empieza en Python pasa a infraestructura en la nube, bases de datos, seguridad y sistemas distribuidos.
El problema más grave era más sutil. Cuando un candidato conocía una tecnología mejor que el entrevistador, este no podía distinguir con fiabilidad entre un conocimiento profundo real y una respuesta que simplemente sonaba correcta. Por eso, la profundidad de una evaluación dependía en parte de quién la realizaba.
Además, había un límite estricto: unas seis entrevistas técnicas por reclutador al día, con dos agendas que coordinar para cada una.
Qué construimos en su lugar
No automatizamos la entrevista. Nos preguntamos para qué servía.
Para los ingenieros sénior, la pregunta útil no es si pueden resolver un ejercicio aislado. Es cómo piensan: cómo abordan la incertidumbre, qué alternativas consideran, si pueden identificar ventajas y limitaciones, por qué eligen una arquitectura en lugar de otra y qué hacen cuando una solución introduce una nueva restricción. Los desafíos de programación no responden nada de eso y les piden a candidatos experimentados que pasen horas escribiendo código al principio de un proceso con el que todavía no se han comprometido.
Por eso construimos una evaluación conversacional. El candidato recibe una situación técnica y explica, con sus propias palabras, cómo la abordaría. No hay un cuestionario fijo: el sistema lee cada respuesta y decide cómo continuar. Si una conversación empieza en Python y llega a una arquitectura en la nube, se puede profundizar en esa arquitectura; si el diseño depende de una estrategia de bases de datos, la conversación pasa al diseño, el rendimiento y la consistencia. Sigue el razonamiento del propio candidato entre distintas áreas, que es la forma de distinguir la familiaridad teórica de la experiencia práctica, y elimina la exigencia de que un entrevistador domine personalmente cada tecnología que pueda surgir.
Como resultado, cambiaron dos cosas. Las evaluaciones se realizan bajo demanda y en paralelo, de modo que los candidatos eligen un momento en el que están preparados en lugar de coordinar agendas, y la capacidad de evaluación deja de depender de la cantidad de personas del equipo. Además, cuando se postulan cientos de personas, ya no tenemos que elegir quién consigue uno de los escasos espacios de entrevista basándonos principalmente en un currículum: podemos evaluar a todos los candidatos y tomar la siguiente decisión con evidencia técnica.
El resultado es estructurado, en lugar de anecdótico: el conocimiento profundo demostrado, el nivel de experiencia correspondiente y la posición del candidato en relación con todos los demás que hemos evaluado. El inglés hablado se evalúa a partir de la misma conversación. Ambos resultados aparecen en la vista del reclutador junto al perfil, como información que lee una persona.
Segunda etapa: el perfil que llevaba seis horas
Todavía había que presentar a los candidatos calificados a los clientes en nuestro formato estándar: experiencia, responsabilidades, tecnologías y participación real en cada proyecto. Teníamos un equipo dedicado a redactar esos perfiles.
Nunca se trató solo de escribir. Para representar a un ingeniero sénior con precisión, tienes que entender cómo se usó cada tecnología en cada proyecto, qué implementó personalmente el candidato frente a lo que entregó su equipo y qué detalles le importarán realmente al cliente. Sin ese contexto técnico, se omiten cosas, se simplifican o se exageran sin que resulte evidente. Cada perfil llevaba de cuatro a seis horas; preparar un grupo completo de candidatos para un cliente llevaba de dos a tres días.
El agente toma la transcripción y extrae un esquema fijo: las tecnologías de cada puesto y el verbo asociado a cada una —construyó, mantuvo, evaluó, migró—; el trabajo que el candidato implementó personalmente, separado de lo que entregó el equipo; su rol y su nivel real de participación; los detalles técnicos relevantes para presentarlo. Luego redacta el perfil en nuestro formato. No es un resumen de la entrevista, sino un documento con una función: hacer comprensible el perfil de un ingeniero sénior para alguien que decide en cinco minutos si quiere conocerlo.
La parte difícil fueron los pronombres. Las entrevistas se cuentan en «nosotros». Un perfil tiene que ser honesto sobre el «yo». Un modelo al que le pides un resumen convierte sin problema «migramos el servicio de pagos» en una afirmación de que el candidato migró el servicio de pagos. Conseguir que examine cada frase para atribuirla correctamente y que descarte una afirmación cuando la transcripción no la respalda fue la mayor parte del desarrollo. Esa es la diferencia entre un perfil en el que el cliente confía y uno que apenas hojea.
De cuatro a seis horas se convirtieron en cinco a diez minutos. Un grupo de candidatos que llevaba de dos a tres días está listo en menos de dos.
Cómo nos ganamos la autonomía
No lo encendimos y nos fuimos.
Durante las primeras tres semanas, la operación pasó de tres redactores a un revisor, cuyo trabajo era validar cada perfil generado y señalar errores, omisiones, inconsistencias y casos límite. Cada corrección se convirtió en una regla: cómo tratar un proyecto descrito solo en plural, qué hacer con una tecnología mencionada una vez de pasada y cuándo «lideró» significa liderar y cuándo significa participar.
Durante las siguientes tres a cuatro semanas, iteramos a partir de los comentarios de producción. A medida que las correcciones se acercaron a cero, la etapa de revisión dedicada dejó de ser necesaria. Tres redactores → un revisor → ningún operador dedicado, en unas siete semanas.
Las reglas que habíamos escrito de antemano se equivocaban en gran medida sobre dónde estarían los problemas. La etapa de revisión no era una carga adicional. Fue la forma de construir el sistema.
Las cifras
La producción de perfiles pasó de cuatro a seis horas a cinco a diez minutos. El volumen pasó de unos 90 perfiles al mes a unos 890: la misma operación, con un orden de magnitud más de candidatos presentados. En la evaluación, la restricción que desapareció es más difícil de expresar en una sola cifra: la capacidad de evaluación ya no depende de cuántos reclutadores técnicos tenemos, cuándo están disponibles o qué tecnologías conocen.
La cuestión no era automatizar dos tareas. Era que la calidad dejara de depender de la persona que realizara cada etapa: ahora se aplica el mismo estándar a todos los candidatos y se mantiene a medida que crece el volumen.
Qué le diríamos a cualquiera que esté haciendo esto
Pregúntate para qué sirve la etapa antes de automatizarla. Podríamos haber construido una versión más rápida de la entrevista que ya hacíamos. La entrevista que realmente necesitábamos era otra.
La calidad de la transcripción marca el límite. Todo lo que viene después —el perfil, el nivel de experiencia y el nivel de inglés— hereda los errores de la transcripción. Dedicamos más tiempo a eso que a elegir cualquier modelo.
Deja que las correcciones definan las reglas. No tus suposiciones. Un revisor que señale problemas en resultados reales durante unas semanas te enseñará más sobre los casos límite que cualquier cantidad de trabajo de diseño.
Mide la unidad. Horas por perfil. Entrevistas por día. No «productividad».
Construimos esto para nosotros antes de construir algo parecido para otra empresa, y es el mismo patrón que ahora aplicamos dentro de las operaciones de otras compañías: encontrar dónde la disponibilidad de especialistas, el conocimiento escaso o los traspasos manuales limitan el negocio y rediseñar esa parte en torno a lo que los modelos realmente hacen bien.