Les pido a los candidatos que usen IA en la prueba técnica

Casi todo lo que veo alrededor de las pruebas técnicas va por el lado de la detección. Supervisión remota, análisis de pulsaciones, herramientas que avisan cuando alguien pega de golpe un bloque de código.

Nosotros fuimos por el camino contrario. Les pedimos que usen IA. Está en el enunciado.

El razonamiento no tiene mucho misterio. Si contratamos a esa persona, el lunes por la mañana va a usar IA. Evaluarla en un estado en el que nunca va a trabajar dice muy poco de cómo va a hacer el trabajo. Y una prueba diseñada para resistirse a la IA acaba siendo una prueba sobre una herramienta, no sobre el oficio.

Así que hicimos la tarea más fácil a propósito.

Qué les damos

Un proyecto pequeño, desde cero, sobre un framework. Normalmente Laravel, porque tiene de las barreras de entrada más bajas que hay. Usa IA. Y elige una metodología, spec-driven development o la que prefieras, pero sigue alguna.

Con eso quitamos casi todas las excusas habituales. El framework se encarga de lo aburrido, la IA se encarga de teclear, y les decimos de antemano qué tipo de proceso queremos ver en vez de dejarlo como una trampa. Lo que quede después ya no depende de las condiciones.

Qué miro al revisar

Abro el código buscando una sola cosa. ¿Han aportado algo propio, o han usado el framework como cajón de sastre?

La versión plana se reconoce enseguida. Todos los endpoints en routes/api.php, un archivo que lo hace todo, y nada que lo sostenga. Funciona. Puede que hasta pasen los tests. La IA es buenísima produciendo esto, y es igual de buena produciendo lo otro si quien la maneja se lo pide.

La otra versión tiene los conceptos separados. A veces hay una arquitectura por encima, hexagonal o CQRS, y sinceramente me da bastante igual cuál, mientras haya alguien detrás que sepa decirme por qué la puso.

La prueba es el material, no el filtro

Aquí es donde la prueba cobra sentido, y no es como filtro. La uso para tener algo concreto encima de la mesa en la entrevista, porque es ahí donde se decide.

Les digo que quiero añadir un command que haga lo mismo que uno de sus endpoints. Y miro.

Lo que espero es que vean que los dos deberían llamar al mismo sitio, que se den cuenta de que ese sitio todavía no existe en su código, y que lo extraigan. Lo que me encuentro cuando alguien no construyó de verdad lo que entregó es duplicación: copian la lógica del endpoint dentro del command y siguen. Luego les pregunto cómo lo testearían, y la diferencia se hace más grande.

Sin su propia prueba delante esta conversación no existe. Por eso la mandamos, y por eso da igual quién o qué escribió la primera versión: lo que se comprueba en directo es lo mismo que la prueba decía demostrar.

El que me hizo cambiar las preguntas

Me pasó con una entrega que tenía buena pinta. Los conceptos estaban separados, la estructura se sostenía y sobre el papel era de las mejores que habíamos recibido. En cuanto le pedí el command, se lió.

No veía que hubiera que sacar esa lógica a un sitio común para que la llamaran los dos. Me hablaba de buenas prácticas, pero cuando le pedía aplicarlas ahí mismo volvía a repetir lo mismo sin llegar a tocar el código.

Después le planteamos otra cosa. Su código enviaba un correo dentro de la propia petición, uno por cada elemento asignado. Le pregunté qué haría si alguien asignara cien de golpe y hubiera que mandar cien correos. No buscaba una respuesta concreta: hay varias formas de resolver eso y casi todas valen, y lo que quiero ver es el razonamiento y qué caminos se le ocurren. Acabó diciendo que quitaría la notificación y pondría una página para que la gente entrara a mirar si tenía algo nuevo.

Lo descartamos. Y no ha sido un caso aislado: me encuentro a bastante gente que no llega a resolver el problema, aunque haya varios caminos válidos para hacerlo.

Lo que me llevé de ahí no fue el descarte, sino un ajuste en las preguntas.

Ahora el caso que mando es deliberadamente fácil. Lo que discrimina viene después, en directo: le pido que lo altere aplicando arquitectura de verdad o buenas prácticas. Y no necesito que las haya aplicado en la entrega. Necesito que conteste rápido. Quien sabe de esto responde al momento, porque no lo está construyendo mientras habla: lo está recordando.

Por qué lo planteamos así

Aquí no hay nada que detectar. Les pedimos nosotros que la usaran.

Lo que miro es si alguien distingue entre código que funciona y código que tiene una forma. Conseguir que algo arranque cuesta menos que hace unos años. Lo que menos me encuentro es lo siguiente: alguien que mire lo que ha salido, piense que aquello está amontonado y decida moverlo a un sitio mejor.

En un equipo pequeño esa es la parte que importa, porque un archivo mal colocado lo acaba notando todo el mundo en un mes.