Cómo evaluar las habilidades de colaboración con IA en una entrevista de codificación
Cuando el uso de IA se convierte en una habilidad, no en un comportamiento a detectar
Durante la mayor parte de los últimos dos años, la IA en entrevistas era algo contra lo que defenderse. La rúbrica era "¿usó IA el candidato y la detectamos?" Este enfoque sigue siendo válido en rondas donde la IA está prohibida, y la capa de integridad que detecta mal uso allí es trabajo real.
Pero en el mismo bucle, cada vez más empresas están ejecutando una ronda donde la IA es obligatoria. Meta, Canva, Shopify y Coinbase evalúan explícitamente a los candidatos en colaboración con IA. Si tu bucle se está moviendo en esa dirección, necesitas una rúbrica — porque si le dices a un candidato "usa las herramientas que quieras" y lo calificas según si el código final funciona, estás midiendo casi nada. El hecho de que el código funcione es la contribución de la IA. La habilidad es la que aporta el candidato.
Este post es para managers de contratación que diseñan esa ronda de colaboración con IA. Cuatro dimensiones a calificar, un formato de ejercicio, y los errores comunes de los entrevistadores que aplanan la señal.
Las cuatro dimensiones que vale la pena calificar
Una rúbrica útil de colaboración con IA prueba habilidades que son observables en 45 minutos y que distinguen al ingeniero que usa bien la IA del que copia su resultado. Cuatro dimensiones, con anclajes en cada nivel.
1. Calidad de la solicitud y descomposición del problema
Los candidatos fuertes no piden al modelo que "construya la función". Descomponen primero el problema, luego solicitan ayuda para la parte que necesitan. La primera solicitud del buen ingeniero se parece a un ticket bien delimitado; la del ingeniero débil se parece a la declaración del problema original.
Lo que debes escuchar:
- ¿Reformuló el problema con sus propias palabras antes de hacer la solicitud?
- ¿Restringió el modelo — rutas de archivos, firmas de función, la forma de los datos, ejemplos del resultado esperado?
- ¿Pidió una cosa a la vez, o pegó todo el resumen y rezó?
Un proxy útil: ¿cuántos tokens escribió el candidato en la solicitud por cada línea de código que produjo la IA? Por debajo de cierta proporción, el candidato está usando el modelo como una caja mágica y no está ejerciendo criterio sobre la entrada.
2. Verificación y escepticismo
Esta es la dimensión que con mayor frecuencia separa lo fuerte de lo débil. El modelo produce resultado. ¿Qué hace el candidato con él?
La señal más fuerte es si el candidato verifica antes de integrar. Comportamientos específicos:
- Leer el código generado línea por línea antes de pegarlo
- Ejecutarlo contra un caso de prueba que el candidato construyó (no uno que sugirió el modelo)
- Detectar una función o biblioteca alucinada e intentar volverla a solicitar o reemplazarla ellos mismos
- Notar que el resultado es plausible pero incorrecto en un caso límite
El comportamiento más débil es pegar y rezar: el candidato copia el código del modelo en el editor, ejecuta el caso feliz, ve verde, y continúa. Esto es el equivalente de colaboración con IA de un ingeniero junior fusionando sin leer el diff.
Usa el mismo análisis de coherencia del código que marca código generado por LLM en evaluaciones asincrónicas. En una ronda de IA obligatoria, la puntuación no es "¿usó el candidato IA" — eso se da por supuesto. La puntuación es si las ediciones del candidato en el resultado de la IA muestran evidencia de lectura y reflexión, o si el diff es puro pegado.
3. Control del bucle
Los candidatos junior siguen a la IA a donde quiera que vaya. Los candidatos fuertes lideran la IA.
Comportamientos concretos a calificar:
- Cuando el modelo devuelve una respuesta incorrecta, ¿diagnostica el candidato y solicita de nuevo con una restricción corregida — o sigue regenerando, esperando una respuesta diferente?
- Cuando el modelo propone una arquitectura con la que el candidato no está de acuerdo, ¿presiona ("Preferiría usar una máquina de estados aquí, ¿puedes hacerlo de nuevo con ese patrón?") o acepta la sugerencia?
- Cuando el modelo se va por la tangente (refactorizando algo que el candidato no pidió), ¿lo nota el candidato y lo devuelve?
Esta dimensión es invisible sin grabación de pantalla. Asegúrate de que la ronda capture el historial de solicitudes y el diff del editor juntos, no solo el código final.
4. Comunicación mientras se trabaja en pareja con IA
La última dimensión es si el candidato mantiene al entrevistador en el bucle. Suena suave pero es el predictor de mayor señal de cómo trabajará el candidato día a día en un equipo que trabaja en pareja con IA.
Qué se ve bien:
- Narrar antes de solicitar: "Voy a pedirle a Claude que redacte el analizador. Espero que acierte con el tokenizador pero probablemente maneje mal los caracteres de escape — tendré que repararlo."
- Mostrar la solicitud antes de enviarla
- Sacar a la luz el desacuerdo con el modelo en voz alta, no en silencio
- Distinguir lo que escribieron de lo que escribió el modelo al explicar el código
La versión débil: solicitud silenciosa, pausas largas mientras el candidato lee el resultado del modelo sin compartir lo que piensa de él, código apareciendo en el editor sin explicación de dónde vino. Un candidato que codifica en silencio con IA codificará en silencio con humanos, y esa es una señal de dinámmica de equipo que quieres detectar en el bucle.
El ejercicio que revela estas habilidades
La tentación es dar al candidato un problema de algoritmo y dejarle usar IA. No hagas esto. La IA lo resolverá en segundos y el candidato pasará 40 minutos editando comentarios. No aprenderás nada.
Un ejercicio mejor tiene tres propiedades:
- Multietapa, con una sorpresa incorporada. Comienza con una tarea pequeña que el candidato claramente pueda resolver. A mitad de camino, introduce una solicitud de cambio que rompa una suposición — un nuevo formato de datos, una restricción de rendimiento, una biblioteca deprecada. La adaptación es donde aparece la habilidad de colaboración con IA.
- Un punto de partida sutilmente roto. Dale al candidato código que se compila y ejecuta pero tiene un bug sutil — un error de uno, una excepción tragada, una condición de carrera bajo carga. Observa si lo detectan ellos mismos o confían en que la IA lo encuentre. La mayoría de los modelos no encontrarán un bug sutil sin solicitud.
- Un componente de documentación o investigación. La tarea requiere que el candidato se integre con una biblioteca o API desconocida. El modelo sabe de ella. El candidato tiene que verificar lo que dice el modelo contra los documentos reales. La brecha entre "el modelo afirma" y "los documentos dicen" es una señal rica.
Cuarenta y cinco minutos para toda la ronda. El editor de código colaborativo de ClarityHire ejecuta Monaco con ejecución integrada y lo combina con captura de historial de solicitudes, para que el entrevistador pueda ver el diff del editor y la conversación del modelo uno al lado del otro durante el resumen — no solo el código final.
Anclajes de puntuación, 1 a 4
Califica cada dimensión independientemente en una escala 1–4. Ancla los niveles a comportamientos, no a adjetivos.
Calidad de la solicitud (1–4):
- 1: Pega la declaración de todo el problema en el modelo; sin descomposición.
- 2: Pide la función como un todo, pero añade al menos una restricción.
- 3: Descompone la tarea en dos o tres piezas; solicita cada una por separado con contexto relevante.
- 4: Escribe solicitudes bien delimitadas que incluyen la firma de función, la forma de los datos, y un ejemplo trabajado.
Verificación (1–4):
- 1: Pega el resultado del modelo sin leer.
- 2: Lee el resultado pero solo prueba el caso feliz.
- 3: Construye al menos un caso de prueba independiente de las sugerencias del modelo; detecta al menos un problema.
- 4: Trata cada resultado como sospechoso; verifica contra documentos reales, datos de prueba reales, y casos límite antes de integrar.
Control (1–4):
- 1: Sigue lo que produce el modelo; regenera en lugar de solicitar de nuevo después de fallo.
- 2: Solicita de nuevo con el mismo contexto después del fallo; a veces detecta que el modelo se sale del camino.
- 3: Diagnostica por qué el modelo está equivocado y solicita de nuevo con una restricción corregida.
- 4: Define la arquitectura ellos mismos y usa el modelo para piezas tácticas; presiona cuando el modelo sugiere un diseño diferente.
Comunicación (1–4):
- 1: Solicitud silenciosa; el resultado aparece en el editor sin explicación.
- 2: Narra el resultado final pero no el proceso.
- 3: Narra antes de solicitar y muestra la solicitud al entrevistador.
- 4: Distingue claramente su propia contribución de la del modelo; saca a la luz los desacuerdos con el modelo en voz alta.
Usa una tarjeta de puntuación estructurada donde cada entrevistador bloquea su puntuación antes del resumen. Las dimensiones son lo suficientemente independientes que el desacuerdo es informativo — un entrevistador podría calificar al candidato 4 en verificación y 2 en comunicación, y ese patrón es lo que vale la pena discutir.
Errores comunes del entrevistador
Cinco errores que aplanan la señal en esta ronda:
- Calificar el código final. El código es de la IA. El criterio, las solicitudes y las ediciones son del candidato. Califica esos.
- Pedirle al candidato que "explique lo que hizo la IA." Eso prueba comprensión de lectura, no colaboración. En su lugar, pregunta "¿qué cambiarías sobre cómo la IA abordó esto?"
- Dejar que la ronda transcurra en silencio. Si el candidato se queda callado durante dos minutos mientras lee el resultado del modelo, pregúntale: "cuéntame a través de lo que estás mirando." El silencio no es la prueba; estás evaluando cómo trabajan en pareja.
- Elegir un problema que el modelo pueda resolver de un solo disparo. Un problema trivial significa que el candidato nunca tiene que demostrar control, verificación o recuperación. Elige un problema que requiera al menos una ronda de desacuerdo con el modelo.
- Olvidar la línea base de integridad. Esta es la ronda de IA obligatoria, pero todavía estás en el mismo bucle que la ronda de IA prohibida. Si el patrón de pulsación de teclas de un candidato en esta ronda se parece idéntico a la ronda prohibida, eso es interesante — por razones buenas (el candidato genuinamente tipea así) y malas (el mismo ayudante fuera de cámara ejecuta ambas rondas).
Qué hacer a continuación
Si estás a punto de añadir una ronda de colaboración con IA a tu bucle:
- Decide cuál de las cuatro dimensiones importa más para el rol específico. Un ingeniero de ML aplicado probablemente pesa la verificación más alto; un ingeniero de software generalista podría pesar la comunicación.
- Diseña un ejercicio que incluya una sorpresa a mitad de camino y un bug sutil de inicio. Escribe los anclajes antes de que el primer candidato lo vea.
- Captura el historial de solicitudes junto con el diff del editor. Sin las solicitudes, estás calificando código; con ellas, estás calificando al ingeniero.
- Calibra con dos entrevistadores en una sesión grabada antes de ejecutarlo en vivo. El desacuerdo entre ellos es la rúbrica.
- Califica esta ronda independientemente de la ronda de IA prohibida. Miden cosas diferentes, y mezclarlas recompensará al candidato equivocado.
El objetivo de esta ronda no es encontrar candidatos que puedan usar IA — casi todos pueden. Es encontrar a los cuyo criterio, verificación y dirección son lo suficientemente buenos para que la ventaja de la IA se vuelva real, en lugar de cara y de pegar-y-rezar.