Canva ya espera que los candidatos de varias áreas de ingeniería usen herramientas de IA en una entrevista técnica, y Meta dijo que va a permitir que los candidatos usen IA en algunas entrevistas. Si estás por permitir IA en entrevistas técnicas, la discusión de política es la parte en la que tu equipo va a gastar tres reuniones y la que menos importa. Decir que sí es fácil. Lo que te cuesta es una pregunta que antes respondías de casualidad: si esta persona sabe hacer el trabajo. Estas son las seis conductas que yo evaluaría en su lugar, y la falla de la que nadie te advierte.
¿Deben los ingenieros usar IA en entrevistas? Esa es la parte fácil
Prohibir los modelos dejó de funcionar, y no porque los candidatos se hayan vuelto más astutos. La prohibición nunca fue exigible, así que lo que tenías era una regla más una suposición sobre quién la cumplía. Escribí bastante sobre por qué detectar trampas con IA es la pregunta equivocada, y la versión corta es que esa suposición señala a tus candidatos cuidadosos casi tan seguido como a los deshonestos.
Entonces los equipos cambian la política. Bien. El problema es lo que pasa después, que suele ser nada. La rúbrica queda igual, las preguntas quedan igual, y ahora todos las terminan. Una prueba que ordenaba tu pipeline deja de ordenarlo, y la entrevista se vuelve en silencio un trámite que todos aprueban.
Ese es el costo del cambio de política, y llega haya o no haya sido votado. La dificultad de escribir código venía haciendo un trabajo silencioso a tu favor durante años. Ordenaba tu pipeline sin que nadie tuviera que diseñar ese orden, y por eso nadie lo anotó como algo que la entrevista estuviera midiendo. Permite la herramienta y eso desaparece, así que ahora tienes que ir a buscar la señal a propósito.
Seis conductas que muestran aprovechamiento de IA real
Este es el marco que yo le daría a un entrevistador el lunes. Las seis se ven en una sesión de trabajo grabada, y ninguna requiere una opinión sobre lo que el candidato estaba pensando.
- ¿Encuadran el problema antes de escribir el prompt? Mira los primeros noventa segundos. Algunos candidatos reformulan el problema con sus palabras, nombran la restricción que lo vuelve incómodo, o te preguntan algo. Otros pegan el ticket directo en la caja. Los que vale la pena contratar casi siempre se toman un momento para decidir qué están pidiendo en realidad.
- ¿Qué le cargan al contexto? Esta se ve clarísima apenas la empiezas a buscar. Los candidatos fuertes pegan el schema real, el stack trace de verdad, la restricción que hace que el problema sea suyo y no uno genérico. Los más débiles pegan una descripción ordenadita del problema y reciben una respuesta ordenadita a un problema que nadie tiene.
- ¿Qué descartan? Llega la primera respuesta y ahí cuentas qué sobrevive. Alguien con criterio la lee como un borrador con dos buenas ideas adentro y borra el resto sin sufrir. Alguien sin criterio se pone a editar los bordes de lo que le dieron.
- ¿Cómo la verifican? Correrla, escribir un test rápido, tocar el caso borde que sospechan, ir a leer la documentación de verdad. O que "se ve bien" cargue con todo el peso. Si pudiera quedarme con una sola de las seis, me quedo con esta, porque es la que vale más a medida que los modelos mejoran en lugar de menos.
- ¿Saben cuándo dejar de preguntar? En casi toda sesión hay un momento en que el modelo empieza a dar vueltas. Algunos candidatos lo notan, cierran la pestaña y hacen el siguiente pedazo a mano o vienen a preguntarte. Otros reescriben el mismo prompt una y otra vez y se les van veinte minutos ahí.
- ¿Pueden hacerse cargo con el asistente cerrado? Al final, pídeles que te expliquen el trabajo terminado, incluida una parte que no escribieron ellos. La más barata de las seis y la más brutal. Cuatro minutos, y es muy difícil de fingir.
No necesitas que las seis estén fuertes. La dos y la cuatro cargan con casi todo el peso en mi experiencia, y la seis desempata cuando el debrief está dividido.
Aprovechamiento y dependencia se ven igual durante diez minutos
Acá está lo que me sorprendió, y es la razón por la que muchos formatos con IA permitida no funcionan aunque la rúbrica sea buena.
Durante el primer tramo de una sesión, un candidato que dirige al modelo y uno que copia de él producen un trabajo que se ve bastante parecido. Los dos van rápido. Los dos tienen algo funcionando. Si tu ejercicio es lo bastante corto como para terminar ahí, viste a dos personas parecer competentes y no aprendiste nada que las distinga.
La diferencia aparece en la primera cosa que sale mal. Una respuesta incorrecta, una restricción que el modelo ignoró, una repregunta que rompe la forma de lo que devolvió. El candidato con aprovechamiento toma eso como información y ajusta. El dependiente no tiene lectura propia sobre si la respuesta era correcta desde el principio, así que el error se vuelve el nuevo cimiento y todo lo que viene después hereda la falla.
La forma con la que me topo seguido es más o menos así. El modelo devuelve un middleware de auth que se lee bien y que trata alegremente un token vencido como válido. Es un bug silencioso. No tira excepción, no se pone nada en rojo, y el happy path funciona al primer intento. El candidato al que le va a ir bien escribe el caso del token vencido a los pocos minutos, casi siempre sin que se lo pidan, porque quería saber si la cosa aguantaba antes de ponerle peso encima. El que está en problemas construye tres endpoints arriba y se entera casi al final, cuando alguien pregunta por qué cerrar sesión no cierra la sesión de nadie. Misma respuesta inicial, mismos veinte minutos gastados, y solo uno de los dos escribió algo que mergearías. Si tu ejercicio termina antes de que ese bug pueda salir a la superficie, los dos sacan la misma nota.
Así que lo que decide si todo esto funciona es el ejercicio en sí, más que la rúbrica sobre la que la gente pasa el tiempo discutiendo. Tiene que producir de manera confiable un momento en el que el modelo se equivoque y alguien tenga que agarrarlo. Si tu ejercicio nunca genera uno, la rúbrica es decoración. Es el mismo problema estructural con el que me choqué cuando argumenté que la evaluación de código a prueba de IA es un espejismo: no puedes arreglar un problema de observación apretando aquello con lo que observas.
Evaluar el aprovechamiento de IA en contratación sin caer en la intuición
"Evalúa su aprovechamiento de IA" se convierte en la corazonada del entrevistador salvo que alguien escriba antes cómo se ve lo bueno. Algunas cosas que lo mantuvieron honesto:
Evalúa las seis por separado y no como una impresión única. Si no, un entrevistador al que le cayó bien el candidato rellena en silencio una nota alta en todas, y sales del debrief sabiendo que estuvo "bien" sin saber en qué.
Escribe los anclajes antes de que alguien entreviste. Una línea por conducta describiendo cómo se ve la versión débil, la aceptable y la fuerte. La cuatro se ancla fácil: la débil acepta la respuesta sin examinarla, la aceptable la corre, la fuerte prueba el caso que sospecha que se va a romper. La uno es genuinamente difícil de anclar, y creo que eso es diagnóstico. Si no puedes describir en una frase cómo se ve un buen encuadre, tus entrevistadores tampoco lo van a evaluar igual entre ellos.
El otro hábito que vale la pena exigir son notas sobre lo que pasó en lugar de lo que el entrevistador concluyó. "Reescribió el prompt del bug de auth durante diez minutos y después fue a leer el código de la librería" sobrevive un debrief de una forma en que "buen uso de IA" no, porque alguien puede estar en desacuerdo.
Aviso para que puedas pesar el sesgo: estoy construyendo Skillvee, una simulación de 60 minutos de un "día de trabajo" que reemplaza el filtro telefónico del recruiter y la primera ronda técnica. Los candidatos resuelven un problema real con IA disponible, hablan con compañeros de IA para conseguir la información que necesitan, y defienden sus decisiones ante un gerente de IA mientras se graba la pantalla. Obvio que voy a pensar que mirar el trabajo le gana a evaluar el entregable. Toma el marco por lo que vale, y ten en cuenta que las seis conductas de arriba las puede evaluar una persona con una grabación y ningún producto.
Dónde se pone difícil
Esto no sale gratis, y prefiero que escuches los costos de mi parte a que te los encuentres en el mes dos.
El banco de preguntas es el grande. Si tu loop se apoya en ejercicios donde producir el código era lo difícil, la mayoría hoy queda a un prompt de estar terminada, y reescribirlos compite con todo lo demás que tu equipo debe este trimestre. Los equipos que permiten IA sin hacer ese trabajo terminan con una entrevista más fácil y una lectura peor, que es justo el resultado del que la prohibición al menos los protegía de casualidad.
Después está la atención. Evaluar seis conductas de una sesión de trabajo cuesta más tiempo de entrevistador por candidato que un aprobado o reprobado en una prueba. Esa es una línea de presupuesto real, y por eso yo lo correría solo en la ronda donde ya estás gastando la hora de un ingeniero.
La última es la deriva de calibración, y es la que yo miraría a partir del mes dos. Las conductas tres y cinco dependen de que los entrevistadores se pongan de acuerdo sobre cómo se ve "borrar con confianza" y "saber cuándo parar", y dos entrevistadores pueden separarse bastante en eso sin darse cuenta. Recalibra sobre una grabación compartida cada tanto, igual que harías con cualquier dimensión conductual.
Nada de eso es razón para volver a prohibir la herramienta. La prohibición tiene un problema de precisión peor y se degrada con cada modelo nuevo. Pero permitir IA cambia lo que tu entrevista mide, y los equipos que lo leen como aflojar el estándar son los que se despiertan un trimestre después preguntándose por qué aprobaron todos. Si quieres una versión de esto que no sume horas de entrevistador, es para lo que construimos el producto.