Cómo contratar a un desarrollador cuando no eres técnico

El momento en que te das cuenta de que estás fuera de tu terreno

Publicas la oferta, llegan los CV, y todos mencionan frameworks de los que nunca has oído hablar. Alguien afirma tener cinco años de "desarrollo full-stack con arquitectura de microservicios escalable" y no tienes ni idea de si eso es impresionante o algo que leyó en un tutorial una hora antes de la entrevista. Asientes durante la llamada. No tienes forma de cuestionarlo.

Esto es normal. La mayoría de las personas que dirigen una empresa de 10 a 200 empleados no son desarrolladoras, y aun así la mayoría necesita contratar a una. La buena noticia: no necesitas aprender a programar para contratar bien. Necesitas dejar de intentar juzgar el código y empezar a juzgar la evidencia que lo rodea.

No finjas fluidez técnica: te puede salir el tiro por la culata

Los candidatos notan cuando estás faroleando. Preguntar "cuéntame sobre tu experiencia con Kubernetes" y luego responder "genial, genial" sin importar lo que digan le enseña a un candidato astuto que esta entrevista no tiene un listón real. Los que hablan con soltura pero no pueden entregar resultados pasarán sin problema. Los candidatos discretos y competentes, que asumen que de verdad estás verificando, se venderán por debajo de su valor.

Mejor sé honesto al respecto. "No soy técnico, así que voy a pedirte que expliques las cosas en lenguaje sencillo y voy a apoyarme en alguien técnico para parte de este proceso." Esto no es una debilidad: es lo mismo que hace un responsable de contratación competente cuando contrata en cualquier área que no ejerce personalmente.

Pide prestados los ojos técnicos de otra persona, durante una hora, no todo el proceso

No necesitas un cofundador técnico a tiempo completo para contratar bien. Necesitas una hora del tiempo de un desarrollador, dos veces: una para ayudarte a redactar la descripción del puesto y las preguntas de selección, y otra para participar en una conversación de la ronda final o revisar una muestra de trabajo.

Quién puede ser esta persona:

• Un desarrollador freelance al que pagas por dos horas de consultoría
• Un amigo o asesor que haya construido software antes
• Un contratista al que ya recurres para otra cosa

Lo que le pides que haga debe ser concreto: "Mira la respuesta de este candidato a esta pregunta específica y dime si se sostiene." No "evalúa a esta persona por mí": eso es demasiado vago y pide demasiado a alguien que te está haciendo un favor.

Pide a los candidatos que expliquen su propio trabajo, no hipótesis

Un desarrollador que realmente construyó algo puede explicarlo en lenguaje sencillo, con el nivel de detalle que le pidas. Alguien que infla su CV normalmente no puede ir más allá de la superficie.

Buenas preguntas, en orden de cuánto revelan:

1. "Cuéntame sobre algo que hayas construido de lo que te sientas orgulloso. ¿Qué hacía y cuál fue tu parte en ello?"
2. "¿Cuál fue el problema técnico más difícil de ese proyecto y cómo lo resolviste?"
3. "Si les preguntara a los demás ingenieros de ese equipo cómo era trabajar contigo, ¿qué dirían y por qué?"
4. "Cuéntame de una vez que tu código rompiera algo en producción. ¿Qué pasó y qué hiciste?"

La cuarta pregunta es la que más revela. Casi todos los desarrolladores reales han roto algo alguna vez. Alguien que dice "eso nunca me ha pasado" tras varios años de experiencia declarada, o miente, o nunca ha lanzado nada que importara de verdad.

Usa una muestra de trabajo pequeña y real

No necesitas que un candidato construya una función completa gratis. Una tarea corta y acotada —que le lleve entre 60 y 90 minutos, similar al trabajo real que haría en el puesto— te dice más que una hora de conversación.

Que sea justa:

• Págala, o hazla lo suficientemente pequeña como para que sea razonable no pagarla (la mayoría de los candidatos te dirán cuál es cuál)
• Da la misma tarea a todos los que lleguen a esa etapa
• Pídeles que después te expliquen su propia solución; ahí es donde detectas a alguien que tuvo ayuda que no mencionó

Si no tienes el criterio técnico para revisar el resultado tú mismo, este es exactamente el momento de usar tu hora prestada de tiempo técnico.

Si prefieres no crear una tarea desde cero, una prueba de selección técnica calibrada puede hacer una primera criba antes de llegar a esta etapa: AssessFit ejecuta pruebas adaptativas en toda una gama de habilidades técnicas, para que no envíes a cada candidato directamente a tu único revisor técnico.

Comprueba lo que han entregado, no lo que dicen saber

Un CV lleno de nombres de tecnologías te dice qué ha tocado alguien, no en qué es bueno. Pide evidencia en su lugar:

• Un perfil de GitHub, un portafolio, o un enlace a algo real que hayan construido
• El nombre de la empresa y el producto, para que puedas verlo tú mismo
• Qué porcentaje de un proyecto fue realmente suyo frente al del equipo

No te impresione una lista larga de herramientas. Interésate por una o dos cosas en las que puedan profundizar de verdad. La profundidad es la señal; la amplitud de palabras de moda suele ser justo lo contrario.

Comprobación de referencias: pregunta por la entrega, no por la habilidad

No puedes preguntarle a una referencia "¿su código era bueno?" y esperar una respuesta útil, a menos que la referencia también sea técnica; e incluso entonces, es una pregunta blanda y generosa que la gente rara vez cuestiona.

Pregunta en cambio:

• "¿Terminaron lo que dijeron que terminarían, en el plazo que estimaron?"
• "Cuando algo salía mal, ¿te lo decían pronto o te enterabas después?"
• "¿Le confiarías algo ambiguo y le dejarías resolverlo, o todo necesita estar explicado con todo detalle?"

Estas preguntas tampoco requieren que la referencia sepa de código. Requieren que la referencia haya trabajado junto a esta persona, lo cual es un listón mucho más bajo para obtener respuestas sinceras.

El límite honesto de todo esto

Nada de esto sustituye, a la larga, contar con una persona técnica de confianza. Si esta es tu primera contratación de ingeniería y de verdad no hay nadie en tu red que pueda hacer una comprobación de sensatez, vale la pena reconocerlo abiertamente como un riesgo, ante ti mismo y posiblemente ante un inversor o asesor inicial que pueda conocer a alguien. Un período de prueba de 90 días con hitos de entrega claros y no técnicos (si la cosa se lanzó, si funcionó, si los usuarios se quejaron) es tu red de seguridad si la contratación resulta más débil de lo que sugería la entrevista.

No estás intentando convertirte en desarrollador. Estás intentando construir un proceso que detecte la diferencia entre alguien que ha construido cosas de verdad y alguien que se ha memorizado las palabras para aparentarlo.