Cloud Intelligence™
Nuestros reclutadores ahora lanzan software
Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.
About Vadim Solovey
Founded DoiT in 2011 and have been here ever since — in every flavor of CTO, co-CEO, and now CEO. I started my career in 1999 building data centers before anyone called it "the cloud," and I've spent the two decades since trying to deliver on what the cloud was actually supposed to be. I still write code most weeks.
My personal pageHace un año, careers.doit.com era una página de HubSpot con filtros que no funcionaban. Si hacías clic en la categoría "Customer Experience", veías quizás un tercio de las vacantes abiertas, porque los puestos en Greenhouse se etiquetan con departamentos hijos y el sitio nunca recorría la jerarquía. Los candidatos se postulaban a través de un iframe incrustado que parecía diseñado en 2014, porque así era.
Hoy, el mismo equipo que antes abría tickets sobre esa página tiene a su cargo una aplicación Next.js en producción que corre en Google Cloud Run. Sirve el sitio público de empleo y, detrás de un login, ejecuta un generador de descripciones de puesto con IA, una herramienta de sourcing de candidatos, un evaluador de postulaciones, un flujo de revisión de compensaciones con aprobaciones, un editor de blog para historias de empleados y un bot de Slack que anuncia las nuevas vacantes. El equipo de Talent Acquisition no contrató una agencia. No esperó en el backlog de ingeniería. Lo construyó, con un engineer y mucho Claude.
Quiero compartir cómo funciona esto, porque creo que el modelo es repetible y la mayoría de las empresas lo está complicando de más.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
El Applied AI engineer
El núcleo de todo es un rol que llamamos Applied AI engineer. Es un ingeniero de software cuyo trabajo de tiempo completo es estar integrado dentro de un equipo de negocio. No un consultor que toma requerimientos y desaparece por un trimestre, ni un equipo de plataforma que construye "AI enablement" para todos y para nadie. Un engineer, un equipo (nuestro equipo de People Ops, en este caso), sentado en sus reuniones, padeciendo sus mismas frustraciones.
Nuestro equipo de Talent Acquisition, que forma parte de la organización de People, recibió uno. El mandato del engineer era simple: automatizar lo aburrido, construir lo que falta y enseñar al equipo a hacer cada vez más por su cuenta.
Esa última parte es la más importante. Medimos al engineer por cuánto puede lanzar el equipo sin él, no por su propia producción.
Las especificaciones resultaron ser el verdadero trabajo
La reconstrucción del sitio de empleo empezó con un documento, no con código. Escribimos una larga especificación en markdown que lo describía todo: la jerarquía de departamentos de Greenhouse y exactamente cómo los filtros debían recorrerla, los campos del formulario de postulación, las redirecciones desde las URLs antiguas, el estándar de accesibilidad, e incluso los errores del sitio anterior que no debían repetirse. Ese archivo entró al repositorio como CLAUDE.md, y Claude Code construyó el sitio a partir de él.
Lo que no esperaba era que los reclutadores pudieran leer la especificación. La corrigieron. "La entrevista con el reclutador dura 30 minutos, no 45." "Los puestos se etiquetan con el departamento hijo, por eso se rompen los filtros." El conocimiento del dominio que normalmente se perdería en un teléfono descompuesto entre un PM y un contratista fue directo a la fuente de verdad.
Ahora escribimos una especificación así para cada herramienta interna. La del JD Builder tiene unas diez páginas e incluye los prompts exactos, la rúbrica de evaluación y las preguntas abiertas para los stakeholders. Escribirla tomó días. La herramienta funcional tomó menos tiempo que la especificación. Esa proporción todavía me resulta extraña, y ya dejé de esperar que se invierta.
Lo que realmente construyeron
El sitio público es la parte visible: un formulario de postulación personalizado que habla directamente con la API de Greenhouse, un mapa de contrataciones, alertas de vacantes, SEO y AEO como corresponde, y un correo de confirmación con nuestra marca en el momento en que te postulas. Se ve bien, pero es lo mínimo indispensable.
Las herramientas internas son las que de verdad cambiaron la semana del equipo:
JD Builder. Cualquier persona en DoiT puede generar o reescribir una descripción de puesto. La IA la escribe con nuestra voz y, mientras editas, también vuelve a calificar el borrador aproximadamente cada segundo en cinco dimensiones: inclusión, tono, exhaustividad, legibilidad y si un candidato fuerte realmente dejaría de hacer scroll. Importa una vacante abierta desde Greenhouse, corrígela y súbela de nuevo. La meta que nos pusimos: pasar de "necesito una JD" a publicada en menos de 15 minutos, con un puntaje de inclusión de 85 o más. Los hiring managers dejaron de mandar borradores a TA para que los reescribieran. Se autogestionan.
Nuestro sistema interno de creación de descripciones de puesto
Candidate Sourcing. Un reclutador elige una vacante abierta y la herramienta lee la descripción del puesto, hace que la IA escriba una consulta de búsqueda junto con criterios de verificación, y se los entrega a una API de investigación web que encuentra alrededor de 250 personas compatibles y consigue sus correos profesionales. Los criterios codifican lo que hemos aprendido sobre quién prospera aquí, como los candidatos que vienen de empresas que venden a equipos de plataforma y DevOps. El contacto se hace desde la misma pantalla, por LinkedIn y correo, con leads destacados, notas y seguimiento de contactos. Los sourcers dejaron de hacer malabares con pestañas del navegador y hojas de cálculo.
Interfaz de sourcing de candidatos
Candidate Screener. El volumen es donde la contratación supera a los humanos, así que esta es la herramienta que más importa. Una vacante reciente atrajo unas 2,200 postulaciones; los propios filtros de Greenhouse la bajaron a aproximadamente 1,100 candidatos activos. El screener extrajo de Greenhouse el currículum, las respuestas de screening y el perfil de cada uno, y la IA los calificó frente a ocho rasgos universales más los requisitos específicos del puesto. Cada candidato recibe una evaluación escrita, y digo cada uno: un resumen, fortalezas con evidencia citada del currículum, dudas que vale la pena explorar en una entrevista y puntajes por rasgo, con un enlace a su perfil de Greenhouse. Fijamos el umbral en 96 y terminamos con 61 candidatos fuertes. Esa es una shortlist que un equipo de contratación sí puede sentarse a revisar en conjunto, y exportar a CSV cuando lo haga. ¿El puesto en el que lo probamos? Nuestro próximo Applied AI engineer. Nos pareció apropiado.
Evaluación de candidatos con un clasificador de IA
Comp Review. Cuando un Doer se postula a una vacante interna en Greenhouse, un webhook construye el borrador de la revisión de compensación antes de que alguien lo pida: salario actual, bono, equity e historial de promociones desde la API de Rippling (nuestro sistema de RR. HH.), más un rango salarial calculado a partir de pares en el mismo rol y región. Luego notifica por Slack al reclutador, al manager, al skip-level, al HRBP y al jefe del departamento. Lo que antes era una semana de arqueología en hojas de cálculo y de perseguir correos ahora es un flujo de aprobación con recordatorios.
Sistema de revisión de compensaciones
Anuncios en Slack. Las nuevas vacantes se publican en Slack en cuanto se abren, con el reclutador y el hiring manager etiquetados y la fecha límite para postulaciones internas incluida. Los Doers se enteran de inmediato de las nuevas vacantes y pueden considerar la movilidad interna si encaja con sus aspiraciones profesionales.
Notificaciones internas en Slack
Ninguna de estas herramientas habría pasado el filtro para entrar al roadmap de ingeniería. Juntas cambiaron la forma en que opera el equipo.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
La parte que merece cautela
El screening es el terreno con mayores consecuencias al que hemos apuntado con la IA, y quiero ser honesto sobre ambas caras.
El argumento a favor es fuerte. El screener lee al candidato número 1,100 con la misma atención y los mismos criterios que al candidato número 1. Los humanos no podemos hacer eso. Nos cansamos, nos anclamos en el último currículum que leímos y, a media tarde, estamos detectando patrones en las cosas equivocadas. Una persona enterrada en la posición 900 de la pila recibe de la máquina una lectura justa que nunca iba a recibir de un revisor agotado. Soy un firme defensor de la IA exactamente en este punto.
Pero la IA carga con sus propios sesgos, y un sesgo consistente aplicado a 1,100 personas a la vez es un tipo de problema distinto al de un humano inconsistente. Por eso el screener produce una shortlist y una lista de dudas por explorar; las personas toman todas las decisiones a partir de ahí. Y antes de que esto pase de experimento a herramienta interna establecida, nos debemos una conversación abierta sobre equidad, transparencia y salvaguardas. Estamos teniendo esa conversación ahora, en voz alta, y animaría a cualquier empresa que haga esto a tenerla antes de que la herramienta funcione tan bien que nadie quiera tenerla.
Lo que le diría a otro CEO
Empieza por algo roto, no por una estrategia de IA. No nos propusimos "adoptar IA en RR. HH.". Nos propusimos arreglar un sitio de empleo con filtros rotos. El resto se fue acumulando desde ahí, una molestia a la vez.
Un solo repositorio, infraestructura compartida. Cada herramienta vive en el repositorio del sitio de empleo y reutiliza la misma integración con Greenhouse y Rippling y la misma autenticación. La segunda herramienta tomó una fracción del esfuerzo de la primera. La quinta salió casi gratis.
Los no ingenieros revisan resultados, no código. Nuestros reclutadores no saben leer TypeScript y no lo necesitan. Pueden decirte en segundos si una JD generada suena como nosotros, y el dashboard de calidad les da un lenguaje común para señalar lo que está mal. Confía en el experto del dominio para juzgar el resultado; deja que el agente y el engineer se preocupen por el diff.
Los costos son aburridos. Un modelo rápido y barato para la calificación en tiempo real, un modelo potente para la generación, un contenedor que escala a cero cuando nadie está contratando a las 3 a. m. No es un gasto grande en el presupuesto. Lo caro es el salario del engineer, y justamente esa es la idea: un engineer por equipo.
La verdad poco glamorosa es que la mayor parte del valor vino de una persona a la que le importaba, sentada cerca del trabajo, con un agente de código que eliminó la excusa de "no tenemos capacidad de ingeniería". Esa combinación está al alcance de casi cualquier empresa hoy mismo.
Y si un lugar donde los reclutadores lanzan software en producción y el CEO escribe especificaciones suena como el tuyo, el sitio de empleo que construyó el equipo está en careers.doit.com. Los filtros ya funcionan; lo comprobé.
